[Axiom-developer] [#87 solve(x + 1.1, 0.001) fails] LaTeX not working

[anonymous]

++added:


??changed:
-Of course, yes. However, there is a dilemma: when you give Axiom an equation 
with floating point coefficients, should Axiom "solve" this algebraically, as 
if 'Float' is just like any other domain, or numerically, giving 'Float' a 
special treatment? Since Axiom algorithms are categorical, rather than writing 
two separate algorithms, Axiom solves, if possible, algebraically (that is, 
exactly) and gives numerical answers as options when the precision parameter is 
given. This choice does not work well with equations over 'Float' because 
'Float' does not have some of the algebraic properties as 'Fraction Integer' or 
'Fraction Complex Integer' (such as factorization or GCD), which is why there 
is a warning in 'solve(x^2-1.234)'. The package is numsolve.spad and you see 
that these restrictions are well documented. So the above signature is really 
not meant to be used at the moment. A similar situation occurs, for example 
'factor(1.23)' is legal, but is really useless. Axiom does n!
ot use a mechanism to exclude specific domains from a category. It adopts an 
"include" philosophy but let things fail with warning or error. If you look 
into numsolve.spad, you will find that the 'innerSolve1' algorithm {\it 
implementation} is restricted. (So if later someone finds a way to implement a 
'solve' algorithm over 'Float', that would be just fine).
-
-So a lot of Axiom failures are not bugs, but by design. One way to improve the 
user interface would seem to be to automatically lifting a polynomial over 
'Float' to one over 'Fraction Integer'. A moment's reflection would convince 
you this is not always possible (for example, 'sqrt(2)' or '%pi' are 
technically both belong to 'Float' (model for real numbers), but of course, in 
reality, every floating point number is a rational number. Such a lifting 
package would have to take into consideration the precision to convert some 
symbolic constants to a decimal approximation and then convert that to an exact 
rational number. However, even this would not create satisfactory results 
because we know the sensitivity of solutions of polynomial equations to small 
changes of its coefficients. Wilkinson has this example
- 
-
-<center>
-f(x) = (x+1)(x+2) ... (x+20) = x<SUP>20</SUP> + 210 x<SUP>19</SUP> + ... + 20! 
= 0
-</center>
-
-
-where a change of the coefficient 210 by 2<SUP>-23</SUP> (approximately 1.2 
&times; 10<SUP>-7</SUP>) would turn the root -20 to -20.8 and five pairs of 
zeros to complex roots. (This perturbed equation will take a *very long* time 
in Axiom, will not be solved exactly by Mathematica, but is trivially solved 
*numerically* in Mathematica).
-
-
-
-So if we want numerically accurate solutions, we should use a robust numerical 
library. I believe this is not yet available in Axiom (the NAG version allowed 
interface with its Fortran libraries, at extra costs).
-
-If we are really (no pun intended) only using truely floating point 
coefficients, then it can easily be converted to Fraction Integer, but one has 
to beware that the algorithm would take a very long time because exact 
arithmetic with large integer coefficients are expensive.
-
-{\tt [[Kostas Oikonomou wrote:]]}
-[1 more lines...]
Of course, yes. However, there is a dilemma: when you give Axiom an equation 
with floating point coefficients, should Axiom "solve" this symbolically, as if 
'Float' is just like any other domain, or numerically, giving 'Float' a special 
treatment? Since Axiom algorithms are categorical, rather than writing two 
separate algorithms, Axiom solves, if possible, exactly and gives numerical 
answers as options when the precision parameter is given. This choice does not 
work well with equations over 'Float' because 'Float' does not have some of the 
algebraic properties as 'Fraction Integer' or 'Fraction Complex Integer' (such 
as factorization or GCD), which is why there is a warning in 
'solve(x^2-1.234)'. 


++added:
The package is numsolve.spad and you see that these restrictions are well 
documented. So the above signature is really not meant to be used at the 
moment. A similar situation occurs, for example 'factor(1.23)' is legal, but is 
really useless. Axiom does not use a mechanism to exclude specific domains from 
a category. It adopts an "include" philosophy but let things fail with warning 
or error. If you look into numsolve.spad, you will find that the 'innerSolve1' 
algorithm *implementation* is restricted. (So if later someone finds a way to 
implement a 'solve' algorithm over 'Float', that would be just fine).

So a lot of Axiom failures are not bugs, but by design. One way to improve the 
user interface would seem to be to automatically lifting a polynomial over 
'Float' to one over 'Fraction Integer'. A moment's reflection would convince 
you this is not always possible (for example, 'sqrt(2)' or '%pi' technically 
both belong to 'Float' (model for real numbers)), but of course, in reality, 
every (finite precision) floating point number is a rational number. Such a 
lifting package would have to take into consideration the precision to convert 
some symbolic constants to their decimal approximations and then convert them 
to exact rational numbers. However, even this would not create satisfactory 
results because we know the sensitivity of solutions of polynomial equations to 
small changes of its coefficients. Wilkinson has this example
 

<center>
*f*(*x*) = (*x*+1)(*x*+2) ... (*x*+20) = *x*<SUP>20</SUP> + 210 
*x*<SUP>19</SUP> + ... + 20! = 0
</center>


where a change of the coefficient 210 by 2<SUP>&minus;23</SUP> (approximately 
1.2 &times; 10<SUP>&minus;7</SUP>) would turn the root &minus;20 to &minus;20.8 
and five pairs of zeros to complex roots. (This perturbed equation will take a 
*very long* time in Axiom, will not be solved exactly by Mathematica, but is 
easily solved *numerically* in Mathematica).



So if we want numerically accurate solutions, we should use a robust numerical 
library. I believe this is not yet available in Axiom (the NAG version allowed 
interface with its Fortran libraries, at extra costs).

If we are really (no pun intended) only using truely floating point 
coefficients, then it can easily be converted to Fraction Integer, but one has 
to beware that the algorithm would take a very long time because exact 
arithmetic with large integer coefficients are expensive.

{\tt [[Kostas Oikonomou wrote:]]}

Also, while 'solve(x+1.1)' "works", so to speak, 'solve(x^2 - 1.234)' returns a 
warning.


??changed:
-{\tt [[Martin Rubey Sat Feb 12 13:07:55 -0600 2005 &lt;address@hidden> 
wrote:]]}
-
-I think the idea is to convert your Polynomial Float into a Polynomial Fraction
-Integer and then use solve (POLY FRAC INT, FLOAT) -> result.
{\tt [[Martin Rubey Sat Feb 12 13:07:55 -0600 2005 &lt;address@hidden> wrote:]]}

I think the idea is to convert your 'Polynomial Float' into a 'Polynomial 
Fraction
Integer' and then use 'solve (POLY FRAC INT, FLOAT) -> ... ' to get results.

??changed:
-Yes, as explained above. Algebraic methods do not work well with Float. 
-                       
-
Yes, as explained above. Symbolic methods do not work well with 'Float'. 
                        


--
forwarded from http://page.axiom-developer.org/zope/mathaction/address@hidden