Ask Your Question
1

Inaccurate numerical result for roots of square equation

asked 2011-03-08 12:18:44 +0100

avi9526 gravatar image

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 flag offensive close merge delete

Comments

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.

kcrisman gravatar imagekcrisman ( 2011-03-08 12:31:49 +0100 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2011-03-08 12:37:33 +0100

kcrisman gravatar image

updated 2011-03-11 13:35:02 +0100

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.

The following will help you more:

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.

edit flag offensive delete link more

Comments

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

avi9526 gravatar imageavi9526 ( 2011-03-08 13:30:21 +0100 )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.)

kcrisman gravatar imagekcrisman ( 2011-03-08 20:52:28 +0100 )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)

avi9526 gravatar imageavi9526 ( 2011-03-09 17:36:04 +0100 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2011-03-08 12:18:44 +0100

Seen: 617 times

Last updated: Mar 11 '11