
2013-07-14 00:08
————————————————————————————————————————————————————————————————

第一版 字符串计算 架构思路：
第一版 命名空间 BaseUtil.Compute —— 只是 BaseUtil 程序集 中的 一个子功能
第一版 抽象思想：
	运算分为 运算符(IComputeSymbol + ComputeSymbolAttribute) + 函数(IComputeMethod + ComputeMethodAttribute)
	使用 常用的   接口 + 特性   的方式 进行插件扩展
	内置插件 
		运算符插件：	+ - * / % ^ LIKE > < >= <= = == === OR || AND && [?:] 
		函数插件：		REPLACE  LEN
	基础数据类型 的解析 为 代码内置：通过数据识别顺序 判定类型
		基础数据类型：		string double bool 
		基础数据判定顺序：	string double bool



第二版 字符串计算 架构思路：
第二版 命名空间 Laura.Compute —— 功能完全独立
第二版 改进：
	基础数据类型：			string double bool array
	支持 数组 ：			伴随支持 IN 运算符插件(第一版 的 IComputeSymbol IComputeMethod 无法扩展 IN 语法) 
	重大思想变革：			取消 函数概念: 比如之前函数 REPLACE(A, B, C) 思想转变成 REPLACE {Array} —— 只要是 (A,B,C ...) 这样的模式 统统被 认定为 数组
	取消函数概念 + 数组概念 造成的影响：	影响可能巨大,且可能导致的思想局限或者错误暂时未知(2013-07-13)
	取消参数 类型的 预设定：	第一版 因为不知道 表达式 中，哪些是 参数表达式，所以需要 给表达式 提前设置 数据类型，所以 增加了使用复杂度。第二版 采用 参数表达式 自动识别

第二版 抽象思想：
	依然使用   接口 + 特性   的方式 进行插件扩展
	核心思想：	类似 SQL 脚本的 语法模式
	概念合并：  函数思想 合并 到 运算符思想 中 —— 至此：函数也是一种 运算符  [这是一个 思想合并的过程 : 即为 再抽象], 伴随的是 接口 的 合并


————————————————————————————————————————————————————————————————


2013-07-16 00:21
————————————————————————————————————————————————————————————————
第二版 字符串计算 算法 已经写完

	算法完成 速度之快 主要是因为：
		>概念再抽象之后，核心思想 的简洁
		>在并序运算的代码 直接复制 第一版的 并序运算代码 (ExpressSchema.cs 301-318 行代码)
		>很多插件 代码 都是在 第一版插件代码 基础上 略做修改 而成，节省了不少时间

	基本测试已经通过：
		>运行速度 达到 每秒 10000-12000 次左右(配置：CPU-I3 Momery-6G)，远超 第一版 字符串计算算法(第一版 每秒 500-1000次左右)
		>参数化 字符串计算 尚未测试：预想BUG应该不大(因为 第二版 采用 先完全解析，再执行 的思想，预期性能依然在 第一版 10倍以上)

	算法亮点：
		>第二版语法 更人性化，除 可以省略的 this 关键字外，语法类似 SqlScript 如：[FSchoolName] == "孝感学院" AND [FStudentName] == "ShuXiaolong"
		>第二版语法支持 索引，子属性 超复杂表达式  如：  this.[FSchools]["孝感学院"].[FClasses][1].[FClassName] (可省略 this)
		>第二版语法 取消了 第一版语法 对 自定义属性格式 的支持：所有 参数属性 必须以 [] 括起来
		>第二版语法 支持 插件扩展 (第一版也支持)，凡是 继承 ICompute+ComputeExpressAttribute 的类 会被自动识别为 算法插件
		>第二版语法 支持 IN 关键字插件 (第一版语法 因为 概念思想 的局限，无法扩展 IN插件) 如  \"ShuXiaolong\" IN (\"ShuXiaolong\",\"HanYusi\")"
	
	算法用途：
		>内存检索(当然，速度 远远不及 SQL引擎 或 DataTable 的 检索)，在语法的 灵活性上 胜过 DataTable 的内存检索计算
		>动态编程(接下来 有一个 概念器 的 流程引擎 的设计)，让动态配置式 编程 更具有灵活性
		


