Inaccurate numerical result for roots of square equation

Hi,I have 'Sage Version 4.6.1, Release Date: 2011-01-11' and I using next code to get roots of square equation:

reset()
var('a b c p pz pz2')

a = 0.0000148294611962432
b = 9.90113840830450
c = 1.00000000000000
A = a*p^2 + b*p + c

pz = solve(A == 0, p, solution_dict = True)
pz = [s[p].n() for s in pz];
Result1 = A(p=pz[0])


This way give very bad accuracy of the 1st root (Result1=-0.00138422288000584). What i do wrong? And How to get precision result with Sage? Thanks!

edit retag close merge delete

A note not related to your question; the only thing you need (or should) declare as a variable above is p. Assigning values to an identifier automatically changes its type in any case: try var('a'); type(a); a=0.01; type(a) to see what I mean.

( 2011-03-08 05:31:49 -0500 )edit

Sort by » oldest newest most voted

Second edit:

Based on the comment, I think you need to use higher-precision rings. I don't know if Maxima (which is what does our solve command) can do higher precision easily from within the Sage interface, though I am pretty sure it can do it. Here is one solution in Sage. No pun with CCCP intended, as CC is already defined in Sage as the 53 bit precision complex field.

sage: CCC = ComplexField(150)
sage: a = CCC(a)
sage: b = CCC(b)
sage: c = CCC(c)
sage: R.<z> = CCC['z']
sage: R
Univariate Polynomial Ring in z over Complex Field with 150 bits of precision
sage: B = a*z^2+b*z+c
sage: B
0.000014829461196243200000000000000000000000000000*z^2 + 9.9011384083045000000000000000000000000000000*z + 1.0000000000000000000000000000000000000000000
sage: type(B)
<class 'sage.rings.polynomial.polynomial_element_generic.Polynomial_generic_dense_field'>
sage: B.roots()
[(-667666.66566816452809456920010337455502540059, 1), (-0.10099850239767434102211890294234211348279429, 1)]
sage: B.subs(z=B.roots()[0][0])
-8.9931131544973785160672193466796947557173371e-41


I hope that provides enough accuracy for your needs!

++++Edit: I see your question. You are saying that plugging 67... in yields something not quite right. This is going to happen with floating point approximations, especially when we pass things to Maxima, which we do here. Maxima is turning the floats into fractions, essentially, which means things will get off a little bit with such constants.

sage: A.find_root(-700000,-500000)
-667666.66566816461
sage: sol = A.find_root(-700000,-500000)
sage: A(p=sol)
0.000000000000000


+++++ original

Another thing that might work is not trying to approximate symbolic solutions which come

I'm not sure what's happening here. If I don't do it quite the way you do, I get

sage: pz = solve(A == 0, p)
sage: pz
[p == -340/5007*sqrt(24168884910961) - 1671503750/5007, p == 340/5007*sqrt(24168884910961) - 1671503750/5007]
sage: pz[0].rhs()
-340/5007*sqrt(24168884910961) - 1671503750/5007
sage: pz[0].rhs().n()
-667666.665528360
sage: pz[1].rhs().n()
-0.100998502399307


Plotting this

sage: plot(A,-700000,100000)


seems to agree with these results.

more

is that possible to use another sage build-in block instead of maxima for arithmetics that more accurate?

( 2011-03-08 06:30:21 -0500 )edit

Absolutely, but I was trying to answer your question most easily. You should look for documentation on RealField and other arbitrary (but fixed) precision fields, as well as interval arithmetic. Without knowing what you are trying to do, I can't be more specific. (I suspect Maxima also has such capabilities, but we don't wrap them.)

( 2011-03-08 13:52:28 -0500 )edit

i do this for home task, so i have directives how i must solve main task (..writen 1980 in CCCP) also i dont want use find_root because roots can be complex and i must know where roots are. In variant #2 in ur answer u get little wrong root, same as i get, correct root #1 = -667666.665668165 - its not so far from -667666.665528360, but its for simple calculator, not for sage (my SRP-280 calculator gives better result than sage [-667666.665668]), some tasks need very good precision (my task not, but i want find way to exclude possible problems in next work)

( 2011-03-09 10:36:04 -0500 )edit