On Thu, Jul 6, 2023 at 4:15 PM David Bailey <d...@dbailey.co.uk> wrote:
>
> On 05/07/2023 21:40, Aaron Meurer wrote:
> > For interactive use, just passing a string to S() (or equivalently
> > sympify() or parse_expr()) is the simplest way to deal with this.
> > However, I would avoid this for non-interactive usage (i.e., any code
> > that gets saved to be executed later). Putting your expression in a
> > string breaks the ability for Python to parse it directly, meaning
> > things like simple syntax errors won't be caught until the code gets
> > run.
> >
> > You should also be very careful when doing this if you use
> > assumptions. S("x + 1") will create a symbol x with the default
> > assumptions. If you already defined x with assumptions, like
> >
> > x = symbols('x', real=True)
> >
> > then this will be a *different* symbol. For example:
>
> Thanks for that caution, Aaron,
>
> This whole problem reminds me vaguely of a friend of mine that bought an
> early Sinclair calculator. He discovered that ln(2) was seriously
> inaccurate, so he wrote to them. They replied that there was nothing
> wrong with his calculator, he had just chosen an unfortunate example!
>
> What I'm trying to say is that there must be people out there who gave
> given up on SymPy after discovering what it does to 1/2*x, or worse
> still, got an error in their work (particularly if using Python 2).
No one should be using Python 2 at this point. So fortunately that
particular headache is behind us.
>
> Thinking about it, I can see how hard it is to do something really
> effective about this problem, but couldn't you prevail on the Python
> term to insert a hook in the Python parser to make it possible to change
> an input string before Python parses it and applies its integer division
> rule?
That particular way of solving the problem would very likely be
rejected. It's basically equivalent to adding macros to the language,
which has been rejected multiple times before.
I have wondered if it wouldn't be possible for Python to keep track of
how purely numeric constants are created at compile time and store
that information on the constant. Since it would only apply to pure
numbers and would only happen at compile time, it would have basically
no runtime penalties. That would also allow something like
1.0000000000000000001, which automatically truncates to 1.0, to create
sympy.Float('1.0000000000000000001'). But it's only a vague idea I've
ruminated on and I haven't written to the core Python team about it.
Aaron Meurer
>
> 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/d6b19b21-d61c-e4f8-3116-f5f64ac6ab48%40dbailey.co.uk.
--
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%3D6LXNmwPMEc8Kaixa0dxrd3bV8R%3DHJQxXqSz43w3aXu8nQ%40mail.gmail.com.