第二版 和 第一版 算法插件 的 运算优先级 如下：
	StringLengthComputeMethod			LEN			1000000
	StringReplaceComputeMethod			REPLACE		1000000
	PowComputeSymbol					^			100000
	MultiplyComputeSymbol				*			10000
	RemainComputeSymbol					%			10000
	DivideComputeSymbol					/			10000
	PlusComputeSymbol					+			1000
	MinusComputeSymbol					-			1000
	LikeEqualComputeSymbol				LIKE		700
	LessThanEqualComputeSymbol			<=			685
	GreaterThanEqualComputeSymbol		>=			680
	LessThanComputeSymbol				<			675
	GreaterThanComputeSymbol			>			670
	StrictEqualComputeSymbol			===			610
	EqualComputeSymbol					==			605
	BaseEqualComputeSymbol				=			600
	AndComputeSymbol					AND			525
	AndSignComputeSymbol				&&			525
	OrComputeSymbol						OR			520
	OrSignComputeSymbol					||			520
	TernaryComputeSymbol				?:			100
	InComputeMethod						IN			未定(默认为 0)


————————————————————————————————————————————————————————————————


2013-07-19 04:35
————————————————————————————————————————————————————————————————
第二版 字符串计算 算法 测试完成

	>但是在 修改 BUG 的过程中，修改了细节代码，但这些细节代码 主要用于 括号的处理，分析算法 瞬间似乎 被严重拖慢
	>运行速度(分析+计算) 达到 每秒 7000-10000 次左右(配置：CPU-I3 Momery-6G) —— 已经被拖慢
	>目前的 计算速度 大有 低于 第一版 的势头

	>于是，哥陷入了杯具
	>具体速度 和 功能 是否比 第一版有绝对优势 当然还得 再次测试

	>第二版 比 第一版 最有优势的地方 或许 就只是 先完全编译，再完全执行 的 全分离。
	>在 同一 表达式的情况 下，动态对象参数 的计算速度，预计比 第一版 速度要快很多。

	>睡觉
	>Ps.今天是 丝雨生日 的样子，希望一切都好。

	>不甘心，再次测试了一哈：如果缓存了 ExpressSchema 对象，那么 执行 23*20000 次(分析1次+计算20000次)，时间 从 59秒 转为 906毫秒
	>计算环节 节省性能的 目标 或许算是 达到
	>后期 看如何优化 分析环节 的代码，将分析环节的速度 进行提升


————————————————————————————————————————————————————————————————


2013-07-20 01:51
————————————————————————————————————————————————————————————————
第二版 字符串计算 算法 内存检索 测试已经完成

	>速度简直让人不敢想象：
		>从 数据库单词表 读取出 55726 个单词
		>检索 条件为   [Word] LIKE '%cat%'
		>DataTable 自带的 内存检索 392.0224 毫秒
		>字符串算法 内存检索 时间为 909.052 毫秒（每秒计算超过 60000 次）
		>而之前 第一版 算法因为 没能将 分析|计算 完全分开，计算过程中还有要执行某些 分析操作 导致 第一版算法 需要 5-10分钟
		>第二版 字符串算法 在内存检索 方面的速度 虽然 低于 DataTable 的 内存检索
		>但是 此速度 已经完全胜任 今后 催化剂架构 中配置式编程 的需求

	>第二版 字符串算法 的速度已经 达到满意程度，接下来的 需要做的是 对 内存检索  内存排序 的封装


————————————————————————————————————————————————————————————————


2013-07-21 03:07
————————————————————————————————————————————————————————————————
第二版 字符串计算 算法 内存排序 测试已经完成

	>速度相比 内存检索 慢很多——但是依然远远超过自己的预期：
		>从 数据库单词表 读取出 55726 个单词
		>检索 条件为   [Word],[Comment] (即为 [Word] ASC,[Comment] ASC)
		>DataTable 自带的 内存检索 483.0277 毫秒
		>字符串算法 内存检索 时间为 8553.4892 毫秒（平均 6515 次）
		>而之前 第一版 算法因为 没能将 分析|计算 完全分开，计算过程中还有要执行某些 分析操作 导致 第一版排序 需要 8-15分钟
		>第二版 字符串算法 在内存排序 方面的速度 虽然 低于 DataTable 的 内存检索
		>但是 此速度 已经完全胜任 今后 催化剂架构 中配置式编程 的需求

		>当然：因为 现在的排序 是 现算结果 现比较：因此 55726 单词，实际计算次数 肯定是 远超 55726 次(即有 多次甚至数倍的 重复计算，重复计算次数 取决于 微软 Sort 算法的 复杂度)
		>因此 排序中，计算结果 肯定是要 使用缓存的

	>第二版 字符串算法 的速度已经 达到满意程度，内存检索  内存排序 的封装 已经基本宣告完成：接下来的工作 就是 优化 和 正式宣告完工
	>SVN 版本从 2013-07-12 183版 到 2013-07-21 222版，累计编码 约 10-14小时
	>(除 2013-07-19 凌晨5点提交的时间 比较玩命之外，其余时间多集中在 22-01 点之间；算是不紧不慢)

	>Ps.一边写代码，一边听YY，认识一首新歌 《偶像派-赵奕欢&莫熙儿&田晓天&王紫潼&宋丹》，正在试图听腻

