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 _______________________________________________ Axiom-math mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-math
