On Fri, May 14, 2021 at 3:04 PM Oscar Benjamin
<oscar.j.benja...@gmail.com> wrote:
>
> On Fri, 14 May 2021 at 21:33, Aaron Meurer <asmeu...@gmail.com> wrote:
> >
> > On Fri, May 14, 2021 at 1:59 PM gu...@uwosh.edu <gu...@uwosh.edu> wrote:
> > >
> > >
> > > I want to second Aaron's comment. Please just use
> > > `sympy.init_session(auto_int_to_Integer=True)` if you want that behavior.
> > > As a scientist who uses python to process large data sets I do not want
> > > it to bog down trying to do exact calculations. Most datasets only have a
> > > few significant figures anyway. Python should not be changed.
> > >
> > > However, I think there could be a fruitful discussion of whether sympy
> > > should by default cast integer input to sympy integers. I personally
> > > prefer that behavior, so set it when I am doing something where I care.
> >
> > SymPy already does pretty aggressively cast all input types into SymPy
> > types. The issue is that in something like 1/2*x, Python evaluates
> > this as (2/3)*x, where the 2/3 part is completely Python types, so it
> > gets evaluated before we have any control over it. It is only when the
> > "*x" part happens that SymPy is able to cast it to a SymPy type, but
> > by then, it has already gone through the inexact division. This is why
> > instead doing 2*x/3 does create an exact result, because this is
> > evaluated as first 2*x, where the Symbol('x') is able to cast the 2 to
> > a SymPy Integer type, then the /3 is able to be divided by this SymPy
> > type and SymPy can do the division exactly.
> >
> > This is only an issue for division of integers because it's the only
> > operation on Python types that loses precision. Something like 2*3*x
> > also works the same way where the 2*3 is evaluated by Python first
> > before it gets to SymPy, but in that case, it doesn't matter because
> > the answer is exact, even for large integers.
> >
> > This is just the way Python works. It is an eagerly evaluated
> > language. There's not much we can do about it as a library.
>
> There is an obvious fix that SymPy could do but it wouldn't be backwards
> compatible. I think it would be better if sympifying a float used nsimplify
> to convert the float to a Rational. Users are stung by the problems of Float
> all the time just from either using integer division but also from thinking
> that an expression like 0.5 or 0.1 should be exact. It's not hard to make
> this change in SymPy:
This would work for simple cases, but since the float is an
approximation, there would always be cases where it would guess the
input incorrectly. From the Zen of Python, "In the face of ambiguity,
refuse the temptation to guess."
Here's an example of a handheld calculator that does this sort of
thing, and the sorts of weirdness it can cause
https://www.youtube.com/watch?v=7LKy3lrkTRA.
Aaron Meurer
>
> diff --git a/sympy/core/sympify.py b/sympy/core/sympify.py
>
> index ed5ba267d9..23250877e5 100644
>
> --- a/sympy/core/sympify.py
>
> +++ b/sympy/core/sympify.py
>
> @@ -353,6 +353,12 @@ def sympify(a, locals=None, convert_xor=True,
> strict=False, rational=False,
>
>
>
> if isinstance(a, CantSympify):
>
> raise SympifyError(a)
>
> +
>
> + if isinstance(a, float):
>
> + from sympy import nsimplify
>
> + from sympy.core.numbers import Float
>
> + return nsimplify(Float(a))
>
> +
>
> cls = getattr(a, "__class__", None)
>
> if cls is None:
>
> cls = type(a) # Probably an old-style class
>
>
> With that we get e.g.:
>
> In [2]: 1/2*x
>
> Out[2]:
>
> x
>
> ─
>
> 2
>
>
> In [3]: 0.5*x
>
> Out[3]:
>
> x
>
> ─
>
> 2
>
>
> In [4]: from math import sqrt
>
>
> In [5]: sqrt(2)
>
> Out[5]: 1.4142135623730951
>
>
> In [6]: sqrt(2)*x
>
> Out[6]: √2⋅x
>
>
>
> --
> Oscar
>
> --
> 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/CAHVvXxQQiHfcDSSCmi8w_4iz0817ym%2BpavuFMtR-A3EJaS3Pzw%40mail.gmail.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%3D6K4TvQ7gJ5xTxDY2XSzJgwKkRugq-rphBjRVn47Z%3DO%2B7g%40mail.gmail.com.
