Re: [sage-devel] sqrt() returns wrong result for large inputs
David Roe wrote : I posted a patch there that should fix it; I have to work on other stuff, but if someone else wants to take over and write some doctests, make sure it works in lots of cases... David On Mon, Oct 25, 2010 at 17:14, Burcin Erocal bur...@erocal.org mailto:bur...@erocal.org wrote: On Mon, 25 Oct 2010 17:00:39 -0400 David Roe r...@math.harvard.edu mailto:r...@math.harvard.edu wrote: This is a good workaround, but the original problem can be traced to the function sage.symbolic.expression.Expression.__int__ def __int__(self): #FIXME: can we do better? return int(self.n(prec=100)) Presumably you could adaptively estimate to higher precision until your error interval included only one integer... This is #9953 on trac: http://trac.sagemath.org/sage_trac/ticket/9953 I prefer return(self.n(prec=ceil(log(abs(self.n()),10)+10))) But this answer isn't right around . or XXX.1. And I don't see where floor(10^1234*sqrt(2)) is wrong. I test : vt=floor(10^1234*sqrt(2)) ; sign(vt^2-2*10^2468) ; sgn((vt+1)^2-2*10^2468) # answer =-1 and 1 for sage 4.5.3 With int the result is false (I get 1 and 1 in the both cases). I ignore how to trace these 2 calculus. F. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sqrt() returns wrong result for large inputs
On Tue, Oct 26, 2010 at 1:03 AM, Francois Maltey fmal...@nerim.fr wrote: David Roe wrote : I posted a patch there that should fix it; I have to work on other stuff, but if someone else wants to take over and write some doctests, make sure it works in lots of cases... David On Mon, Oct 25, 2010 at 17:14, Burcin Erocal bur...@erocal.org mailto:bur...@erocal.org wrote: On Mon, 25 Oct 2010 17:00:39 -0400 David Roe r...@math.harvard.edu mailto:r...@math.harvard.edu wrote: This is a good workaround, but the original problem can be traced to the function sage.symbolic.expression.Expression.__int__ def __int__(self): #FIXME: can we do better? return int(self.n(prec=100)) Presumably you could adaptively estimate to higher precision until your error interval included only one integer... This is #9953 on trac: http://trac.sagemath.org/sage_trac/ticket/9953 I prefer return(self.n(prec=ceil(log(abs(self.n()),10)+10))) But this answer isn't right around . or XXX.1. And I don't see where floor(10^1234*sqrt(2)) is wrong. I test : vt=floor(10^1234*sqrt(2)) ; sign(vt^2-2*10^2468) ; sgn((vt+1)^2-2*10^2468) # answer =-1 and 1 for sage 4.5.3 Use intervals, increasing the precision until the result lies in a single interval. This is what floor(...) does. Of course that can be quite slow, especially for actual integer values. A speedup (not in floor itself) would be to test equality against an integer if the result looks like it is equal after several refinements. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sqrt() returns wrong result for large inputs
Georg wrote : while calculating the integer part of square roots I realized that sqrt() returns wrong results for large inputs (although the sqrt() command itself accepts bignum values). example: int(sqrt(2^94533)) int isn't a mathematical Sage type, but Integer is a Sage type. And Integer (sqrt(2^1234567)) fails But floor over Integer seems fine : n=10001 ; res=floor(sqrt(2^n)) ; sign(res^2-2^n) ; sign((res+1)^2-2^n) I get -1 and 1. but it fails around n=3 or 4. You may also get a precise numerical approximation by the method _.n(digits=). By example : sqrt(2).n(digits=1). But in this case you must compute by pen the digit value. A very similar exercice : Is the number of digits of 123^456^789 even or odd ? Of course you must read 123^(456^789), not (123^456)^789 ! I hope this help you... F. (in France) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sqrt() returns wrong result for large inputs
When you do sqrt(2^m) when m is odd, say m=2*k+1, the returned value is symbolically 2*k * sqrt(2): sage: sqrt(2^101) 1125899906842624*sqrt(2) Now using Integer() to round that will evaluate sqrt(2) approximately to standard precision, which is not enough. Instead, use the isqrt() method for Integers: sage: a = 2^94533 sage: b = a.isqrt() sage: a b^2 True sage: (b+1)^2 a True John On Mon, Oct 25, 2010 at 4:50 PM, Francois Maltey fmal...@nerim.fr wrote: Georg wrote : while calculating the integer part of square roots I realized that sqrt() returns wrong results for large inputs (although the sqrt() command itself accepts bignum values). example: int(sqrt(2^94533)) int isn't a mathematical Sage type, but Integer is a Sage type. And Integer (sqrt(2^1234567)) fails But floor over Integer seems fine : n=10001 ; res=floor(sqrt(2^n)) ; sign(res^2-2^n) ; sign((res+1)^2-2^n) I get -1 and 1. but it fails around n=3 or 4. You may also get a precise numerical approximation by the method _.n(digits=). By example : sqrt(2).n(digits=1). But in this case you must compute by pen the digit value. A very similar exercice : Is the number of digits of 123^456^789 even or odd ? Of course you must read 123^(456^789), not (123^456)^789 ! I hope this help you... F. (in France) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sqrt() returns wrong result for large inputs
This is a good workaround, but the original problem can be traced to the function sage.symbolic.expression.Expression.__int__ def __int__(self): #FIXME: can we do better? return int(self.n(prec=100)) Presumably you could adaptively estimate to higher precision until your error interval included only one integer... David On Mon, Oct 25, 2010 at 12:13, John Cremona john.crem...@gmail.com wrote: When you do sqrt(2^m) when m is odd, say m=2*k+1, the returned value is symbolically 2*k * sqrt(2): sage: sqrt(2^101) 1125899906842624*sqrt(2) Now using Integer() to round that will evaluate sqrt(2) approximately to standard precision, which is not enough. Instead, use the isqrt() method for Integers: sage: a = 2^94533 sage: b = a.isqrt() sage: a b^2 True sage: (b+1)^2 a True John On Mon, Oct 25, 2010 at 4:50 PM, Francois Maltey fmal...@nerim.fr wrote: Georg wrote : while calculating the integer part of square roots I realized that sqrt() returns wrong results for large inputs (although the sqrt() command itself accepts bignum values). example: int(sqrt(2^94533)) int isn't a mathematical Sage type, but Integer is a Sage type. And Integer (sqrt(2^1234567)) fails But floor over Integer seems fine : n=10001 ; res=floor(sqrt(2^n)) ; sign(res^2-2^n) ; sign((res+1)^2-2^n) I get -1 and 1. but it fails around n=3 or 4. You may also get a precise numerical approximation by the method _.n(digits=). By example : sqrt(2).n(digits=1). But in this case you must compute by pen the digit value. A very similar exercice : Is the number of digits of 123^456^789 even or odd ? Of course you must read 123^(456^789), not (123^456)^789 ! I hope this help you... F. (in France) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.comsage-devel%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.comsage-devel%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sqrt() returns wrong result for large inputs
On Mon, 25 Oct 2010 17:00:39 -0400 David Roe r...@math.harvard.edu wrote: This is a good workaround, but the original problem can be traced to the function sage.symbolic.expression.Expression.__int__ def __int__(self): #FIXME: can we do better? return int(self.n(prec=100)) Presumably you could adaptively estimate to higher precision until your error interval included only one integer... This is #9953 on trac: http://trac.sagemath.org/sage_trac/ticket/9953 Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sqrt() returns wrong result for large inputs
I posted a patch there that should fix it; I have to work on other stuff, but if someone else wants to take over and write some doctests, make sure it works in lots of cases... David On Mon, Oct 25, 2010 at 17:14, Burcin Erocal bur...@erocal.org wrote: On Mon, 25 Oct 2010 17:00:39 -0400 David Roe r...@math.harvard.edu wrote: This is a good workaround, but the original problem can be traced to the function sage.symbolic.expression.Expression.__int__ def __int__(self): #FIXME: can we do better? return int(self.n(prec=100)) Presumably you could adaptively estimate to higher precision until your error interval included only one integer... This is #9953 on trac: http://trac.sagemath.org/sage_trac/ticket/9953 Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.comsage-devel%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
