On 5 April 2016 at 17:15, Aaron Meurer <asmeu...@gmail.com> wrote: > On Tue, Apr 5, 2016 at 6:19 AM, Oscar Benjamin > <oscar.j.benja...@gmail.com> wrote: >> >> I though that it should be possible to easily do this with sympy >> Floats but it doesn't seem to work: >> >> In [1]: x = S(1.4142) >> >> In [2]: x >> Out[2]: 1.41420000000000 >> >> In [3]: x**6000 >> Out[3]: 1.16144178843571e+903 >> >> In [4]: x**6000 % 400 >> Out[4]: 32.0000000000000 >> >> This doesn't work because auto-evaluation of x**6000 destroyed all the >> precision so I tried: > > No, it's because the default precision is 15. I didn't realize you > needed a precision of 950. If you do what I did above with that you > get the right answer > > In [6]: x = Float("1.4142", 950) ...
It is because of the auto-evaluation in the sense that there were enough digits to exactly represent all the input numbers but the auto-evaluation cheated me from specifying how many digits to use for the exponentiation with evalf later. I think that inexact auto-evaluation should be disabled by default. Explicitly calling .evalf() serves as a useful reminder of the numeric approximations that have occurred in the calculation and should be required for this. >> So let's disable evaluation of at the mod step as well: >> >> In [10]: Mod(Pow(x, 6000, evaluate=False), 400, evaluate=False).evalf(50) >> Out[10]: >> ⎛ 6000 ⎞ >> Mod⎝1.4142 , 400⎠ >> >> How do I get that to actually evaluate? > > expr.doit() will evaluate the expression, but it evaluates it using > the prevision of x. For your x, that's 15, so you get the wrong answer > 32. If you set x = Float("1.4142", 950) you get the right answer. Is there a reason for not evaluating this when evalf is called? ... > > I don't know if it should be considered a bug, but it's worth noting > that if you want SymPy to give the right precision in general you have > to start with Float objects that are set with the precision you need. > To me it feels like a bug because it negates the purpose of the evalf > precision argument. Is there a coherent policy on float-handling in sympy? My ideal would be: 1) All float objects are created exact (having the exact value of the object passed in). 2) No inexact auto-evaluation. 3) .evalf() can be used to fully evaluate the expression with desired precision. 4) Ideally the precision argument to .evalf would be the precision of the *output* rather than the internal precision of the intermediate calculations Currently 1) already occurs for decimal strings but Float(float) rounds to 15 digits and you can explicitly force something impossible as a ratio string: Float("1/3"). I think Float should be more like decimal.Decimal here: all input arguments are treated as exact regardless of precision etc. (and I don't see any good reason for allowing Float("1/3")) Without 2) it is impossible to achieve 3). If approximate auto-evaluation can occur before calling .evalf then there's no way for evalf to set the precision to be used for the auto-evaluation. Obviously 4) is harder than current behaviour and perhaps impossible in general but it is achievable for simple cases like in this thread. >From a user perspective it is definitely what is actually wanted and much easier to understand. -- 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 post to this group, send email to sympy@googlegroups.com. Visit this group at https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxRxmU9wrh__88Jw0ERkht3BPzFjo_cu3_iuvRdJdy_BrA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.