Andrzej Chrzeszczyk finds this numerical error in this equation :
sage: s=solve(3*x^3-9*x+10,x,solution_dict=True)
sage: ns=[n(s[k][x]) for k in range(3)]
sage: ns
[1.06780542232902 - 1.84949324407141*I,
0.0277635108030695 + 1.24902476648341*I,
-1.09556893313209 + 0.600468477588001*I]
# no real solution, no conjugate solutions
So this last result is very wrong.
But is it a bug ? where is this bug ? Let me explain my calculus.
In this solve there is an unsimplified (-1)^(1/3)
After a subs or a radical_simplify the last result is right.
sage: res = map (lambda z:z[x].subs((-1)^(1/3)==-1), s) ; res
sage: res2 = map (lambda z:z[x].radical_simplify(), s) ; res2
sage: res3 = map (lambda z:z[x], s) ; res3
sage: reduce (lambda a,b:a*(x-b), [1]+res).expand()*3 # right
sage: reduce (lambda a,b:a*(x-b), [1]+res2).expand()*3 # right
sage: reduce (lambda a,b:a*(x-b), [1]+res3).expand()*3 # a (-1)^(1/3)
remains
This reduce computes 1*(x-rac1)*(x-rac2)*(x-rac3).
The 2 first expand aren't so fine :
look at the result with a +/- 1/2*I*3^(5/6) without the last ...*3 in
res and res2.
But this isn't the main question...
It's possible to verify it with numerical values :
sage: reduce (lambda a,b:a*(x-b.n()),[1.0]+res) * 3.0
The curious 1 == 1.0 appears,
it's not so nice, but the ...*3.0 erases this behaviour.
So the main error seems to be about (-1)^(1/3).
(-1)^(1/3) remains (-1)^(1/3), and ((-1)^(1/3)).radical_simplify() is right.
sage: (-1)^(1/3) # remains (-1)^(1/3)
sage: maxima ("(-1)^(1/3)") # remains...
But in an older maxima 5.13 :
(%i14) (-1)^(1/3);
(%o14) - 1
(%i15) solve(3*x^3-9*x+10, x) ;
sqrt(3) %i 1
- ---------- - -
1/3 sqrt(3) %i 1 2 2
(%o15) [x = - 3 (---------- - -) - ----------------,
2 2 1/3
3
sqrt(3) %i 1
---------- - -
2 2 1/3 sqrt(3) %i 1 1/3 1
x = - -------------- - 3 (- ---------- - -), x = - 3
- ----]
1/3 2
2 1/3
3 3
In this 5.13 maxima, the roots are conjugates and float is almost fine
(a product remains) :
(%i2) float(solve(3*x^3-9*x+10, x)),numeric ;
(%o2) [x = - 1.442249570307408 (0.86602540378444 %i - 0.5)
- 0.69336127435063 (- 0.86602540378444 %i - 0.5),
x = - 0.69336127435063 (0.86602540378444 %i - 0.5)
- 1.442249570307408 (- 0.86602540378444 %i - 0.5), x = - 2.135610844658043]
But in Sage the test is less nice :
sage: maxima("float(solve(3*x^3-9*x+10, x)),numeric")
[x=1.442249570307408*(.8660254037844386*%i-0.5)/(-1)^(1/3)
+.6933612743506347*(-1)^(1/3)*(-.8660254037844386*%i-0.5),
x=.6933612743506347*(-1)^(1/3)*(.8660254037844386*%i-0.5)
+1.442249570307408*(-.8660254037844386*%i-0.5)/(-1)^(1/3),
x=.6933612743506347*(-1)^(1/3)+1.442249570307408/(-1)^(1/3)]
So is it a maxima bug in this new version ? I use sage 4.6.1
But now tests
sage: n((-1)^(1/3)) ; CC((-1)^(1/3))
0.500000000000000 + 0.866025403784439*I
It's not so false in CC, absolutely unusal in RR.
I get an error with RR((-1)^(1/3))
The blend of these 2 behaviours is buggy ! but where/what is the bug ?
Can someone give me the right way of thinking ?
And explain the 2 other results about expand with +/- I*... , and 1==1.0.
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
