为什么会有MathCAD Prime？兼答zpz老师
本帖最后由 朱老剑客 于 2013-2-20 19:41 编辑原文网址：
http://blog.163.com/zhu_xinyan@yeah/blog/static/106916534201312002621973/
网络上对MC和MP的问题挺多的，比如说MP作为升级版，很多功能还不如MC呢，比如Win7旗舰64bit下MC出现了计算错误，比如说3D图形的显示等等。我查了PTC官网上的一些解释，包括用户社区和开发者论坛，口径一致的说MP就是MC的升级版，而且推荐使用MP，MC将不再升级，总之这些是瞎话，但到现在为止还没有哪个国家的人指出这些确实是瞎话。所以我下面说的话也就找不到佐证了，只能拿出我找到的一些证据以及分析来说明“这些确实是瞎话”，顺便能够解释一些网络上经常提到的问题吧。
（一）
首先要明确的是MC和其他M系列软件的最大区别，在MC中写下来的是解释语言，在其他M系列软件写下来的是编译语言。所有的问题的根本就出在这里。
MC的最大特点就是它的程序界面是像积木一样的区域化编辑界面，我们可以很自由的移动这些区域，组成自己想要的UI，它给提供了一张白纸，我们在上写算草。在这个界面里，我们可以同时把任意多的图形并列的放在一起，同时观察变量对各个图形的影响；我们可以非常自由的同时计算任意多个程序组，以比较筛选出最优算法……这都是解释语言界面的优点——自由，如果再加上脚本程序的使用，就等于无限的拓展性！MC界面的规则只有一个：“从上到下，从左到右”。
而编译语言则限制很多了，它需要用户提供具体的操作符，有特定的复杂语法，一个“:”或一个“;”用错了，你就不能执行你的程序，只能一行一行的编写程序，要同时看好几程序的比较，只能通过软件自带的扩展包或者使用特定的编程语句。所有的模板都是死的，要想构建自己的应用程序UI，只能使用Visual系列的编程工具或插件来实现。
解释语言的缺点是，执行程序时，系统需要利用“从上到下，从左到右”的规则一点一点儿的解释所有区域，边解释边执行，每次解释都要用一次CPU，把每次执行结果都放在内存里，调用程序计算内核进行计算，再编译为计算结果返回用户界面。慢！
而编译语言则是将所有命令行作为一整块进行编译，调用程序计算内核进行计算，再把计算结果通过编译返回到用户界面。快！
比如说1+1=，在MC里被认为是一个区域，包括“1，+，1，=”四个子区域，每一个子区域都要进行解释、执行、计算、编译，然后形成“2”再编译返回给用户界面；在Matlab中，等号可以忽略，“1+1”被作为一条完整的命令进行编译计算，得到“2”之后再编译返回给用户界面，如果你要使用TeX风格显示结果，在命令行里给出“print::type:TeX”之类的语句，它将与“1+1”一块儿作为一条完整的命令编译执行。
鱼和熊掌不能兼得。想要自由，就得牺牲速度；想要速度，就得想使用C、ForTran一样进行数学计算。而21世纪的数学软件发展趋势是“更高更快更强”，使人们更充分的享受到计算内核程序的强大功能和高配置计算机的优越性。人们关心的是数学软件在PC机上可以实现多大规模多么复杂的建模计算，可以同时控制多少亿的点阵，而不再有人过问它是否好上手是否容易使用了。所以用解释语言的MC在大客户商圈里是没有竞争力的，是买不出好价钱的软件。
那么，有没有既能够自由使用，又可以保证计算速度的数学软件呢？目前没有。但据我查找，世界上很多软件开发商都在朝这个方向努力。大概有4种做法：
（1）自己创造编程语言，再用它来编写软件。比如MicroSoft就是这么做的。
（2）不断的丰富自己的知识库、类库、插件库来强大自己，并且发动全世界的人来共同做这件事情。比如Eclipse就是这么做的。
（3）发扬一不怕苦二不怕累死的革命精神，针对每一个大用户或特定工程计算领域量身定做一套的特别的计算内核程序。比如Modelica就是这么做的。
（4）不玩儿了！推倒重来，只是还沿用以前的牌子。比如MathCAD就是这么做的。
嗯，以上就是MathCAD Prime诞生的背景。
（二）
打开MC的安装目录，你会发现一个很有意思的文件夹，“MuPAD”，嗯，这是MathCAD的计算内核。而且，如果你还安装了MuPAD Pro4的话，你会很容易发现，share文件夹中lib，MuP的共享程序库与MC的计算核心程序库从文件夹、文件名上看是完全一样的，这是MuP给Matlab提供的服务库，只是版本上不同。MuP在出了pro4之后就不再发表独立软件了，它专心的去做计算内核程序，为Matlab等大型数学软件提供符号运算内核。MC15M020的MuPAD内核要比MuPPro4的共享程序库先进好几个版本，这个版本和Matlab R2012b的MuPAD版本是一样的。
但同样的符号运算内核，MC为什么会得到与其他M系列软件不完全一样的符号运算结果呢？原因还是在解释语言上。MC对表达式逐个区域进行解释，发送给MuP，MuP使用lisp宏程序（形成或调用lisp方言）对逐个区域进行运算，然后返回给MC，一般情况下，这个过程和编译语言的把表达式整体编译之后输送给MuP使用lisp宏程序进行统一运算再返回的计算结果是一样的。
只有在当逐条解释的过程中，局部的或者错误的引用了lisp宏程序，这种情况下，才会返回不一样的结果。
打个比方，解释语言是个口吃病患者，编译语言是个说话正常的人。向别人道歉，编译语言会说：“我说的对不起。”，解释语言会说：“我说的对……对……对不起！”然后lisp就发生了误会。
在Windows早期版本里，还有一些回旋的余地，当lisp发生误会的时候，同时出现了几条解决宏程序，按照Maxima（MuP、Maple、Mathematica的内核）的“保持最简”原则，各条宏程序运行之后，它会选择最简的那个结果作为输出结果，这样往往不会发生大错误。但这个误会在Win7之后就更麻烦了，Win7旗舰64位（Win8没用过）中的安全策略是发现危险宏类程序（比如说并发宏）自动阻挡，具体是哪个升级包具有这种功能我就不清楚了。
另外，在编译语言的M系列软件里，你可以通过命令行直接给MuP发布指令，相当于自定义lisp宏程序，强制它来按照自己的想法完成一系列运算，这种自定义的本地宏程序是Windows许可的，被认为是安全的。而这个“自定义”在解释语言里也是没法做到的，它只能遵守计算内核程序包里的既有规则，使用固定的那么几个lisp宏。
嗯，接着，Win7给PTC一个很大的冲击，这个在PTC的MathCAD社区里讨论了不少。同样都有MuP内核，同样花了那么多钱买它，但用户却不能同样的享受到MuP的专业精神！那还留着MuP干什么？！
要不就放弃调用外部计算内核，自力更生，这样就减少了发生解释误会的风险，只是路漫漫其修远；要不就彻底改变用户界面，把区域编辑界面改为命令行界面，用编译语言而不用解释语言——那么，MathCAD还能叫做“MathCAD”么？
好了，下面，请打开MathCAD Prime的安装目录，你会发现MuPAD的文件夹没有了。
没错，MP使用的是PTC自己的计算程序内核。可问题又来了，首先，最致命的，不能完全避免发生解释错误，因为符号运算最终都是lisp语言层的操作——就像ASCII码和汇编一样古老，并发宏的问题仍然会出现。在这次MP的革命中，PTC仅仅是节省了一大笔购买MuP的经费。
其次是出现了新的问题。原来调用别的计算内核的时候，MC只是一个面具，无论你对这个外壳怎么修理，都不会伤害内核程序。除了MuP之外，还有方程求解器等其他的外挂计算内核，还有对Windows提供的API的引用功能等等，在MP里都不要了，取而代之的是PTC自己或者旗下公司开发的计算内核。所以，MP的解释层要比MC的薄很多，运行速度确实快了不少，但也就脆弱了不少。为了保证主程序的安全，很多在MC里常用的操作在MP里都没有了，比如说插件和控件，比如说编译成dll文件，比如说实时符号运算功能（符号表达式实时优化，这个在MC15里也是被禁用的，但偶尔可以调出来，看运气），比如说编程的时候需要对变量进行初始化（它在调用自己主程序所在的内存，已不再有什么壳给这些编程进行预处理之后再调用外部命令了）。MC开发人员参考、作者参考里说的所有东西都被禁用。这还不够，3D绘图不是要引用Windows的API么？字符集不是要调用Windows的Unicode表么？嗯，都给禁用了。所以你在MP里写好的东西，不可能插入到word里。
MC通过VBScript、JavaScript可以做到无限的扩展性，比如说我给AutoCAD编一个MC仿真插件，让AC动起来，没问题，可以做到，但MP不能。
MP做到的仅是提供了大量的使用了21世纪新算法的新函数来弥补缺少外部计算内核的不足，对大客户和老客户们有了一个交代。
那么MP岂不是失败了？至少现在看是这样的。但不管咋说，这种完全独立的大型数学软件也很有可能成为“成功的第三方”，它可以安排一些其他M系列软件中不常用或者用起来很麻烦的功能。不知道，只要MP继续开发，现有的毛病都会克服的。
只是我不看好MP的未来，这是由于PTC对MP的定位，它被定位为Creo的插件，一个完全内部化的东西，与MC的开放路线完全相反。说来这也对，PTC的主打是Creo系列，这个最能卖钱。而数学软件商太多了，解释语言的数学软件也不是主流，PTC需要的就是完全为自己软件服务的数学计算引擎，自主知识产权的计算内核，可以很好的保住自己的技术秘密。
PTC的目标是形成像NI、MSC系列的成套的东西，而且做得更绝，不使用Modelica这样的通用工程库，而是自己开发一套工程库，Knovel系统。所以SmartSketch、VimSim在PTC从MathSoft公司购进了MathCAD的同时就义无返顾的与MathCAD决裂了。
还有Windchill系统，PTC使用Windchill系统整合了它的所有产品，并利用Internet平台进行广泛的世界级的技术合作。针对Windchill，我和PTC的国内代理电话过几次，最终还是不敢使用这个系统。PTC的想法很好，但不现实，任何企业都有自己的技术秘密，能够放到网络上的一般都是无关痛痒的。
（三）
最后说说MathCAD的未来吧。PTC既然已经决定不再升级MC了，那么MC是不是就这么死掉了呢？很简单，不会。人们是不会放弃一个用的顺手，可以单纯的用简单的数学知识就可以解决几乎所有问题的，而且界面自由、功能几乎无限的，这么好的软件的。世界几所不错的大学都在开MC的课程，而且在网络上发起了校园论坛，尽管人们对MP有不少怨言，但对MC的开发正在默默的进行着呢。
Kornucopia，这是我在网络上找到的唯一一个专门为MC编写高级算法的dll和xmcd文件的公司，很小的程序包，价格不菲。其他的都是以个人、民间组织的名义进行“开源活动”，一点点的丰富MC的函数库和编程法。有意思的是，PTC公司的工作人员也在MathCAD社区里发起了探讨MC usage的运动，他们表示虽然这个软件的代码他们都能够背下来，但仍旧时常的被一些新的发现所感动。这我想应该感谢lisp语言的博大精深。
国内有几家公司专门做MC程序的扩展项目，比如说给某个控制系统编个计算插件，用VisSim实现复杂的动态仿真等等。
我对编程知之甚少，我只是也想参与到这个民间运动里，利用我的博客也发布一些我觉得有意思的xmcd函数文件，可以通过相对引用功能来调用到各位自己的工作表里直接使用。说不定如果找到志同道合的人，也会组织个公司玩玩儿的哈。
先生思想敏锐，知识渊博，逻辑严密，见解新颖。拜读本文之后，使老朽有醍醐灌顶之感。
好文章，好见地，谢谢你！ 学习了，一直不知道这些软件有这么多的内容 看来MATHCAD没盼头了 本帖最后由 gps99 于 2021-10-31 15:55 编辑
这帖子9年了，，，，现在看mathcad prime 7.0还是一贯的半死不活:lol
将MP当作一个主流math软件，目前看来是完全不够格的，与Maple MMA Ml差距越来越大。从望其项背，到尾灯都看不见。。。。当然PTC也没打算MP成为典型的math软件，PTC体系内的一个计算插件就OK了
最后说说MathCAD的未来吧。PTC既然已经决定不再升级MC了，那么MC是不是就这么死掉了呢？很简单，不会。人们是不会放弃一个用的顺手，可以单纯的用简单的数学知识就可以解决几乎所有问题的，而且界面自由、功能几乎无限的，这么好的软件的。
页:
[1]