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.

Reply via email to