(四)集算器的目标

在设计目标上,集算器希望提升这两方面的效率:计算的描述效率计算的执行效率

这两个效率都容易理解,如果描述效率太低,就意味着开发成本太高,很难写出程序进行计算;而如果执行效率低,则需要运行很久才能得到结果,那实用价值也就大打折扣了。事实上,执行效率本质上也是描述效率,因为我们在软件层面不可能提高硬件性能,只能寄希望于设计出更高效的算法,而如果编写高效算法太困难甚至写不出,那就解决不了执行效率的问题了。


那么集算器用什么办法来达到这两个目标呢?

我们知道,计算机只能认识并执行形式化的程序语句。用计算机解决问题的过程,也就是把问题算法翻译成某种程序语言的过程,如果语言的语法体系和数据类型设计得不好,就可能发生把问题解法翻译成代码的难度大于解决问题本身的现象,也就是明明知道怎么做却很难写出程序来;有时候甚至真地写不出来,就出现明明知道有好的高效算法却无计可施,只能使用笨办法去低性能计算。


这种现象在结构化数据计算领域是普遍存在的,特别是对于很常见的过程式(需要多步骤才能完成)和有序计算。这主要是作为结构化数据计算的主流程序语言SQL造成的,我们举两个不太复杂的例子分别说明:

1. 找出一支股票最长连续上涨了多少天

这个问题对于Java或C++程序员来讲非常简单:做个初值为0的计数器,把数据按日期排序后遍历,发现上涨就将计数器加1,下跌则清0,最后看这个计数器出现过的最大值,这是个很自然的思路。但是用SQL就很困难,需要人为地制造出日期的序号后,再产生一个分组标志,把上涨的日期和前一天分成一组,下跌的日期分到另一组,然后计算最大的分组COUNT()值,这个思路下写出的代码也很长也很难理解。

2. 从10亿条数据中找出最大的前10名

熟悉算法的程序员都知道,解决这个问题不需要把10亿条数据全排序。只要产生一个有10个成员的空集合,然后遍历数据,过程中始终保持这个小集合是当前已遍历过数据中最大的10个,数据只要遍历一次,内存占用也很小。但SQL却很难甚至无法描述这个过程,逻辑上只能采用大排序后取前10名的算法,简单情况时还能寄希望于数据库系统在工程上的优化,而情况复杂就束手无策(比如有子查询和JOIN等情况)。

而这两个例子中的算法过程用集算器的程序语言都很容易写出来。


确切地说,集算器并不负责解决问题,想出(高效)算法是程序员的任务。集算器的任务就是提供更好的数据类型及相关的语法体系,使得编写这类计算更容易更简洁,更贴切人们的自然思维习惯。当然,这个目标也没有止境,集算器会一直向在这个方向努力,只要是能提高这两个效率的方法,我们都会尽量将其纳入到集算器的体系中去。