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:
*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.
