On Sun, Sep 3, 2023 at 11:43 AM emanuel.c...@gmail.com
<emanuel.charpent...@gmail.com> wrote:
>
> [ 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)…
SymPy already has an evaluate(False) context manager. But that doesn't
really solve the fundamental problem, which is that virtually every
algorithm in SymPy is written expecting evaluation. If you search the
issue tracker, you'll find hundreds of issues with various things that
don't work when you disable evaluation. Quite a few of them come from
just from printing, meaning the user isn't even really trying to do
anything with the expression. Basically, evaluate=False or 'with
evaluate(False)' only "works" in the very technical sense. If you
actually try using it it will lead to an endless number of bugs and
unexpected behavior.
Basically, when evaluation happens all the time and certain invariants
about expressions always hold, then functions are written assuming
those invariants. It isn't even done intentionally most of the time.
The only way out of this is to have a core that never evaluates in the
first place, so that code written against it will never assume
evaluation.
Aaron Meurer
>
> Le vendredi 1 septembre 2023 à 14:56:09 UTC+2, gu…@uwosh.edu a écrit :
>
> Take a look at SageMath (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)
> cortex-js/compute-engine: An engine for symbolic manipulation and numeric
> evaluation of math formulas expressed with MathJSON (github.com)
> 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.
--
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/CAKgW%3D6KAtE%2BNWKLg6-FSQANHpzhsB3tC9p9ON0GBshjncyaxPw%40mail.gmail.com.
