[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] [#87 solve(x + 1.1, 0.001) fails] reply and experiment
From: |
anonymous |
Subject: |
[Axiom-developer] [#87 solve(x + 1.1, 0.001) fails] reply and experimenting with new format |
Date: |
Sun, 13 Feb 2005 02:09:12 -0600 |
++added:
{\tt [Kostas Oikonomou <address@hidden> wrote:]}
++added:
{\tt [William Sit <address@hidden> replied:]}
??changed:
-One should be careful interpreting these results. The second one solves it to
5 binary digit accuracy (closest binary to 0.1 (decimal) is 1/16+1/32 =
0.09375) hence the answer is not {\tt -1.1}. A similar loss happens in the
third one. To obtain {\tt -1.1} as the solution, one needs much higher
accuracy, as in the fourth one (that is the minimum needed).
-
-From unknown Fri Feb 11 07:25:14 -0600 2005
-From:
-Date: Fri, 11 Feb 2005 07:25:14 -0600
-Subject: Not a bug.
-Message-ID: <address@hidden>
-
-Severity: normal => minor
-Status: open => closed
-
-
-From KostasOikonomou Sat Feb 12 09:03:08 -0600 2005
-From: Kostas Oikonomou
-Date: Sat, 12 Feb 2005 09:03:08 -0600
-Subject: [#87 solve(x + 1.1, 0.001) fails]
-Message-ID: <address@hidden>
-
-
-[9 more lines...]
One should be careful interpreting these results. The second one solves it to
5 binary digit accuracy (closest binary to {\tt 0.1} (decimal) is {\tt
1/16+1/32 = 0.09375}) hence the answer is not {\tt -1.1}. A similar loss
happens in the third one. To obtain {\tt -1.1} as the solution, one needs much
higher accuracy, as in the fourth one (that is the minimum needed).
{\tt [[Kostas Oikonomou Sat Feb 12 09:03:08 -0600 2005 replied:]]}
++added:
{\tt [[William Sit replied:]]}
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 not use a mechanis!
m 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
\begin{equation*}
f(x) = (x+1)(x+2) \cdots (x+20) = x^20 + 210 x^19 + \cdots + 20! = 0
\end{equation*}
where a change of the coefficient 210 by $2^{-23} \approx 1.2 \times 10^{-7}$
would turn the root $-20$ to $-20.8$ and five pairs of zeros to complex roots.
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:]]}
++added:
\begin{axiom}
solve(x^2 - 1.234)
\end{axiom}
??changed:
- Kostas
-
-
-From MartinRubey Sat Feb 12 13:07:55 -0600 2005
-From: Martin Rubey
-Date: Sat, 12 Feb 2005 13:07:55 -0600
-Subject: [#87 solve(x + 1.1, 0.001) fails] [#87 solve(x + 1.1, 0.001) fails]
-Message-ID: <address@hidden>
-In-Reply-To: <address@hidden>
{\tt [[Martin Rubey Sat Feb 12 13:07:55 -0600 2005 <address@hidden> wrote:]]}
??changed:
-Martin
-
{\tt [[William Sit wrote:]]}
Yes, as explained above. Algebraic methods do not work well with Float.
--
forwarded from http://page.axiom-developer.org/zope/mathaction/address@hidden
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Axiom-developer] [#87 solve(x + 1.1, 0.001) fails] reply and experimenting with new format,
anonymous <=