On 10/2/2013 11:32 AM, Rupert Swarbrick wrote:
>>> For constants, in isolation, the position I take is that
>>> a particular item like (-1)^(1/6) is a six-tuple. Unless you know
>>> more info about it.
>> Ok, Let's assume (-1)^(1/6) is a six-tuple. Here is just
>> one of the ways in which this makes solve's answer wrong.
> I think that you an Richard might be talking slightly at cross-purposes
> here. It's definitely true that solve() is less than brilliant when it's
> given radicals like what you're describing. I don't think anyone would
> dispute that its results are unhelpful.
The only ways I know of to force the results of solve() to be generally
fool-proof are to return the
results as either RootOf( ...) expressions, expressions free of
ambiguous radical subexpressions when possible, or numerical
approximations that are unambiguous and naturally
free of radicals.
These are not computer problems, but problems of mathematical
discourse. One can attempt
to describe an expression pf a single complex variable through
well-understood mechanisms
taught in courses in complex variables, conformal mapping, etc. For more
than one
complex variable, not so much. Some of the problems raised by users of
computer algebra systems amount to sputtering about how the answer is
not what the user learned in high school, when things
were left out. Like log in the complex plane.
To quote from an old NSF proposal of mine,
In brief, the problem is this: many standard functions, such as the
logarithm and square root functions,
cannot be dened continuously on the complex plane. When working with
such functions, arbitrary lines
of discontinuity, or branch cuts, must be chosen. For example, the
conventional branch cut for the complex
logarithm function lies along the negative real axis, so that log(-1)
= pi i but when e_1 is small, real, and
positive, log(-1 - e_1 i) = -pi i + e_2 for some small, complex e_2.
>
> I think that Richard is trying to show the problems that we might run
> into trying to make a solve implementation that's more helpful. I'm
> certain we can/should do better than we do currently, but I suppose it's
> important to specify exactly what problem we're trying to solve.
>
> Yes, I agree that at some point we need to bite the bullet and "fix
> it". I think the problem is that it's a big and difficult job and
> no-one's quite sure how to do that correctly.
You are welcome to design a solve program that does something different.
I suspect you will have to design a different computer algebra system
around it..
>
> Rupert
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima