Hi,

On 23 September 2013 20:12, Heiner Kirchhoffer
<[email protected]> wrote:
> Hi Aaron and all,
>
> Maybe, P can be negative? This would require a float or maybe better, a
> Rational.
>
> After studying the related code from a pure syntactical point of view
> (without knowing the mathematical concept behind), I would like to discuss
> two changes which could maybe solve the problem.
>
> In function "dup_root_upper_bound()" in file "rootisolation.py", change the
> return statement from
>         return 2.0**(max(P)+1)
> to
>         return Rational(2)**(max(P) + 1).
>
> In function "dup_root_lower_bound()" in file "rootisolatin.py", change the
> return statement from
>         return 1.0 / bound
> to
>         return Rational(1) / bound.
>
> Of course, Rational needs to be imported as well.
> The places where dup_root_lower_bound() is called should handle the change
> from float to Rational correctly.
>
> The changes are relative to the latest version from git.

This is a good idea. I created a pull request fixing this issue:
https://github.com/sympy/sympy/pull/2481.

> By the way, thank you for the link, I will try to avoid using strings for
> this purpose in future.
>
> Best regards,
> Heiner
>
> Am Freitag, 20. September 2013 19:32:42 UTC+2 schrieb Aaron Meurer:
>>
>> I guess we just need to look at why it uses floating point 2.0 instead
>> of 2, which would work just fine.
>>
>> By the way, it's better to build up expressions using Symbols instead
>> of using strings. At the very least, don't assume that arbitrary SymPy
>> functions will convert strings to expressions. See
>>
>> https://github.com/sympy/sympy/wiki/Idioms-and-Antipatterns#strings-as-input.
>>
>> Aaron Meurer
>>
>> On Fri, Sep 20, 2013 at 10:28 AM, Ondřej Čertík <[email protected]>
>> wrote:
>> > Hi Heiner,
>> >
>> > On Fri, Sep 20, 2013 at 9:39 AM, Heiner Kirchhoffer
>> > <[email protected]> wrote:
>> >> Hello,
>> >>
>> >> some months ago I started using sympy for finding roots of polynomials.
>> >> It works really well and it enables me to solve more and more
>> >> complicated
>> >> problems.
>> >
>> > I am glad SymPy is useful to you.
>> >
>> >>
>> >> Recently, I observed a case where the function sympy.intervals(...)
>> >> throws
>> >> an "OverflowError" exception.
>> >> It happens when executing the following commands:
>> >>
>> >> import sympy
>> >>
>> >> a = "(x**45 - 45*x**44 + 990*x**43 - 1)"
>> >>
>> >> b = "(x**46 - 15180*x**43 + 9366819*x**40 - 53524680*x**39 +
>> >> 260932815*x**38
>> >> - 1101716330*x**37 + 4076350421*x**36 - 13340783196*x**35 +
>> >> 38910617655*x**34 - 101766230790*x**33 + 239877544005*x**32 -
>> >> 511738760544*x**31 + 991493848554*x**30 - 1749695026860*x**29 +
>> >> 2818953098830*x**28 - 4154246671960*x**27 + 5608233007146*x**26 -
>> >> 6943526580276*x**25 + 7890371113950*x**24 - 8233430727600*x**23 +
>> >> 7890371113950*x**22 - 6943526580276*x**21 + 5608233007146*x**20 -
>> >> 4154246671960*x**19 + 2818953098830*x**18 - 1749695026860*x**17 +
>> >> 991493848554*x**16 - 511738760544*x**15 + 239877544005*x**14 -
>> >> 101766230790*x**13 + 38910617655*x**12 - 13340783196*x**11 +
>> >> 4076350421*x**10 - 1101716330*x**9 + 260932815*x**8 - 53524680*x**7 +
>> >> 9366819*x**6 - 1370754*x**5 + 163185*x**4 - 15180*x**3 + 1035*x**2 -
>> >> 47*x +
>> >> 1)"
>> >>
>> >> sympy.intervals( a + "*" + b )
>> >>
>> >>
>> >>
>> >> Of course, in this particular case, the exception could be avoided if
>> >> sympy.intervals() is called for a and b separately.
>> >> However, since I run a very large number of similar computations, I am
>> >> not
>> >> so much interested in how to solve this particular problem.
>> >> Instead, I am interested in why this exception is raised at all. Is it
>> >> due
>> >> to a limitation of sympy.intervals()? Or maybe a bug? Or do I use it
>> >> incorrectly?
>> >
>> > Here is a full log with latest sympy master:
>> >
>> > https://gist.github.com/certik/6640160
>> >
>> > looks like a bug to me.
>> >
>> >> What I observed so far is that the above code raises an "OverflowError"
>> >> exception when function dup_root_upper_bound() tries to compute
>> >> 2.0**1041,
>> >> which obviously must fail.
>> >
>> > Yes, that's the error in the log:
>> >
>> >>>> 2.0**1041
>> > Traceback (most recent call last):
>> >   File "<stdin>", line 1, in <module>
>> > OverflowError: (34, 'Numerical result out of range')
>> >
>> > The question is why the intervals() function needs this, and one would
>> > need to investigate how it works.
>> > In any case, the exception that it throws should be more readable /
>> > informative.
>> >
>> > Ondrej
>> >
>> > --
>> > 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 [email protected].
>> > To post to this group, send email to [email protected].
>> > Visit this group at http://groups.google.com/group/sympy.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> 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 [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/sympy.
> For more options, visit https://groups.google.com/groups/opt_out.

Mateusz

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to