[ Sagemath user and small-time developper here… ]
As far as I can tell, Oscar’s points are right on the spot. I’d second them
with a remark : more generally, the user-visible functions and the
algorithm implementations should be more separated in distinct layers, the
“translation” between external (user-visible) representations and internal
implementations of the same objects being *impliicitely* handled.
His point about the toxic side-effects of automatic evaluation is right.
However, I note that this can be (at leas partially) *simulated* now, via
the evaluate keyword accepted by numerous Basic functions and methods :
>>> from sympy import cos, pi, sqrt, sympify >>> cos(pi/3) 1/2 >>>
cos(pi/3, evaluate=False) cos(pi/3) >>> sympify("sqrt(4)*cos(pi/3)") 1 >>>
sympify("sqrt(4)*cos(pi/6)", evaluate=False) sqrt(4)*cos(pi/6)
I wonder if this problem could be handled with a auto_evaluate context
handler, signalling to the symbolic expression system that the automatic
evaluation is not allowed at this stage. Of course, you should have a tool
to evaluate unevaluated expression (analogous to thehold/unhold mechanism
available in large parts of Sage or the quoting/nouns mechanism
(contraption…) of Maxima)…
Le vendredi 1 septembre 2023 à 14:56:09 UTC+2, gu…@uwosh.edu a écrit :
Take a look at SageMath <https://www.sagemath.org/> (
https://www.sagemath.org/), which does pulls together lots of disparate
packages. I have used it and even contributed to it. I recommend it for
people doing pure math or sophisticated niche work. However, It has
historically been too heavy-weight and difficult to use correctly for the
applications I have in the physical sciences and teaching. They are working
towards making installable with pip, which may help with some of my issues.
One non-trivial issue of Sagemath is that a large number of the packages it
uses are Unix-only ; this “weds” Sagemath to Unix (in the Catholic +
shotgun version of “wedding” : don’t even *think* of divorce…). Since a
generation of potential users have been force-fed Windows as their primary
interface with computers, this may be a problem…
A Cygwin version of Sagemath has long been (heroically !) maintained, but
this effort has been recently stopped. The recommended way to run Sagemath
on Windows is nowadays to install Windows Subsystem for Linux version 2,
install a Linux distribution, then install Sagemath from source on this.
None of this is especially difficult, but Windows users are in for a
serious cultural schock… Furthermore, this may disrupt the integration of
tool chains end users are used to. If you are used to integrate
computational results in documents (e.g. via markdown/pandoc, R’s knitr or
emacs’ org-mode), you’d better use a Unix version of your tools, creating
some Windows-to-Unix bridge scripts if necessary.
Nevertheless, this might be (*is*, IMNSHO) worthwile : the range of
mathematical tools accessible via Sage is astounding. BTW : this includes
Sympy ;-), as well as some proprietary tools such as Magma, Mathematica,
Maple or Matlab. Having one central software and language to access all
these tools is indeed precious.
Jonathan
On Thursday, August 31, 2023 at 8:57:57 PM UTC-5 syle...@gmail.com wrote:
Thanks for the blog post.
Unfortunately, I'm outside from using SymPy recently because
I'm now mainly involved in projects that use React and Typescript heavily,
However, I particularly find things like mathjs
josdejong/mathjs: An extensive math library for JavaScript and Node.js
(github.com) <https://github.com/josdejong/mathjs>
cortex-js/compute-engine: An engine for symbolic manipulation and numeric
evaluation of math formulas expressed with MathJSON (github.com)
<https://github.com/cortex-js/compute-engine>
to be interesting, and had got me the impression that
small symbolic expression system, without automatic evaluation, is still
very useful by itself.
And although SymPy, being fully featured CAS, with many features, easy to
use,
had not got a good reputation that it is best at something, or it is best
at anything at all.
It seemed like having having CAS not being best at performance or
having it too opinionated and limits about what kind of math it can do,
pushed me away from using general computer algebra systems,
to more dedicated matrix, algebra, polynomial libraries.
However, I just want to tackle that this problems may come from monolithic
software designs of computer algebra systems.
Although `arb`, `flint` or `gmpy` achieves best performance at one specific
math,
However, they don't really seem like restricting what you can build on top
of it.
I have got a similar opinion, that CAS should be minimal like basic
operating system that only connects the modules,
and start to have the boundary of what should be inside it or what should
be built on top of it.
On Monday, August 21, 2023 at 3:35:01 PM UTC-5 da...@dbailey.co.uk wrote:
On 21/08/2023 21:01, Aaron Meurer wrote:
Thanks Aaron for your amazingly fast response!
> The main reason Oscar benchmarked matrices is that that's the part of
> SymPy that he's focused on making faster so far. Actually, matrices
> are more important than you'd think. They end up being used internally
> in many calculations, in places like the solvers or integrals, so
> making matrices faster will also make other parts of SymPy faster.
>
> But actually, matrix inverse and your series example are very similar.
> They both produce unwieldy expressions when computed naively. But
> these expressions are much simpler if they are simplified:
If Oscar had mentioned that, I would never have written that reply -
perhaps he forgot that he was not talking to a SymPy developer!
Is there a readable account explaining how the internals of SymPy
perform their algebraic/calculus manipulations?
David
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/a14e9400-6bcd-4a9a-9e1b-ebcf0de6aafdn%40googlegroups.com.
