在企业的规划、优化场景中，均需要开发规划类的项目，实现从各种可能方案中找出相对最优方案。如排班、生产计划（包括高层次的供应链优化，到细粒度的车间甚至机台作业指令）、车辆调度等。因为这类场景需要解决的问题，均可以归约为数学中的NP-C或NP-Hard问题。而解决此类问题，均需要通用的求解器才能实现。这类求解器也称规划引擎，通过它才能从天文数字的可能方案中，找出一个可行且相对优化的方案。
因为工作和其它原因，很长一段时间没有出新的、关于OptaPlanner的文章了，但工余时间并没有停止对该引擎的学习。与此同时Geoffrey大神带领的KIE项目团队并没有闲下来，尽管在工业可用性、易用性和使用门槛方面，OptaPlanner相对传统的求解器已经做得相当出色；特别是在规划过程交互、和各种操作接口方面，更是目前最为容易使用的规划求解器。
以下是翻译Optaplanner创始人Geoffrey De Smet的一篇文章《Does A.I. include constraint solvers?》。 因为英语及中文表达习惯的差异，以该
在单元测试中构造问题数据集，并发送到TimeTableController测试求解器。
Timeslot类表示教授课程的时间段，例如:星期一上午10：30-11：30或星期二13：30-14：30。为简单起见，所有时间段的持续时间相同，午餐或其他休息时间没有时间段。 时间段没有日期，因为高中的课程表每周都是一样的。 因此，无需进行连续规划（18.4）。
本文原来只计划直接翻译OptaPlanner官网一篇关于SolverManager下实时规划的博文《Real-time planning meets SolverManager》，但在翻译过程中，发现该文仅从具体的技术细节上描述使用SolverManager及其相关接口实现在批量规划过程中的实时响应。因此，只能对具体使用OptaPlanner的开发人员有一定帮助，对于相关的业务分析和决策人员关注的适用场景，该文并未作深入描述；因而，未能从业务场景到工程实践的角度和过程，来描述批量规划与实时规划的实用意义。
OptaPlanner创办人Geoffrey De Smet及其团队，在Red Hat 技术峰会上主题会场上，演示了一个通过OptaPlanner实现实时规划与调度的示例。Geoffrey及其团队专门为此分三篇博文描述了该程序。该程序及其相关博文是OptaPlanner在VRP领域极之经典之作。本系列也分三篇对博文进行翻译，以飨各位ORer, APSer和Planner.
通常一个应用包含一个SolverFactory 来为每个要求解的问题数据集构建新的Solver实例。SolverFactory是线程安全的，但Solver不是。
本文章译自OptaPlanner官网上，Geoffrey De Smit先生的博文，链接如下：How good are human planners? 以下为译文： 在规划方面，我们人类比机器（计算机
*score(分数)*表示特定解决方案的质量，越高越好。OptaPlanner通过在可用时间寻找最高得分的解决方案的方式来寻找最优方案，它也可能是最佳方案。
在此之前，针对APS写了一些理论性的文章；而对于OptaPlanner也写了一些介绍性质，几少量入门级的帮助初学者走近OptaPlanner。在此以后，老农将会按照OptaPlanner官方的用户手册的结构，按章节地对其进行翻译，并成型一系列的操作说明文章。在文章中，为了降低对原文的理解难度，有些地方我不会直接按原文档的字面翻译，而是有可能加入一些我自己的理解，或添一些解释性的内容。毕竟英语环境下的思维和语言表达方式，跟中文或多或少会有差别的，所以如果全部按字面翻译，内容就非常生硬，可读性差，解程难度较大。我认为应该在理解了作者原意的基础上，再进一步以中文方式的表达，才算是真的的本地化。记得老农还是少农时，学习开发技术，需要阅读一些外国书箱的翻译本时，印象最深的是候捷老师的书，尽管《深入浅出MFC》，砖头厚度的书，硬是被我翻散了线，MFC尽管真的晦涩难懂，但候老却能把Windows的消息机制及MFC中整个个宏体系，系统地通俗地描述出来，令读者不需要花费太多精力去理解猜测书中字面的意义，大大降低的VC++中MFC的学习门槛。但老农毕竟只是一个一线开发人员，不是专业的技术资料翻译人才，不可能有候老师的专业水平，因此，我也只可尽我所能把内容尽量描述得通俗一些，让读者尽量容易理解，花费更少的时间掌握这些知道要点。
本人2004年有幸参加了中国石油集团的高性能数控测井系统项目的开发研制工作。该系统是在当前测井成套测井装备的基础上，为了满足高精度，高性能，高效率的要求开发的测井系统。该系统由井下成套仪器，测井遥测系统，测井地面系统，测井软件系统，测井解释评价系统等子系统组成。本人在其中主要是负责测井软件系统的分析、设计以及部分开发任务。设计模式是前人设计面向対象软件的经验和总结，在软件设计中灵活的使用设计模式可以极大的提高系统的稳定性，可扩展性，以及良好的可维护性。本文描述了在测井软件系统开发过程中，如何分析和发现相关模式，以及如何选择和应用设计模式，特别是介绍了 MVC模式在软件框架和相关系统模块中的应用和使用效果。在文章的最后，讨论了在实际项目开发中，设计模式应用的有关想法和教训。
每个组织都面临规划问题：为产品或服务提供有限的受约束的资源（员工、资产、时间和金钱）。OptaPlanner用来优化这种规划，以实现用更少的资源来做更多的业务。 这被称为Constraint Satisfaction Programming（约束规划，这是运筹学学科的一部分）。
上一篇介绍了OptaPlanner 7.32.0.Final版本中的SolverManager接口可以实现异步求解功能。本篇将继续介绍SolverManager的另一大特性 - 批量求解。
在进行APS（高级计划与排程）系统开发时，绝大多数情况下是需要考虑多目标的。但面对多目标问题进行规划求解时，我们往往极容易因处理方法不当，而影响输出结果，令结果与用户期望产生较大差别。事实上很多时候用户，面对此类问题也无法给出一个确定的合理的期望，因为多个目标混合在一起的时候，产生复杂的规划逻辑，用户自身也会被迷惑，到最后就错误地提出一些所有目标都达到极致的“完美”计划要求；但客观上是不存在这种“完美”计划的。
很久没更新过APS系列文章了，这段时间项目工作确实非常紧，所以只能抽点时间学习一下运筹学的入门知识，算是为以后的APS项目积累点基础。看了一些运筹学的书（都是科普级别的）发现原来我目前面对的很多排产、排班、资源分配和路线规划问题，都是运筹学上的典型案例。与此同时，除了继续使用Optaplanner来做我们的规划类项目外，还花点时间去研究了一下Google OR-Tools开源规划引擎，这是Google旗下的一个开源求解器，接下来我会专门写一些关于Google OR-Tools应用的文章，并与Optaplanner作些关联对比。
从今年年初就一直在喊的具有革命性、未来性、开创新纪元的 JDK 21，正式发布了！
之前的文章中，分别从APS，排产到规划引擎叙述了一些理论基础；并介绍了一些Optaplanner大概的情况；并一步步将Optaplanner的示例运行起来，将示例源码导进Eclipse分析了一下它的Hello world入门示例，从本篇开始，我们将分步学习它的一些概念及用法。
之前的文章中，分别从APS，排产到规划引擎叙述了一些理论基础；并介绍了一些OptaPlanner大概的情况；并一步步将OptaPlanner的示例运行起来，将示例源码导进Eclipse分析了一下它的Hello world入门示例，从本篇开始，我们将分步学习它的一些概念及用法。
Java 17 已正式发布，新版本提供了不少新特性和功能增强。不过对于大多数项目而言，往往需要更改代码才能利用到这些新变化，但性能除外 —— 开发者只需要升级 JDK 版本，就能免费获得性能提升。
本人2004年有幸参加了中国石油集团的高性能数控测井系统项目的开发研制工作。该系统是在当前测井成套测井装备的基础上，为了满足高精度，高性能，高效率的要求开发的测井系统。该系统由井下成套仪器，测井遥测系统，测井地面系统，测井软件系统，测井解释评价系统等子系统组成。本人在其中主要是负责测井软件系统的分析、设计以及部分开发任务。作为整个系统控制核心的测井软件如何才能保证有整个系统的高性能和高可靠性呢？ 本文从系统优化、程序设计优化两个方面来详细讨论如何提高整个测井软件系统的性能。其中系统优化主要是通过调节软件运行环境来优化软件性能，程序设计优化主要从程序架构设计、语法、内存管理、输入输出等方面来讨论如何采取措施提高软件的性能。
本人在测井行业的一个国有企业软件开发部工作，从2002年初开始，我陆续参加了多个测井软件开发项目，这些项目都是测井行业资料处理解释软件，具有很强的行业特征，其开发方向和应用范围都非常相似，从“测井资料处理集成软件"项目，开始我实施了软件产品线技术，虽然在开始阶段，由于经验不足和管理不善，遇到了一些问题，但是随着逐歩实施，都得到的纠正和有效控制，目前这几个软件项目都非常顺利的完成，实施工期明显缩短， 极大的提高了产品质量，本文就在这些项目中为什么实施软件产品线？在实施过程中遇到哪些问题？产品线开发支持工具选用情况和产品线实施带来的益处等进行论述，并分析总结在目前本单位产品线技术应用中存在的不足。
有好些时间没有写过关于OptaPlanner的东西了，其实近半年来，OptaPlanner还是推出了不少有用、好用的新特性。包括本文讲到的以Stream接口实现评分编程。关于OptraPlanner的约束详细用法，可以参考官方资料：
上篇笔记里介绍了微环谐振器的一些基础知识点，有些地方表达得不是很准确，被一位读者指出来了(感谢long_rain的指正)，这篇笔记继续查漏补缺。
经过上面篇长篇大论的理论之后，在开始讲解Optaplanner相关基本概念及用法之前，我们先把他们提供的示例运行起来，好先让大家看看它是如何工作的。OptaPlanner的优点不仅仅是提供详细丰富的文档 ，还为各种应用场景提供丰富的示例，它的文档里都是以几个简单经典的例子来说名各种功能特征和深层次概念的，例如Solver, Phase及Move等，以下我们就先把这些示例运行起来，先看看整体的情况，下一往篇我们再把示例的源码导进Eclipse，拿一个简单经典的示例，讲解一下Optaplanner规划引擎工作时需要哪些要素，它是如何工作的。
本人是名软件开发人员，从事软件开发工作10多年。近几年慢慢沉淀到制造业信息化方面，主要是APS在生产计划方面的应用，APS - Advance Planning and Scheduling, 高级计划与排程技术。其实就是计划的一种优化手段，其中使用了一些优化算法，令计划的质量更高一些。通过该技术生成的计划，在达到一些硬性约束的基础上，能实现更进一步的优化。例如满足生产工艺的同时，提高订单的按时交付率，降低成本等。从最开始被调去做ERP数据适配APS项目实施，到现在自己在为公司设计、开发排产程序（通过第三方规划引擎用、求解器实现）。从中也接触过不少排程产品，针对不同的场景，其适应性、可用性千差万别。长期制造企业生产领域的工作经历，令我有更多机会面对各种供应链、排产等方面的问题。本人细说一下APS技术在制造业的生产计划上的应用。
求解线性方程组是科学计算中的一个基础问题，也可利用线性方程组构造复杂的算法，如数值计算中的插值与拟合、大数据中的线性回归、主成分分析等。而正是由于线性求解问题在学科中的基础性作用，其在科学、工程、金融、经济应用、计算机科学等领域也应用广泛，如常见的天气预报，需要通过建立并求解包含百万变量的线性方程组实现对大气中类似温度、气压、湿度等的模拟和预测；如销量预测，需要采用线性回归方式的时序预测方法进行预测。
在结构光三维重建中，最常见的方法就是相移法，相移是通过投影一系列相移光栅图像编码，从而得到物体表面一点在投影仪图片上的相对位置或者绝对位置。下面，笔者将详细介绍如何制作相移编码图片，以及如何对获取的相移图片进行解码，最后笔者将粗浅的谈谈相移相比其他方法（如格雷码）有什么优势。
去年初，单位承担了新立的“测井资料处理与解释集成软件"项目，目的是集成目前国内零敬的测井解释方法，我有幸参加该项目，并负责软件系统平台设计和部分开发工作，在项目的实施过程中，我充分进行基于构件的软件开发，复用成熟的商业构件和本单位的构件资源库，同时考虑了本项目开发资源的进一歩复用，形成了绘制组件包，数据交换组件和数值计算组件包等。基于构件开发，大大提高了软件的质量，缩短软件的开发周期。开发的软件目前在石油测井几个油田现场使用，并得到用户的好评。本文就在本项目中如何进行基于构件开发进行描述，并在复用构件的使用和丰富方面谈一些自己看法。
在本文中，我将尝试简要介绍一下这篇论文的重要性，但我将强调实际应用，以及我们如何应用这种需要在应用程序中应用各种神经网络。
根据公司软件系统开发的需要，我们在软件的开发过程中引入了软件产品线技术，成立了基于软件产品线的项目组。本人有幸参加了该项目，并在其中担任软件分析与设计、软件产品线核心资源开发的工作。 在软件产品线的开发过程中，我们使用了 ROSE建模工具，有效地完成了产品线中核心资源和产品的建模分析与设计实现；我们使用了国际标准POSC数据模型框架，有效地解决了数据的多样性与可扩展性，实现了统一开放的测井数据访问系统；建立了统一的可扩展的地质绘制组件和统一公用的数据处理模块。最终圆满的完成了公司产品线的建立和各子系统的开发。
光流的概念是Gibson在1950年首先提出来的。它是空间运动物体在观察成像平面上的像素运动的瞬时速度，是利用图像序列中像素在时间域上的变化以及相邻帧之间的相关性来找到上一帧跟当前帧之间存在的对应关系，从而计算出相邻帧之间物体的运动信息的一种方法。一般而言，光流是由于场景中前景目标本身的移动、相机的运动，或者两者的共同运动所产生的。
Slam：同步定位与建图，就是在定位的同时，建立环境地图。 主要思路是根据运动学模型计算位姿，并通过传感得到的环境信息，对估计位姿调整优化，从而得到准确位姿，根据定位及感知数据绘制地图。 下图为slam主流框架：
量子相位估计算法（quantum phase estimation，QPE）也称作量子特征值估计算法，是很多量子算法的基本步骤，其中包括Shor`s算法（秀尔算法）和HHL算法（线性方程组的量子算法）。它的作用就是快速的估计一个酉变换的特征值。由于酉矩阵拥有一个性质：酉矩阵的特征值都是模为1的复数。所以对酉矩阵而言，其特征值和相位基本是对等的。
SeismicPro是我用C#写的一款地震剖面显示软件，可从标准SEGY地震数据体中抽取纵测线和横测线的二维剖面，并以波形、变面积和变密度等多种方式进行专业化显示，可进行一键式显示方式切换，并可进行定制开发叠加井轨迹与测井曲线等。 我感觉最人性化的一个功能是：只需要指定一个地震数据体SEGY文件（里面含有多条测线，自动判断道头字位置），就可以任意抽线显示了。 主要功能列表： 1）根据SEGY快速生成三维工区信息，可预览三维工区的概貌 2）快速选取纵测线或横测线 3）在工区内以指定间隔快速前滚、后滚剖面 4）
其实本文不知道算不算一个知识点分享，过程很美妙，但结果很失败。我们在利用OptaPlanner的Real-Time planning(实时规则)功能，设计实时在线规划服务时，遇到一个属于OptaPlanner7.8.0.Final版本的Bug。在实现实时在线规划服务的过程中，我做过很多尝试。因为需要实时在线的服务，因此，需要设计多线程并发为外界请求提供响应，需要实现消息队列来管理并发请求的时序等问题。这些Java方面的并发处理，我们暂时不详述，这方面的牛的人太多了，我只是新手，站在别人的肩膀上实现的代码而已。在本文我着重介绍一下，我在尝试使用OptaPlanner的Real-Time Planning功能时遇到的问题，最终确认问题出自OptaPlanner引擎自身, 并通过JIRA向OptaPlanner 团队提交issue过程。 关于OptaPlanner的Real-time planning 先看看正常情况下，我们对OptaPlanner的应用场景。平时我们使用OptaPlanner时，不外乎以下几个， 构建Problem对象 + 构建Solver对象-> 启动引擎 -> 执行规划 -> 结束规划 -> 获得方案-> 获取结果方案,如下图。 这种应用模式下，引擎处于一个非实时状态，只是一个调用 -> 获取规划结果的简单交互过程。
在进行实例的动态推断和构建时，我们会经常使用到反射这一技巧，然而在某些场景中反射的效率显得有些力不从心。从JDK7开始，MethodHandle被推出，用于解决反射的效率问题。在JDK8，MethodHandle又与Lambda进行深度结合，成为Lambda的最底层调用方式。在JDK9，MethodHandle又被进一步增强。 在开源项目中，Mybatis Mapper的动态代理实现则运用了MethodHandle。
今天我们接着上期的问题分析把整个过程的数学细节都描绘下来，注意今天的描绘的粒度是每一次对整个序列的遍历，而第一篇描述的时候是每一次行动。但是，这次更加粗粒度的角度没有抹去任何细节，反而抓住了更加深刻的规律，利用了剔除过程中每个周期内的周期性，或者说是同余性质，我们一点点来看。
Java 17 已正式发布，该版本是自Java 11以来的首个长期支持版本。Oracle 还提议将 JDK LTS发布的节奏从每三年一次改为每两年一次，并且每个LTS 版本的服务时间至少8年以上。Java 版本通常是6个月一更新，时间分别在3月和9月，而这些版本的支持时间基本在半年左右。
“前几篇文章介绍了振动耐久试验常用的类型：正弦扫频，宽频随机，正弦叠加随机，半正弦冲击。接下来的几篇文章将对这些试验类型作深入的对比。在这之前，需要先基础的介绍振动力学方程及其求解。”
Oracle 还提议将 JDK LTS发布的节奏从每三年一次改为每两年一次，并且每个LTS 版本的服务时间至少8年以上。Java 版本通常是6个月一更新，时间分别在3月和9月，而这些版本的支持时间基本在半年左右。
在之前的文章中，已介绍过APS及规划的相关内容，并对Optaplanner相关的概念和一些使用示例进行过介绍，接下来的文章中，我会自己做一个规划小程序 - 一个关于把任务分配到不同的机台上进行作业的小程序，并在这个小程序的基础上对OptaPlanner中更多的概念，功能，及使用方法进行讲解。但在此之前，我需要先讲解一下OptaPlanner在进行规则运算的原理。所以，本文是讲述一些关于寻找最优解的过程中的原理性的内容，作为后续通过示例深入讲解的基础。但这些原理知识不会涉及过分深奥的数学算法，毕竟我们的目标不是写一个新的规划引擎出来，更不是要研究各种寻优算法；只是理解一些概念，用于理解OptaPlanner是依据什么找出一个相对优解的。以便在接下来的一系列文章中，可以快速无障碍地理解我所讲解的更细化的OptaPlanner功能。
都说Java 8 是YYDS，那你注意到 Java 17 已经正式发布了吗？目前Java 18 也已经进入早期开发阶段。
上一篇我们成功以把Opotaplanner规划引擎下载回来，并把它的示例运行起来，简单解析了一下它的Cloud balance示例。这一篇我们这些示例的源代码导入到Eclipse中，看看它在后台是怎么运行的。
结构光法原理其实是跟双目视觉一样的，都是要确定对应“匹配点”，利用“视差”三角关系计算距离，所不同的是：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
