选择可用的计算机代数系统(CAS)?

cobranail

maxima可不可以输出求解的过程，比如求积分时做的每一步?

wildfire

Post by herberteuler;1833454
不太了解这方面的程序，但是貌似 Lisp 在这方面较 C/Python 要更适合一些吧，Maxima 不是 Common Lisp 写的么。呵呵，如果有错请指出。

实际上符号计算系统和数值计算系统在算法实现上是完全不同的。对于符号计算来说象 Lisp 这样的函数式编程语言有着天然的优势，这儿递归的概念起着很重要的作用，这一点对于实现符号推演几乎是度身定作，是其它编程语言无法匹敌的。尽管如今新的 CAS 系统大多用 C++ 等来实现，其中主要原因可能还是在于这些语言比较普及，界面也比较好写，毕竟 Lisp 程序员太少了，另外 Lisp 代码的可维护性估计也是一个因素，我曾经浅尝辄止地学过一点 Scheme，一行代码中十来重括号是家常便饭，编程思想也和传统语言迥然不同，所以很快就放弃了。（我不是学计算机科学的，没必要强迫自己硬着头皮受这份罪，呵呵）

反之对于数值计算来讲 Lisp 就几乎一无所长了，所以这儿还是 C/C++/Fortran 的天下，近来由于电脑硬件的飞速发展，象 Python 这样容易上手，扩展性也好的解释性脚本语言也能在此大展身手。

wildfire

Post by cobranail;1833616
maxima可不可以输出求解的过程，比如求积分时做的每一步?

据说 Derive 能一定程度地给出求解的中间过程，不过不要抱大的希望，它给出的过程肯定是你一想就能想到的，稍微要点创造性的推导绝对没门。就拿积分来说，符号计算程序都 hard code 了一张积分表，算的时候它先查表，然后根据一些给定的规则（就是你在数学手册里能找到的那些简单然而实质性的规则）来演化。这一点你用 Mathematica 做几个小实验就能清楚地看出来，同样算一个定积分，你先求不定积分再代入上下限要比直接求定积分快很多，原因就在于求不定积分时它能直接查表，再做一些简单的演化就能得到解析表达式，然后直接代入边界值就好了，而直接求定积分它则是先查一张定积分表（很小，只有一些很特殊的特例），假如查不到，它就按数值计算方法来算（看到这儿你是不是要晕倒了 ：）所以说符号计算看起来很神奇，其实和数值计算程序在使用上实质是一样的，人们只应该（也只能）让计算机程序做一件事，那就是简单，但繁琐、重复多次的运算。任何电脑程序的创造性都比不上人脑的一个零头。

herberteuler

Post by wildfire;1833684
实际上符号计算系统和数值计算系统在算法实现上是完全不同的。对于符号计算来说象 Lisp 这样的函数式编程语言有着天然的优势，这儿递归的概念起着很重要的作用，这一点对于实现符号推演几乎是度身定作，是其它编程语言无法匹敌的。尽管如今新的 CAS 系统大多用 C++ 等来实现，其中主要原因可能还是在于这些语言比较普及，界面也比较好写，毕竟 Lisp 程序员太少了，另外 Lisp 代码的可维护性估计也是一个因素，我曾经浅尝辄止地学过一点 Scheme，一行代码中十来重括号是家常便饭，编程思想也和传统语言迥然不同，所以很快就放弃了。（我不是学计算机科学的，没必要强迫自己硬着头皮受这份罪，呵呵）

反之对于数值计算来讲 Lisp 就几乎一无所长了，所以这儿还是 C/C++/Fortran 的天下，近来由于电脑硬件的飞速发展，象 Python 这样容易上手，扩展性也好的解释性脚本语言也能在此大展身手。

事实上 Lisp 程序的可维护性非常好。以我自己的感觉来说，Lisp 以外的语言写成的程序我需要稍长的时间来理解（比如说，几天到一周），但是 Lisp 写成的程序我几乎只要几个小时就可以理解。“括号太多”这个理由实在是太牵强了，找个好点儿的编辑器就可以解决掉这个问题；“编程思想”同传统语言迥然不同是因为相比于命令式编程语言（如 C/Python）Lisp 的函数式编程思想更接近于数学，而不是“计算机”。

至于数值计算，我不知道 Lisp 是不是“一无所长”。但是，有几点考虑使我认为事实可能不是这样的。首先，Lisp 内置了复数，对于数值计算并没有上限，而且对于实数有精确和非精确之分：

1. ;; Gambit 是一个 Scheme 解释器
   
2. Gambit v4.0.1
   
3. 
   
4. ;; 计算 -3 的平方根
   
5. > (sqrt -3)
   
6. +1.7320508075688772i
   
7. ;; 计算 1+2i 的平方根
   
8. > (sqrt 1+2i)
   
9. 1.272019649514069+.7861513777574233i
   
10. ;; 15 / 9 ：一个精确实数
    
11. > (/ 15 9)
    
12. 5/3
    
13. ;; 15 / 9.0 : 一个非精确实数
    
14. > (/ 15 9.0)
    
15. 1.6666666666666667
    
16. ;; 计算 2 ^ (256 * 12)
    
17. > (expt 2 (* 256 12))
    
