ASKSAGE: Sage Q&A Forum - Latest question feedhttp://ask.sagemath.org/questions/Q&A 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 numbershttp://ask.sagemath.org/question/42369/unexpected-behaviour-of-arbitrary-precision-real-numbers/I'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 -0500http://ask.sagemath.org/question/42369/Issues with .99999999999...http://ask.sagemath.org/question/35963/issues-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 -0600http://ask.sagemath.org/question/35963/Difference between RealField and numerical_approxhttp://ask.sagemath.org/question/32834/difference-between-realfield-and-numerical_approx/What 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 -0500http://ask.sagemath.org/question/32834/why don't sage return exact value in some functionshttp://ask.sagemath.org/question/25514/why-dont-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 -0600http://ask.sagemath.org/question/25514/is it a bug?http://ask.sagemath.org/question/10106/is-it-a-bug/the 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 -0500http://ask.sagemath.org/question/10106/Longer fraction to decimal numberhttp://ask.sagemath.org/question/9671/longer-fraction-to-decimal-number/After `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 -0600http://ask.sagemath.org/question/9671/find roots with arbitrary precisionhttp://ask.sagemath.org/question/9486/find-roots-with-arbitrary-precision/It 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 -0500http://ask.sagemath.org/question/9486/adding real literal and real number of high precisionhttp://ask.sagemath.org/question/9185/adding-real-literal-and-real-number-of-high-precision/When 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 -0500http://ask.sagemath.org/question/9185/