ASKSAGE: Sage Q&A Forum - Latest question feed Forum for SageenCopyright Sage, 2010. Some rights reserved under creative commons license.Fri, 18 May 2018 19:26:56 -0500Unexpected behaviour of arbitrary precision real numbers've been trying to use arbitrary precision real numbers and I'm a bit confused. The simple snippet below illustrates my point: R = RealField(200) z = R(2.0) print '%.20f' % (z.sqrt()) I should get (or that's what I was expecting) 1.41421356237309504880, but instead I got 1.41421356237309514547 (a disagreement in the last five decimal places). Where am I goofing up? You see, it's a quite simple code. How could I fix it in order to obtain the desired/expected result? Thanks in advance for any light shed on this matter. FaustofbarbutoFri, 18 May 2018 19:26:56 -0500 with .99999999999... Here is a result that I found surprising and I don't understand completely what corercian is causing it. sage: int(.9999999999999999) 0 sage: int(.99999999999999999) 1 sage: int(0.99999999999999999) 0 sage: int(0.9999999999999999) 0 sage: int(0.999999999999999999999999999999999) 0 What is going on? More to play with: sage: a=.99999999999999999; b=0.999999999999999999999999999999999 sage: a<b False sage: int(a)<int(b) False and sage: a=.999999999999999990; b=0.999999999999999999999999999999999 sage: int(a)<int(b) False sage: a<b True sage: a=.999999999999999997 sage: a<b False sage: a=.999999999999999996 sage: a<b True mfFri, 09 Dec 2016 05:00:48 -0600 between RealField and numerical_approx is the difference between using RealField, as in sage: RealField(10).pi() 3.1 and `numerical_approx`, aka `n`, as in sage: pi().n(10) 3.1 Are they actually the same function under the hood or should one be used over the other in some cases?Pretty AntlersSat, 19 Mar 2016 23:26:35 -0500 don't sage return exact value in some functions Look at the following code: realpoly.<z> = PolynomialRing(RR) factor(z^2-2) it returns: (z - 1.41421356237310) * (z + 1.41421356237310) why don't sage return (z-sqrt(2))*(z+sqrt(2)) and how can i make it to do that?Chong WangTue, 13 Jan 2015 21:31:08 -0600 it a bug? output of the following lines n=log(64.0)/log(2.0) print n, range(n) n=log(N(64))/log(N(2)) print n, range(n) n=N(log(64)/log(2)) print n, range(n) is 6.00000000000000 [0, 1, 2, 3, 4, 5] 6.00000000000000 [0, 1, 2, 3, 4, 5] 6.00000000000000 [0, 1, 2, 3, 4] shouldn't they be all the same? ('Sage Version 5.9, Release Date: 2013-04-30', osx 10.6.8)abcThu, 09 May 2013 00:54:14 -0500 fraction to decimal number `solve( x^3+8*x^2+x+10 , x )` I get `x = (2/9*sqrt(3)*sqrt(1355) - 611/27)^(1/3) + 61/9/(2/9*sqrt(3)*sqrt(1355) - 611/27)^(1/3) - 8/3` Now how to show this as decimal? float(x) and R = RealField(50); R(x) doesn't seem to work.randomuserMon, 31 Dec 2012 23:08:55 -0600 roots with arbitrary precision seems that `find_root` will always convert its parameter range to `float`, even if `a` and `b` were originally given in some arbitrary precision real number field. Is there a variant of this algorithm that can find roots to arbitrary precision? Even greater would be some algorithm that can make use of interval arithmetic based on `RealIntervalField`, which in particular will return an interval that is guaranteed to contain the zero. I have written some code along these lines: def bisect_interval(f, i, d): # find zero of function f in interval i with desired diameter d # f must be monotonically increasing and must contain a zero in i d2 = d/2 zero = i.parent()(0) hi = i while hi.absolute_diameter() > d2: l, r = hi.bisection() c = l.intersection(r) fc = f(c) if fc > zero: hi = l else: hi = r lo = i while lo.absolute_diameter() > d2: l, r = lo.bisection() c = l.intersection(r) fc = f(c) if fc < zero: lo = r else: lo = l return lo.union(hi) Am I reproducing functionality that's already available somewhere in Sage? If not, do you consider this functionality worth adding? Should it use some better algorithm than simple bisection? Is the algorithm even correct? You don't *have* to answer all of these questions, as my core question remains the one about an arbitrary precision version of `find_root`. But additional answers would be welcome.MvGTue, 30 Oct 2012 23:44:29 -0500 real literal and real number of high precision Sage is adding a real literal to a real number of high precision, shouldn't it calculate the sum in the high precision ring? Instead, Sage seems to calculate in double precision: RF=RealField(150); RF Real Field with 150 bits of precision RF(0.9 + RF(1e-18)) 0.90000000000000002220446049250313080847263336 RF(1.0+ RF(1e-18)) 1.0000000000000000000000000000000000000000000 RF(1+ RF(1e-18)) 1.0000000000000000010000000000000000000000000 I'm trying to use high precision arithmetic (2658 bits) in Sage to verify some results produced by the high precision semidefinite program solver sdpa_gmp. Sage's treatment of real literals in these calculations has made me anxious about the possibility that I'm overlooking other ways in which the calculations might be unreliable. Is there anywhere an explanation of Sage's treatment of real literals in high precision arithmetic? Added: Immediately after posting this question, the list of Related Questions in the sidebar pointed me to question/327/set-global-precision-for-reals where I learned that 'RealNumber = RF' would make all real literals lie in the high precision ring. Still, I wonder why the default behavior is to discard precision that is present in the original real literal. thanks, Daniel Friedan thanks for Daniel FriedanFri, 27 Jul 2012 06:05:52 -0500