18. 5809605995369958062859502533304574370686975176362895236661486152287203730997110225737336044533118407251326157754980517443990529594540047121662885672187032401032111639706440498844049850989051627200244765807041812394729680540024104827976584369381522292361208779044769892743225751738076979568811309579125511333093243519553784816306381580161860200247492568448150242515304449577187604136428738580990172551573934146255830366405915000869643732053218566832545291107903722831634138599586406690325959725187447169059540805012310209639011750748760017095360734234945757416272994856013308616958529958304677637019181594088528345061285863898271763457294883546638879554311615446446330199254382340016292057090751175533888161918987295591531536698701292267685465517437915790823154844634780260102891718032495396075041899485513811126977307478969074857043710716150121315922024556759241239013152919710956468406379442914941614357107914462567329693696
    
19. >

复制代码

当然，Common Lisp 也有类似的功能。这些都是无需加载任何附加程序库的。这说明，至少从大数计算/复数计算，以及精度上 Lisp 都不会有问题。

其次，以我从网上看到的一些论文来看，Lisp 的速度也不慢。例如，这篇论文介绍的：
http://delivery.acm.org/10.1145/ ... mp;CFTOKEN=24881331

最后，NASA 的卫星上使用的（至少一部分程序）也是用 Lisp 写的，这些程序对数值计算的要求也不低吧。

有一种可能，就是我所看到的信息都是错误的，但我觉得这个可能太小。

最后我想说明，我不认为 Python 比 Lisp 更容易上手，也不认为 Python 的扩展性比 Lisp 好。这些当然都是我自己的观点。

pointer

个人以为 LISP 的快慢在于其语言核心, 查表操作太多, 所以递归应该不太高效---不是很清楚

其实个人以为最好的语言是C, 高级语言是计算机的一种抽象, 抽象层太厚就像虚拟机, 肯定影响速度, 还加大复杂性, 太简单, 则成了一种机器语言. C最需要的是的库, 而不是各种 ++ --.

但对使用CAS, 重要的是已经有了什么, 这方面LISP是无与伦比的

herberteuler

Post by pointer;1834138
个人以为 LISP 的快慢在于其语言核心, 查表操作太多, 所以递归应该不太高效---不是很清楚

其实个人以为最好的语言是C, 高级语言是计算机的一种抽象, 抽象层太厚就像虚拟机, 肯定影响速度, 还加大复杂性, 太简单, 则成了一种机器语言. C最需要的是的库, 而不是各种 ++ --.

这两个观点，“查表操作太多、递归不高效”，以及“最好的语言是 C”，都没有出现在一个特定的上下文中，所以都不太正确。

没有“最好”的语言。只能说，对于某种应用，一种语言比其他语言更适合。虽然像 Python、Java、Lisp 这样的语言做了许多抽象，从而导致其性能可能会有所下降，但这并不能使 C 这种抽象机制并不丰富的语言成为最好的语言（当然，那些语言也不是最好的）。抽象的好处在于，能够使人在更高的层面上思考问题。当要处理的问题本身就比较底层时，C 会较比 C 高级的语言更合适，但是这也并不绝对。如果该问题太过底层，甚至 C 的抽象机制都太多，C 也就不是适合的语言了。

在 Lisp 中，所有的数据_有可能_全部使用表来表示，但这并不是必须的。Lisp 同时提供了 vector（数组）和 hash table 等数据结构来解决某些场合的问题。此外，表也并非在任何情况下速度都比数组慢。比如，树的结点之间相连的方式同表相同，但要在树中添加或删除元素比数组要快。

有两种形式的递归，用 C 的形式来书写，它们是

1. unsigned int
   
2. fact1 (unsigned int n)
   
3. {
   
4.   if (n > 1)
   
5.     return n * fact1 (n - 1);
   
6.   else
   
7.     return 1;
   
8. }
   
9. 
   
10. unsigned int
    
11. fact2 (unsigned int n, unsigned int r)
    
12. {
    
13.   if (n > 1)
    
14.     fact2 (n - 1, r * n);
    
15.   else
    
16.     return r;
    
17. }
    

复制代码

这是两种本质上完全不同的递归，后一种同迭代效果相同，被称为尾递归。在 C 中尾递归的效率可能不高（我不太清楚有哪些 C 编译器能够做尾递归优化），但好的 Lisp 编译器会将尾递归编译成类似 goto 的形式，这和 C 中的 for 语句实际上是一样的。“递归的效率不高”，指的是前一种递归，不过这种递归在 C 中效率也不高。

mingyou

关于CAS类程序的中文文档还是偏少的吧。

mingyou

maxima的那几个中文介绍都还不错。

pointer

我想用CAS的大多是大学生及以上学历, 英文文档应该都可以看懂吧.

herberteuler 兄说得不错, 事无绝对, 但C自由度高一些, 做事也就麻烦一些.
C程序的效率高度依赖程序员, 不想LISP会自己做尾递归优化.

另外函数调用的开销也是依赖于硬件平台的, 记得就有平台开销很大, 此时编译器会展开很多函数调用.

我并不希望看到有太多的语言, 但大家喜欢的又不一样, 有人希望消失的Java, 有人希望消失的是Perl, 诸如此类, 很难统一.

也许以后学计算机语言就像学自然语言一样, 有翻译器做这些事, 人们通常只需要学一种语言.

mingyou

XMaxima在Linux下的显示效果太差了，几乎到了可以影响数学式准确性地步了。
实在不建议使用。
而传的很神的Texmacs加maxima同样不建议使用。一是目前版本的texmacs不支持最新的5.14.0版的maxima，二是即使支持，稳定性方面也无法保证。
建议一般应用时，选用konsole等终端直接在字符界面下启动maxima，非常可靠，显示效果也要强于xmaxima。如果追求美观的话，还是用emacs+imaxima吧。