————————————————————————————————————————————————————————————————


2013-07-21 04:02
————————————————————————————————————————————————————————————————
第二版 字符串计算 算法 内存排序 新增 SortExecuter 排序执行器(多线程下 不安全)

	>使用 比较执行器 之后，缓存了 List.Sort() 排序的 算法复杂度 造成了 重复计算过程
	>55726 个单词  [Word],[Comment] 排序
	>DataTale		排序时间	584.0334毫秒
	>检索排序		排序时间	8828.505毫秒
	>排序执行器		排序时间	2827.1617毫秒

————————————————————————————————————————————————————————————————


2013-07-21 05:04
————————————————————————————————————————————————————————————————
第二版 字符串计算 算法 封装已经完成

至此，算法 结束并完成。
代码调用 简化为 ExpressHelper.SomeMethod(*);

最后Ps. 算法基于 .Net Framework 2.0 编码，向上兼容 (爱 4.0，爱3.5，更爱一路走来的 2.0)

————————————————————————————————————————————————————————————————


2013-07-21 13:22
————————————————————————————————————————————————————————————————
增加插件

	DateAddComputeMethod				DATEADD			1000000
	DateConvertComputeMethod			CONVERTDATE		1000000
	DateDiffComputeMethod				DATEDIFF		1000000
	DateFormatComputeMethod				DATEFORMAT		1000000
	DateNowComputeMethod				GETDATE			1000000
	DatePartComputeMethod				DATEPART		1000000
	GuidNewComputeMethod				NEWID			1000000

	运算速度 平均问 20000(分析20000次+计算20000次)次 2000-2500毫秒 

————————————————————————————————————————————————————————————————



2015-08-18
————————————————————————————————————————————————————————————————
迁移版本库

	Laura.Compute 正式迁移为 InkFx.Express
	Compute 函数迁移为 Calc

————————————————————————————————————————————————————————————————



2015-11-18
————————————————————————————————————————————————————————————————
优化、稳定、异常分析、函数增加、调整架构

	性能：
		> 目前 数学计算 性能在 100W/s ; 函数计算 系能在 10W/s ;
		> 字符串 LIKE 函数 等 部分函数, 进行了 10~100 倍 的性能优化;
	
	修正：
		> 修复 部分细节 BUG ;
	
	完善：
		> 表达式错误时, 精确提示 错误的原因 ;
		> 用户参数 的 重构稳定 —— 用户参数 必须使用 [] 括起来 (包括 this 也得使用 [this] 关键字, [this] 可以省略);

	扩展：
		> 修正、增加 部分 日期函数
		> 完善 测试项目

	架构调整：
		> 为了 稳定的 用户参数, 删除了 200行核心代码, 且引入了 新的局部思想 ArgumentSlice.cs —— 目前, 用户参数 经过高压测试, 稳定高效 ;
		> 为了 精确定位 表达式的 错误原因, 删除了 150行核心代码, 且引入了 ExpressType.UnKonw 未知片段 这个概念 —— 但是会 损失 分析性能 ;
		> 为了 完全兼容 SQL Server 的 时间函数, 删除了 50行核心代码, 且引入了 全局常量、函数常量 这个概念 ;
			> 之前 DATEPART('YEAR', GETDATE()) 改版为 DATEPART(YEAR, GETDATE()) —— 去掉了 引号, 后者与 SQL Server 完全一致 ;
			> 这里的 YEAR 就成为了 函数常量
			> 而之前核心代码 内置的 圆周率 π 也被取消, 取而代之的 是两个 全局常量: PI π 

————————————————————————————————————————————————————————————————


