On 9/4/2023 11:38 PM,
clicliclic@freenet.de wrote:
A devastating insider critique of SymPy:
<https://oscarbenjamin.github.io/blog/czi/post1.html>
Wow,
Martin.
When author says
"What SymPy needs is a symbolic subsystem that is not based on automatic evaluation"
I am confused here. Isn't the standard for CAS systems to do automatic evaluation?
That is what Maple and Mathematica do.
i.e. When one writes
x:=1;
y:=sin(x);
Then y automatically evaluates to sin(1). Having to do
y:=sin(eval(x)); each time on each subexpression to evaluate it
is not practical.
Even when setting x:=1 afterwords, then y automatically becomes sin(1):
restart;
y:=sin(x);
sin(x)
x:=1;
y;
sin(1)
May be I misunderstood what is being said here. How will a CAS system
based on not automatic evaluation look like? are there such CAS
systems out there now?
I think the problem with sympy and all other such CAS systems
is that they are not build from the ground up using symbolic language.
They are an add on top of a non symbolic language. Python
is not symbolic language. Same with Julia, same for the symbolic
toolbox added to Matlab. Matlab is not symbolic language.
Same with sagemath symbolics. It uses Python which is not symbolic language. Same with giac. It is uses C++ which is not symbolic.
To do CAS system right, the base system/language itself must be symbolic.
Adding a layer of symbolics on top of foundation which is not symbolic
will always be awkward and feel not natural even though it "works" since
the base language itself is not symbolic.
It is the foundation what is important. Not the top floors.
my 2 cents ofcourse.
--Nasser
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)