Re: [fricas-devel] Re: [Axiom-math] Selection of roots

[Alejandro Jakubi]

On Mon, 3 Nov 2008, Bill Page wrote:

> There are different kinds of documentation. I expect that the best
> time to write a tutorial (for other people at a similar stage) is
> while one is still learning, or at least while it is still "fresh".

I see what you mean. But I have no doubt that I will be still learning and
fresh wrt Axiom for a very long time.

> Well, Tim Daly states that the original Axiom project has a 30 year
> time horizon, so I guess you still have time. :-)

Sure.

> Hyperdoc is also a very important source of information. It is often
> easier and faster to find what you are looking for there. But
> ultimately (for better or worse, mostly worse) the last resort is the
> algebra source code itself.

Not in my experience. In a large fraction of cases, I have not found in
Hyperdoc the information that I was looking for. On the other hand, as I stay
most of the time in Windows, and as I prefer native ports, usually I do not
have Hyperdoc at hand.

Yes, I have tried lately browsing a bit some spad files with very limited 
success,
as you may imagine.

> Great. I think you work would also be of some interst to others.

Do you really mean posting these tm files to the wiki as they are?

> The documentation says RealClosure characterizes solutions uniquely
> bound by intervals open on the right, i.e. just one real-valued
> solution is known to lie at or greater than the "left" value and less
> than the "right" value. It does not actually find exact solutions.
> 'radicalSolve' on the other hand finds exact symbolic values (up to
> 4th order) but these can be difficult to evaluate.

Does it mean that these labels like %A1 represent these close-open intervals?
(I had guess that they were an equivalent to Indexed RootOfs in Maple). If so,
what 'approximate' does is to "refine" these intervals?

> It is sometimes easy to find the exact real solutions directly:
>
>   A:=select(x+->retractIfCan(complexNumeric rhs x) case Float,radicalSolve(fp));
>
> such as in this particular example, but this method could silently
> skip some roots due to rounding errors.

Remarkably, the origin of my question was this thread at MaplePrimes:

http://www.mapleprimes.com/forum/assumingdontassume

that dealed with the current limitations of the automated prover built in
Maple 'is' for a postprocessing of the output of 'solve', and an interim 
workaround
using a "numerically aided" filter, which seems to be similar to your
proposal.

Alejandro Jakubi