Simplify torture
MCKAY john
This expression is easy to simplify by hand.
What torture does your CAS take you through to do the same ?
Which one is most painless ?
x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
--
Cogito ergo sum aut miror ergo sim.
Julian Stoev
On 28 May 1998, MCKAY john wrote:
|This expression is easy to simplify by hand.
|What torture does your CAS take you through to do the same ?
|Which one is most painless ?
|
| x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
Mathematica 3.0:
In[1]:= Simplify[-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9)]
Out[1]= 0
:-)
MapleV.3
> simplify((-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
2/9 8/9 5/9
(-1) - (-1) + (-1)
:-(
MuPAD 1.4:
simplify((-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
2/9 5/9 8/9
(-1) + (-1) - (-1)
:-(
--Julian Stoev
Allan Hayes
MCKAY john wrote in message <6kkoeg$dlt$1...@newsflash.concordia.ca>...
>This expression is easy to simplify by hand.
>What torture does your CAS take you through to do the same ?
>Which one is most painless ?
>
> x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
With Mathematica:
x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
Simplify[x]
0
-------------------------------------------------------------
Allan Hayes
Mathematica Training and Consulting
Leicester UK
http://www.haystack.demon.co.uk
h...@haystack.demon.co.uk
voice: +44 (0)116 271 4198
fax: +44(0)116 271 8642
Julian Stoev
On Fri, 29 May 1998, MCKAY john wrote:
|You seems to have lost an initial minus sign.
|Try again?
|J
|
|In article <Pine.GSO.3.96.980529144348.12341C-100000@neuro> you write:
|>On 28 May 1998, MCKAY john wrote:
|>
|>|This expression is easy to simplify by hand.
|>|What torture does your CAS take you through to do the same ?
|>|Which one is most painless ?
|>|
|>| x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
|>
|>Mathematica 3.0:
|>In[1]:= Simplify[-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9)]
|>Out[1]= 0
|>:-)
|>
|>MapleV.3
|>> simplify((-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
|>
|> 2/9 8/9 5/9
|> (-1) - (-1) + (-1)
|>:-(
Correction:
> simplify(-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
2/9 8/9 5/9
-(-1) - (-1) + (-1)
|>MuPAD 1.4:
|>simplify((-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
|>
|> 2/9 5/9 8/9
|> (-1) + (-1) - (-1)
|>:-(
Correction:
simplify(-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
5/9 2/9 8/9
(-1) - (-1) - (-1)
--Julian Stoev
Andre Poenitz
Julian Stoev (st...@SPAM-RE-MO-VER-usa.net) wrote:
: Mathematica 3.0:
: In[1]:= Simplify[-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9)]
: Out[1]= 0
: :-)
:
: MapleV.3
: > simplify((-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
:
: 2/9 8/9 5/9
: (-1) - (-1) + (-1)
: :-(
: MuPAD 1.4:
: simplify((-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
:
: 2/9 5/9 8/9
: (-1) + (-1) - (-1)
: :-(
: --Julian Stoev
:
I am not quite sure whether you put the right smileys at the right
spot... First of all, you gave the Mathematica input an additional minus
sign and secondly what do you assume to be 'the correct value (tm)'
of (-1)^(1/9)?
Andre'
--
Andre' Poenitz, TU Chemnitz-Zwickau, Fakultaet fuer Mathematik
poe...@mathematik.tu-chemnitz.de .......... +49 3727 58 1381
har...@yahoo.com
mc...@cs.concordia.ca (MCKAY john) wrote:
>
> This expression is easy to simplify by hand.
> What torture does your CAS take you through to do the same ?
> Which one is most painless ?
>
> x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
Macsyma 2.2 symplifies it to -3 by just copying and pasting the original
problem (without the = sign). Does Macsyma get a smiley face?
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Sam Dooley
MCKAY john wrote:
> This expression is easy to simplify by hand.
> What torture does your CAS take you through to do the same ?
> Which one is most painless ?
>
> x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
> --
> Cogito ergo sum aut miror ergo sim.
John,
Perhaps you could give us an idea of which "easy" simplification you
have in mind?
Or to amplify on Andre's post, if by (-1)^(1/9) you mean (-1), then the
expression
simplifies to - (-1)^2 - (-1)^8 + (-1)^5 = - 1 - 1 - 1 = -3 and so Mma
gets a :-(
If on the other hand by (-1)^(1/9) you mean cos(pi/9) + i sin(pi/9),
then the expression
(eventually, but not easily) simplifies to 0 and Mma gets a :-)
So since Mma just picks one, it at best can be said to get a :-|
Maple, by refusing to pick, avoids picking the "wrong" one (by which I
only mean,
the one you did not intend), but then doesn't really move the problem
along either :-|
So if you'll allow me to rephrase your question:
Can you use your CAS to help you simplify x to each of -3 and 0?
In other words, can you pick what you mean by (-1)^(1/9)?
Is it equally painless to make either choice, and how painless is it?
Sam
Robert Harley
mc...@cs.concordia.ca (MCKAY john) writes:
> This expression is easy to simplify by hand.
> What torture does your CAS take you through to do the same ?
> Which one is most painless ?
>
> x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
I'd say it's not clear what this means. Do you choose the same ninth
root of -1 each time? Assuming that you do, it's an 18-th root of
unity but not a ninth root so it's either primitive 18-th, sixth or second:
? lift(Mod(-x^2-x^8+x^5,polcyclo(18)))
time = 0 ms.
%1 = 0
? lift(Mod(-x^2-x^8+x^5,polcyclo(6)))
time = 0 ms.
%2 = -3*x + 3
? lift(Mod(-x^2-x^8+x^5,polcyclo(2)))
time = 0 ms.
%3 = -3
The following paper gives a general method for simplifying "stuff in
cyclotomic fields":
Wieb Bosma
"Canonical bases for Cyclotomic Fields"
AAECC (Applicable Algebra in Engineering, Communication and Computing)
Volume 1, Number 2 (1990), pages 125..134.
Bye,
Rob.
Joseph Riel
MCKAY john (mc...@cs.concordia.ca) wrote:
: This expression is easy to simplify by hand.
: x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
: --
Maple,
radnormal(x);
0
Joe Riel
--
j...@sparc.sandiegoca.ncr.com
Richard J. Fateman
executive summary...
Just in case this is not entirely clear, in at least some peoples'
view, the REALLY WRONG ANSWER IS FROM MATHEMATICA!
Here is what I'm referring to:
(comments are at the bottom)
In article <rz7af81...@corton.inria.fr>,
Robert Harley <har...@corton.inria.fr> wrote:
>mc...@cs.concordia.ca (MCKAY john) writes:
>> This expression is easy to simplify by hand.
>> What torture does your CAS take you through to do the same ?
>> Which one is most painless ?
>>
>> x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
>
>I'd say it's not clear what this means. Do you choose the same ninth
>root of -1 each time? Assuming that you do, it's an 18-th root of
>unity but not a ninth root so it's either primitive 18-th, sixth or second:
>
>? lift(Mod(-x^2-x^8+x^5,polcyclo(18)))
>time = 0 ms.
>%1 = 0
>? lift(Mod(-x^2-x^8+x^5,polcyclo(6)))
>time = 0 ms.
>%2 = -3*x + 3
>? lift(Mod(-x^2-x^8+x^5,polcyclo(2)))
>time = 0 ms.
>%3 = -3
>
>
>The following paper gives a general method for simplifying "stuff in
>cyclotomic fields":
>
> Wieb Bosma
> "Canonical bases for Cyclotomic Fields"
> AAECC (Applicable Algebra in Engineering, Communication and Computing)
> Volume 1, Number 2 (1990), pages 125..134.
>
>Bye,
> Rob.
One could argue that any multi-valued expression is ambiguous.
That is, since sqrt(3) could be + or -, one could say
sqrt(3)+sqrt(3) is
0, 2*sqrt(3) or -2*sqrt(3).
This is not a very common interpretation, and only an argumentative
human or perhaps a CAS would generate such a folly.
So assuming for the sake of argument that all ninth roots of -1
in the expression are the same ninth root of -1, there are then
9 such roots, among them -1. In some sense -1 is an inadequate
representative of the ninth roots of -1, because powers of it do
not generate the other ninth roots. Another, better root
(primitive root) is exp((i pi)/9). These can be expressed in
complex exponentials, or by cos + i sin expressions or, in many
cases, surd expressions like
q=1/2 - i*sqrt(3)/2
where in this case sqrt(3) is the positive sqrt. This is a
ninth root of -1.
if m = a ninth root of unity, the expression in question
is -m^8+m^5-m^2
among the values possible for this expression: -3, 0, and
3/2 +i*3*sqrt(3)/2 (when m=q given above)as well as
3/2 -i*3*sqrt(3)/2
So the answer to the original simplification query, in
my opinion, could be given as
{0,-3, 3/2 -i*3*sqrt(3)/2, 3/2 +i*3*sqrt(3)/2}
or some equivalent expression. While 0 might be a useful value,
it is not the full answer. Some expressions CAN be simplified
to single values because the value is the same regardless
of the the choice of the root. This isn't one of them.
Just in case you think I'm being ornery, there are a host
of benchmark problems that CAS systems have gotten wrong
by making incorrect calculations of roots. Typically they
arise by taking a foolish choice of root in the process
of integrating expressions like 1/sqrt(1-a*cos(x)).
--
Richard J. Fateman
fat...@cs.berkeley.edu http://http.cs.berkeley.edu/~fateman/
David L. Johnson
In article <Pine.GSO.3.96.980529144348.12341C-100000@neuro>,
Julian Stoev <st...@SPAM-RE-MO-VER-usa.net> writes:
> On 28 May 1998, MCKAY john wrote:
>
>|What torture does your CAS take you through to do the same ?
>|Which one is most painless ?
>|
>| x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
>
> In[1]:= Simplify[-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9)]
> Out[1]= 0
>:-)
>
> MapleV.3
>> simplify((-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
>
> 2/9 8/9 5/9
> (-1) - (-1) + (-1)
>:-(
I would definitely turn those faces around. IMO it is much worse to
confidently give only one of the possible answers to an ambiguous question
than to refuse to make specific assumtions unless you tell it to do so.
Another response gave a Maple command, radnormal, which is written to
specifically take principal branches, and says so. Otherwise, it responds
as above, indicating that, without some assumption, there is no unique
answer.
However, Mathematica's simplify command doesn't give any such indication.
When you take roots of any number, you introduce a choice. For square
roots, it's only a +/- to worry about, and, given positive real numbers,
most people ignore that issue. However, there are 9 different values for
(-1)^2/9 (and the others, so your x really could, with equal correctness,
be any of dozens of different values.
This is a long-standing problem with any CAS, and IMO Mathematica tends to
fall into the trap more than Maple. To give a wrong answer, or only one of
several possible answers, is worse than giving none. In the latter case,
you are perhaps encouraged to look into the problem further.
--
David L. Johnson dl...@lehigh.edu, dl...@netaxs.com
Department of Mathematics http://www.lehigh.edu/~dlj0/dlj0.html
Lehigh University
14 E. Packer Avenue (610) 758-3759
Bethlehem, PA 18015-3174
Bill Mitchell
Julian Stoev <st...@SPAM-RE-MO-VER-usa.net> writes:
-
- On 28 May 1998, MCKAY john wrote:
-
- |This expression is easy to simplify by hand.
- |What torture does your CAS take you through to do the same ?
- |Which one is most painless ?
- |
- | x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
-
- Mathematica 3.0:
- In[1]:= Simplify[-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9)]
- Out[1]= 0
- :-)
-
MapleV.4
> f := x -> -x^2 - x^8 + x^5:
> S := [allvalues(RootOf(x^9=-1))]:
> map(simplify@f,S);
[-3, 3/2+3/2*I*3^(1/2), 3/2-3/2*I*3^(1/2), 0, 0, 0, 0, 0, 0]
Much less work with Mathematica, and Mathematica is right 6 times out of 9.
--
Bill Mitchell
Dept of Mathematics, The University of Florida
PO Box 118105, Gainesville, FL 32611--8105
mitc...@math.ufl.edu (352) 392-0281 x284
smudge
MCKAY john (mc...@cs.concordia.ca) wrote:
: This expression is easy to simplify by hand.
: What torture does your CAS take you through to do the same ?
:
: x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
GNU Maxima 5.2:
(C1) -(-1)**(2/9) - (-1)**(8/9) + (-1)**(5/9);
(D1) - 3
I'm not sure this adds much to the discussion since, as a previous poster
pointed out, the answer depends on what form is assumed for (-1)^(1/9).
How should a computer algerbra system simplify this expression? I suppose
it depends on how it will be used. Maple seems to take the conservative
route, i.e. if the interpretation of the term is ambiguous then don't do
anything. This spares the system from delivering an answer that may be
erroneous, depending on the context in which it's used.
Both Mathematica and Maxima choose a form and simplify, each to a
different result. Another possibility is for the system, in cases of
ambiguity, to ask the user for information that will help it proceed. I
believe Macsyma does this in some cases. Other systems, like Axiom, use a
type system to help resolve ambiguities.
These issues are complex, and the developers of computer algebra systems
have been grappling with them for a long time. The approach chosen can
have a profound affect on the architecture of such systems.
--smudge
Daniel Lichtblau
I'll put the bottom line at the top. The Mathematica result is
completely, entirely, 100% correct according to documented Mathematica
semantics. --dl
David L. Johnson wrote:
>
> In article <Pine.GSO.3.96.980529144348.12341C-100000@neuro>,
> Julian Stoev <st...@SPAM-RE-MO-VER-usa.net> writes:
> > On 28 May 1998, MCKAY john wrote:
> >
> >|This expression is easy to simplify by hand.
> >|What torture does your CAS take you through to do the same ?
> >|Which one is most painless ?
> >|
> >| x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
> >
> > Mathematica 3.0:
> > In[1]:= Simplify[-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9)]
> > Out[1]= 0
> >:-)
> >
> > MapleV.3
> >> simplify((-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
> >
> > 2/9 8/9 5/9
> > (-1) - (-1) + (-1)
> >:-(
>
> I would definitely turn those faces around. IMO it is much worse to
> confidently give only one of the possible answers to an ambiguous question
> than to refuse to make specific assumtions unless you tell it to do so.
> Another response gave a Maple command, radnormal, which is written to
> specifically take principal branches, and says so. Otherwise, it responds
> as above, indicating that, without some assumption, there is no unique
> answer.
>
> However, Mathematica's simplify command doesn't give any such indication.
It has nothing to do with Simplify or overconfidence or hidden
assumptions. In Mathematica the semantics of radicals specify that we
use the principal root. This is clearly documented on p.733 of the
manual. References are found in the index under "principal roots,"
"radicals," "roots of complex numbers," and perhaps elsewhere.
It is a matter of taste whether this choice is preferable to other
possibilities. If you want to graph x^(1/3) from -2 to 2 then you need
to do some extra work to obtain the real root for negative x. That said,
I think that what we do is the obvious thing. As opposed to assigning NO
value (that is, letting radicals stand for generic "multi-valued"
objects), it means one can obtain numerical values, represent roots of
equations that are solvable in radicals correctly and unambiguously,
etc. Moreover one can obtain other roots simply by using appropriate
roots of unity, and it is quite clear exactly what is meant by a given
numeric radical. Also it allows for a clear meaning to be ascribed to
radicals of Gaussians; I am not certain that other conventions are so
useful in that regard.
> When you take roots of any number, you introduce a choice. For square
> roots, it's only a +/- to worry about, and, given positive real numbers,
> most people ignore that issue. However, there are 9 different values for
> (-1)^2/9 (and the others, so your x really could, with equal correctness,
> be any of dozens of different values.
>
> This is a long-standing problem with any CAS, and IMO Mathematica tends to
> fall into the trap more than Maple. To give a wrong answer, or only one of
> several possible answers, is worse than giving none. In the latter case,
> you are perhaps encouraged to look into the problem further.
>
I'd be happy to discuss or pass along to relevant developers any
specific Mathematica examples you might have.
Daniel Lichtblau
Wolfram Research
Herb Brown
In article <896423849.27375.0...@news.demon.co.uk>,
Allan Hayes <h...@haystack.demon.co.uk> wrote:
>
>MCKAY john wrote in message <6kkoeg$dlt$1...@newsflash.concordia.ca>...
>>What torture does your CAS take you through to do the same ?
>>Which one is most painless ?
>>
>> x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
>
>
>
>x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
>
>Simplify[x]
>
>0
>
>-------------------------------------------------------------
>Allan Hayes
>Mathematica Training and Consulting
>Leicester UK
>http://www.haystack.demon.co.uk
>h...@haystack.demon.co.uk
>voice: +44 (0)116 271 4198
>fax: +44(0)116 271 8642
>
>
Allan,
I don't quite understand Mathematica's answer and how it chooses
the value to assign to (-1)^(1/9)?
Herb
--
_________________________________________________________
Herbert I Brown hib...@math.albany.edu (518) 442-4640
Math Dept, The Univ at Albany, Albany, NY 12222
Director, Computer Assisted Instruction in Mathematics
Jeffrey P. Golden
Reply-To: j...@macsyma.com
> Date: 28 May 1998 22:28:32 GMT
> From: mc...@cs.concordia.ca (MCKAY john)
> Subject: Simplify torture
> Organization: Computer Science, Concordia University, Montreal, Quebec
>
> This expression is easy to simplify by hand.
> What torture does your CAS take you through to do the same?
> Which one is most painless?
>
> x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
Not as succinct as with Mathematica, but here are two solutions
gotten via Macsyma:
----------------------------------------------------------------------
/* Tell Macsyma you want to compute with principal branches: */
(c1) domain:complex$
/* Two solutions. Solution 1: */
(c2) rectform(-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
2 %pi %pi %pi 2 %pi %pi
(d2) %i (- sin(-----) - sin(---) + cos(---)) - cos(-----) + cos(---)
9 9 18 9 9
%pi
- sin(---)
18
/* TRIGCONTRACT transforms a sum of trigonometric functions
into a product of trigonometric functions. */
(c3) trigcontract(%);
(d3) 0
/* Solution 2: */
(c4) map(polarform,-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9));
5 %i %pi %i %pi 7 %i %pi
-------- - ------ - --------
9 9 9
(d4) %e + %e + %e
(c5) ratsimp(%);
(d5) 0
----------------------------------------------------------------------
From: Jeffrey P. Golden <j...@macsyma.com>
Organization: Macsyma Inc.
Reply-To: j...@macsyma.com
URL: http://www.macsyma.com
Jeffrey P. Golden
Reply-To: j...@macsyma.com
> Date: Fri, 29 May 1998 09:17:34 -0400
> From: Sam Dooley <doo...@watson.ibm.com>
> Subject: Re: Simplify torture
> Organization: IBM Microelectronics Division
>
> MCKAY john wrote:
> > This expression is easy to simplify by hand.
> > What torture does your CAS take you through to do the same?
> > Which one is most painless?
> > x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
>
> John, Perhaps you could give us an idea of which "easy" simplification
> you have in mind?
>
> Or to amplify on Andre's post, if by (-1)^(1/9) you mean (-1), then the
> expression simplifies to - (-1)^2 - (-1)^8 + (-1)^5 = - 1 - 1 - 1 = -3
> and so Mma gets a :-(
>
> If on the other hand by (-1)^(1/9) you mean cos(pi/9) + i sin(pi/9),
> then the expression
> (eventually, but not easily) simplifies to 0 and Mma gets a :-)
>
> So since Mma just picks one, it at best can be said to get a :-|
>
> Maple, by refusing to pick, avoids picking the "wrong" one (by which I
> only mean, the one you did not intend), but then doesn't really move
> the problem along either :-|
>
> So if you'll allow me to rephrase your question:
>
> Can you use your CAS to help you simplify x to each of -3 and 0?
> In other words, can you pick what you mean by (-1)^(1/9)?
> Is it equally painless to make either choice, and how painless is it?
As was noted yesterday, Macsyma will simplify John McKay's x to
either -3 by default; or to 0; but getting 0 is much harder:
-------------------------------------------------------------------
/* The computation domain in Macsyma is by default real. Daniel
Lichtblau of Wolfram Research said yesterday about Mathematica:
"If you want to graph x^(1/3) from -2 to 2 then you need to do
some extra work to obtain the real root for negative x."
In Macsyma, it is important to us to make this be easy. */
(c1) domain;
(d1) real
(c2) -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
(d2) - 3
/* To do a principal branch computation here with Macsyma, you set
domain to complex: */
(c3) block([domain:complex],
trigcontract(rectform(-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9))));
(d3) 0
/* Macsyma can return any of four results for (-1)^(1/9) : */
/* f(x) = x^(1/3) mapping reals to reals: */
(c4) domain;
(d4) real
(c5) (-1)^(1/9);
(d5) - 1
(c6) domain:complex$
/* Unchanged, if you like: */
(c7) (-1)^(1/9);
1/9
(d7) (- 1)
/* A polar form: */
(c8) polarform((-1)^(1/9));
%i %pi
------
9
(d8) %e
/* Or a rectangular form: */
(c9) rectform((-1)^(1/9));
%pi %pi
(d9) %i sin(---) + cos(---)
9 9
David L. Johnson
In article <356F00C2...@wolfram.com>,
> It has nothing to do with Simplify or overconfidence or hidden
> assumptions. In Mathematica the semantics of radicals specify that we
> use the principal root. This is clearly documented on p.733 of the
> manual. References are found in the index under "principal roots,"
> "radicals," "roots of complex numbers," and perhaps elsewhere.
>
I don't think that a disclaimer on page 733 of the reference manual is the
way to handle this. People use the output of these programs with far too
little examnination as it is, and when the machine gives an answer, even if
6 of 10 of the possible answers agree with it, it may not be what is needed
for a given problem, and that should be made clear.
> It is a matter of taste whether this choice is preferable to other
> possibilities.
I'm sorry, but that is wrong. It is not merely a matter of taste whether
the principal root is the correct one or not. It really does depend on the
problem. There are many examples of problems where the principal root is
_not_ what is needed. More realistically, someone using these programs
should be aware of branch ambiguities. The best way to do that is for the
machine to ask for more information. The worst way is to simply make
assumptions without the user's involvement.
Richard J. Fateman
In article <356F00C2...@wolfram.com>,
Daniel Lichtblau <da...@wolfram.com> wrote:
>I'll put the bottom line at the top. The Mathematica result is
>completely, entirely, 100% correct according to documented Mathematica
>semantics. --dl
>It has nothing to do with Simplify or overconfidence or hidden
>assumptions. In Mathematica the semantics of radicals specify that we
>use the principal root. This is clearly documented on p.733 of the
>manual. References are found in the index under "principal roots,"
>"radicals," "roots of complex numbers," and perhaps elsewhere.
>
>It is a matter of taste whether this choice is preferable to other
>possibilities.
...
>I think that what we do is the obvious thing. As opposed to assigning NO
>value (that is, letting radicals stand for generic "multi-valued"
>objects), it means one can obtain numerical values, represent roots of
>equations that are solvable in radicals correctly and unambiguously,...
I think this explanation is inadequate, because it results
in inconsistencies, some of which are entirely hidden from view
inside Mathematica, but which result in answers that are
wrong.
On the other hand, it seems like we are
arguing with Humpty Dumpty. (from "Through the Looking Glass")
....
`When _I_ use a word,' Humpty Dumpty said in rather a scornful
tone, `it means just what I choose it to mean - neither more nor
less.'
`The question is,' said Alice, `whether you CAN make words mean
so many different things.'
`The question is,' said Humpty Dumpty, `which is to be master -
that's all.'
......
The damage is done not with the interpretation of roots of constants,
but from the view that radicals can be treated this way in general.
The treatment of the extension of radicals to functions is not done
by principal roots. [by which I take it that Mathematica chooses
for positive radicand the positive root, and for negative radicands
that root in the complex plane with the smallest positive angle]
If you solve quartics etc with symbolic coefficients you get into
considerably more hot water than with numerical coefficients.
If Mathematica documentation has in general attempted to define away
the symbolic math problem by defining radicals as being their
principal roots, it should make algebraists and others uncomfortable.
One of the consequences is that Solving[x^p==a] gives only 1 root,
a^(1/p), whereas many people would be unhappy with the consequences of
this result when somewhere downstream when we learn that (say) p=5 and
a=-1. There are now 5 roots, not one.
In section 3.2.7 of the Mathematica documentation there is a discussion
of branch cuts, and the section states that "unique 'principal' values
nevertheless have to be chosen."
......
`The cause of lightning,' Alice said very decidedly, for she
felt quite certain about this, `is the thunder - no, no!' she hastily
corrected herself. `I meant the other way.'
`It's too late to correct it,' said the Red Queen: `when you've once
said a thing, that fixes it, and you must take the consequences.'
......
It is possible for computer algebra systems to work with
multiple-valued functions and specifically useful to do so. I believe
Mathematica "chooses" not to do so primarily because its original
design backed it into a corner, and "you must take the consequences".
Daniel Lichtblau
>I don't think that a disclaimer on page 733 of the reference manual
>is the way to handle this.
It is not a disclaimer. It is documentation of a particular choice among
conventions-- a common one in fact-- that Mathematica uses.
>People use the output of these programs with far to little
>examnination as it is, and when the machine gives an answer, even
>if 6 of 10 of the possible answers agree with it, it may not be
>what is needed for a given problem, and that should be made clear.
In the example given, the lack of examination was not in the answer but
in the question. If by (-1)^(1/9) you mean -1 then you are using
Mathematica incorrectly. This is a simple case of RTFM. As I stated, the
Mathematica output of 0 is 100% correct (not 60%) for the input of
Simplify[-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9)]
>> It is a matter of taste whether this choice is preferable to other
>> possibilities.
>I'm sorry, but that is wrong. It is not merely a matter of taste
>whether the principal root is the correct one or not. It really does
>depend on the problem. There are many examples of problems where
>the principal root is _not_ what is needed...
Your remarks pretty well demonstrate my point. You do not like the
convention we use (or so I infer), and that IS a matter of taste. But it
is documented usage, it is demonstrably viable, it is easily found in
the reference, etc. etc. It is even straightforward to convert from the
convention we use to others. If you think this is a minor issue, try to
express in radicals the principal seventh root of -1. In Mathematica
this is simply (-1)^(1/7). How do you express it if your convention is
to take (-1)^(1/7) to be -1? And what would you make of (1-3*I)^(1/3)?
Or of radical solutions for x^3 - 4*x - 2?
>...More realistically, someone using these programs should be aware of
>branch ambiguities. The best way to do that is for the machine to
>ask for more information...
Asking for more information is one way around this difficulty. I do not
believe any system noted in this thread does so for the example posted.
To do so at the very least would clobber any attempt to use numerical
evaluation inside a program that contained such radical expressions.
This would be no small inconvenience.
If you really want to take Wolfram Research to task for not handling the
above Simplify problem by asking questions, then you need to include the
vendors of every other program cited in this thread, because none handle
it in the manner you desire. This could indicate that none of us on the
implementation end know what we are about. Or it could mean that what
you want may not be such a good thing.
>...The worst way is to simply make assumptions without the user's
>involvement.
I reiterate: Mathematica made no such assumptions. We have a case where
the user failed to check easily accessible documentation. Moreover in
using a convention for interpretion of radicals Mathematica does the
same as every other program mentioned in this thread, though one
apparently chooses a different convention.
Daniel Lichtblau
Wolfram Research
Daniel Lichtblau
Richard J. Fateman wrote:
>
> In article <356F00C2...@wolfram.com>,
> Daniel Lichtblau <da...@wolfram.com> wrote:
> >I think that what we do is the obvious thing. As opposed to assigning NO
> >value (that is, letting radicals stand for generic "multi-valued"
> >objects), it means one can obtain numerical values, represent roots of
> >equations that are solvable in radicals correctly and unambiguously,...
>
> I think this explanation is inadequate, because it results
> in inconsistencies, some of which are entirely hidden from view
> inside Mathematica, but which result in answers that are
> wrong.
For example?
> On the other hand, it seems like we are
> arguing with Humpty Dumpty...
> [silly ad hominem attack deleted --dl]
> The damage is done not with the interpretation of roots of constants,
> but from the view that radicals can be treated this way in general.
> The treatment of the extension of radicals to functions is not done
> by principal roots. [by which I take it that Mathematica chooses
> for positive radicand the positive root, and for negative radicands
> that root in the complex plane with the smallest positive angle]
>
> If you solve quartics etc with symbolic coefficients you get into
> considerably more hot water than with numerical coefficients.
An example? (Translation: "No you do not").
> If Mathematica documentation has in general attempted to define away
> the symbolic math problem by defining radicals as being their
> principal roots, it should make algebraists and others uncomfortable.
Mathematica has done no such thing.
> One of the consequences is that Solving[x^p==a] gives only 1 root,
> a^(1/p), whereas many people would be unhappy with the consequences of
> this result when somewhere downstream when we learn that (say) p=5 and
> a=-1. There are now 5 roots, not one.
It is a transcendental equation. I make no pretense that I can provide
all (infinitely many) roots of such. Let alone detect that they collapse
into finitely many in the limit as the exponent approaches integer
values.
By the way, the behavior you describe is evinced by most, perhaps all,
symbolic software programs (but you knew this because you checked a few,
right?). So you might want to extend your indictment from Mathematica to
the rest of the industry. It will at least give some consistency to your
arguments. At present the situation is
(i) Mathematica documents clearly how it handles numeric radicals.
(ii) Said convention is quite common.
(iii) Mathematica makes easy work of simplifying
-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9) to zero, given the documented
convention.
(iv) Other programs cited in the thread use the same convention but
cannot do the simplification using their generic "simplify" commands.
They must instead use less obvious methods. While this is not
necessarily a bad thing, but it can hardly be a weakness that
Mathematica DOES do the job using Simplify[].
> [another Looking Glass quote snipped --dl]
> It is possible for computer algebra systems to work with
> multiple-valued functions and specifically useful to do so. I believe
> Mathematica "chooses" not to do so primarily because its original
> design backed it into a corner, and "you must take the consequences".
>
here you are lacking
(i) useful (or even any) examples of relevant misbehavior and proposed
better behavior
(ii) a program with which to compare, that does something (dare I say)
radically different.
If you have some examples I will of course be happy to ponder them.
Though again, they will likely have less to say about Mathematicva than
about the general state of symbolic manipulation. Of course you can
continue to bash Mathematica on this topic, though I think you will only
make yourself look pedantically silly. But in a cute sort of way.
> --
> Richard J. Fateman
> fat...@cs.berkeley.edu http://http.cs.berkeley.edu/~fateman/
Daniel Lichtblau
Wolfram Research
Richard J. Fateman
In article <3572DE47...@wolfram.com>,
Daniel Lichtblau <da...@wolfram.com> wrote:
>Richard J. Fateman wrote:
>>
>> In article <356F00C2...@wolfram.com>,
>> Daniel Lichtblau <da...@wolfram.com> wrote:
>> [snip --dl]
>
>For example?
{The first and simplest example that I tried found a bug.
consider x^4+b*x^3+c*x^2+d*x+1==0
Solve it for x
substitute b,c,d ->1
Call FullSimplify on the result.
(I got answers like x->Root[1+#^2+#^3+#^4&,1], which seems to
be wrong by a sign, at least at first glance.)
Try %//N on that for a numerical result.
Then compute NSolve[] on the original.
I got quite different answers. Maybe you could try it and see what
you get, just in case I made some typing error..
I cannot spend the time to diagnose where this went wrong. For
the amount you pay bug finders $0.00, I think I'm being
overly generous!}
[is calling an alleged ad hominem attack silly an
ad hominem attack? I deleted it too! --RJF]
>
>
>> The damage is done not with the interpretation of roots of constants,
>> but from the view that radicals can be treated this way in general.
>> The treatment of the extension of radicals to functions is not done
>> by principal roots. [by which I take it that Mathematica chooses
>> for positive radicand the positive root, and for negative radicands
>> that root in the complex plane with the smallest positive angle]
>>
>> If you solve quartics etc with symbolic coefficients you get into
>> considerably more hot water than with numerical coefficients.
>
>An example? (Translation: "No you do not").
See above. I am sure there are others.
>
>
>> If Mathematica documentation has in general attempted to define away
>> the symbolic math problem by defining radicals as being their
>> principal roots, it should make algebraists and others uncomfortable.
>
>Mathematica has done no such thing.
>
{The evidence that mathematica has made algebraists uncomfortable is
shown by the newsgroup! The fact is when you peel off ONE root,
even if it is one you have every reason to believe is some kind
of canonical "right" root, there will be situations in which it
is a wrong one, and only the realization that it is one of
a collection of possible roots will get you further in your
computation.}
>> One of the consequences is that Solving[x^p==a] gives only 1 root,
>> a^(1/p), whereas many people would be unhappy with the consequences of
>> this result when somewhere downstream when we learn that (say) p=5 and
>> a=-1. There are now 5 roots, not one.
>
>It is a transcendental equation. I make no pretense that I can provide
>all (infinitely many) roots of such. Let alone detect that they collapse
>into finitely many in the limit as the exponent approaches integer
>values.
Why not? I thought that Mathematica was "a system for representing
knowledge" and now you seem to be saying you can't provide a representation
for this knowledge.
>
>By the way, the behavior you describe is evinced by most, perhaps all,
>symbolic software programs (but you knew this because you checked a few,
>right?). So you might want to extend your indictment from Mathematica to
>the rest of the industry. It will at least give some consistency to your
>arguments. At present the situation is
>
>(i) Mathematica documents clearly how it handles numeric radicals.
>(ii) Said convention is quite common.
>(iii) Mathematica makes easy work of simplifying
>-(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9) to zero, given the documented
>convention.
>(iv) Other programs cited in the thread use the same convention but
>cannot do the simplification using their generic "simplify" commands.
>They must instead use less obvious methods. While this is not
>necessarily a bad thing, but it can hardly be a weakness that
>Mathematica DOES do the job using Simplify[].
{I didn't check them. Macsyma has its domain declarations and
assume. Maple has some half-implemented assume facility too.
Neither has, so far as I know, an ability to deal neatly
with "multiple values". Does Mathematica 3.0 have domain declarations
or assume facilities?}
Anyone could write a program that says
"take all simplification programs and apply them. pick the smallest
answer".
I have examples that Simplify[] fails on, but FullSimplify[] works
on, involving radicals.
And as far as that goes, how many other CAS programs can return
an answer (-1+x)/(-x+1) ??
>
>> It is possible for computer algebra systems to work with
>> multiple-valued functions and specifically useful to do so. I believe
>> Mathematica "chooses" not to do so primarily because its original
>> design backed it into a corner, and "you must take the consequences".
>>
>
>here you are lacking
>(i) useful (or even any) examples of relevant misbehavior and proposed
>better behavior
See SIGSAM Bulletin vol 30 no 2 p 8-11, for example.
>(ii) a program with which to compare, that does something (dare I say)
>radically different.
I have written such programs, and they are available in the open
literature. See my paper in ISSAC 94 with Adam Dingle. You've had
4 years to implement it. It is also posted on my web page.
>
>If you have some examples I will of course be happy to ponder them.
>Though again, they will likely have less to say about Mathematicva than
>about the general state of symbolic manipulation.
Well, they talk about both.
Of course you can
>continue to bash Mathematica on this topic, though I think you will only
>make yourself look pedantically silly. But in a cute sort of way.
Hey, glad to provide some amusement.
David L. Johnson
>> If Mathematica documentation has in general attempted to define away
>> the symbolic math problem by defining radicals as being their
>> principal roots, it should make algebraists and others uncomfortable.
>
> Mathematica has done no such thing.
>
equations.
>
>> One of the consequences is that Solving[x^p==a] gives only 1 root,
>> a^(1/p), whereas many people would be unhappy with the consequences of
>> this result when somewhere downstream when we learn that (say) p=5 and
>> a=-1. There are now 5 roots, not one.
>
> It is a transcendental equation. I make no pretense that I can provide
> all (infinitely many) roots of such.
What? x^5=-1 is an algebraic equation. That is what Fateman was referring
to.
Let alone detect that they collapse
> into finitely many in the limit as the exponent approaches integer
> values.
>
> By the way, the behavior you describe is evinced by most, perhaps all,
> symbolic software programs (but you knew this because you checked a few,
> right?).
As was pointed out, Maple, for example, at least does not answer the
question. This is preferred, since the question is ambiguous, to giving an
answer which has inherent assumptions that the user may well be unaware of.
> (i) Mathematica documents clearly how it handles numeric radicals.
> (ii) Said convention is quite common.
Whether it is common, or not, it is still mathematically incorrect.
> (iii) Mathematica makes easy work of simplifying
> -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9) to zero, given the documented
> convention.
> (iv) Other programs cited in the thread use the same convention but
> cannot do the simplification using their generic "simplify" commands.
This is not necessarily the situation, and if this is offerred as a
particular strength of Mathematica's Simplify[] command, it is troubling.
There are situations where one might really want such a form to assume the
real roots, others where the principal roots are correct, and still others
where a "continued" choice of roots is the only correct answer, one which,
based on the equation, comes from evaluating the complex argument at points
along the circle. Now, why should Mathematica presume one is correct?
> They must instead use less obvious methods. While this is not
> necessarily a bad thing, but it can hardly be a weakness that
> Mathematica DOES do the job using Simplify[].
Yes, it is a weakness.
> Of course you can
> continue to bash Mathematica on this topic, though I think you will only
> make yourself look pedantically silly. But in a cute sort of way.
Didn't you, earlier, object to "ad hominem attacks"?
Michael Trott
In sci.math.symbolic article <6kusjn$87t$1...@agate.berkeley.edu> you wrote:
> In article <3572DE47...@wolfram.com>,
> Daniel Lichtblau <da...@wolfram.com> wrote:
> >Richard J. Fateman wrote:
> {The first and simplest example that I tried found a bug.
>
> consider x^4+b*x^3+c*x^2+d*x+1==0
> Solve it for x
> substitute b,c,d ->1
> Call FullSimplify on the result.
>
> (I got answers like x->Root[1+#^2+#^3+#^4&,1], which seems to
> be wrong by a sign, at least at first glance.)
> Try %//N on that for a numerical result.
Can you elaborate on this some more?
The example you gave worked just fine for me:
In[1]:= p=x^4+b*x^3+c*x^2+d*x+1;
In[2]:= sol1=Solve[p == 0,x]/.{b -> 1,c -> 1, d ->1};
(* the numerical solution obtained by numericalizing the radicals *)
In[3]:= nsol1 = N[sol1, 30]
Out[3]= {{x -> -0.80901699437494742410229341718 -
> 0.58778525229247312916870595464 I},
> {x -> -0.80901699437494742410229341718 +
> 0.58778525229247312916870595464 I},
> {x -> 0.309016994374947424102293417183 -
> 0.95105651629515357211643933338 I},
> {x -> 0.309016994374947424102293417183 +
> 0.95105651629515357211643933338 I}}
In[4]:= p1 = p /. {b -> 1,c -> 1, d ->1};
(* the solution is correct *)
In[5]:= p1 /. nsol1
-29 -29 -29 -29 -29 -29
Out[5]= {0. 10 + 0. 10 I, 0. 10 + 0. 10 I, 0. 10 + 0. 10
I,
-29 -29
> 0. 10 + 0. 10 I}
(* the symbolic solution in Root objects *)
In[6]:= sol2 = RootReduce[sol1]
2 3 4
Out[6]= {{x -> Root[1 + #1 + #1 + #1 + #1 & , 1]},
2 3 4
> {x -> Root[1 + #1 + #1 + #1 + #1 & , 2]},
2 3 4
> {x -> Root[1 + #1 + #1 + #1 + #1 & , 3]},
2 3 4
> {x -> Root[1 + #1 + #1 + #1 + #1 & , 4]}}
(* the numerical solution obtained by numericalizing the Root objects *)
In[7]:= nsol2 = N[sol2, 30]
Out[7]= {{x -> -0.80901699437494742410229341718 -
> 0.58778525229247312916870595464 I},
> {x -> -0.80901699437494742410229341718 +
> 0.58778525229247312916870595464 I},
> {x -> 0.309016994374947424102293417183 -
> 0.95105651629515357211643933338 I},
> {x -> 0.309016994374947424102293417183 +
> 0.95105651629515357211643933338 I}}
(* the solution is correct again *)
In[8]:= p1 /. nsol2
-29 -29 -29 -29 -29 -29
Out[8]= {0. 10 + 0. 10 I, 0. 10 + 0. 10 I, 0. 10 + 0. 10
I,
-29 -29
> 0. 10 + 0. 10 I}
(* switching back to radicals *)
In[9]:= sol3 = ToRadicals[sol1];
Out[10]= {{x ->
> -0.80901699437494742410229341718 - 0.58778525229247312916870595464
I},
> {x -> -0.80901699437494742410229341718 +
> 0.58778525229247312916870595464 I},
> {x -> 0.309016994374947424102293417183 -
> 0.95105651629515357211643933338 I},
> {x -> 0.309016994374947424102293417183 +
> 0.95105651629515357211643933338 I}}
(* things still work fine *)
In[11]:= p1 /. nsol3
-29 -29 -29 -29
Out[11]= {0. 10 + 0. 10 I, 0. 10 + 0. 10 I,
-29 -29 -29 -29
> 0. 10 + 0. 10 I, 0. 10 + 0. 10 I}
--
Michael Trott
Wolfram Research, Inc.
Daniel Lichtblau
David L. Johnson wrote:
>
> >> If Mathematica documentation has in general attempted to define away
> >> the symbolic math problem by defining radicals as being their
> >> principal roots, it should make algebraists and others uncomfortable.
> >
> > Mathematica has done no such thing.
> >
> But it has, in that those are the roots that are exhibited as solutions of
> equations.
Mathematica returns solutions in terms of parametrized radicals. It
makes no claim about where these live in the complex plane until
specific numerical values are plugged in for all the parameters.
Moreover I am not aware of incorrect results caused by use of
parametrzed radicals. If you are familiar with the cubic and quartic
Cardano formulas you realize that any choice of a root is fine for
nested radicals in the solution set, provided you are consistent with
that choice elsewhere in the formula.
If you can find an example where Mathematica returns an incorrect result
for a quartic, by all means post it for discussion.
> >> One of the consequences is that Solving[x^p==a] gives only 1 root,
> >> a^(1/p), whereas many people would be unhappy with the consequences of
> >> this result when somewhere downstream when we learn that (say) p=5 and
> >> a=-1. There are now 5 roots, not one.
> >
> > It is a transcendental equation. I make no pretense that I can provide
> > all (infinitely many) roots of such.
>
> What? x^5=-1 is an algebraic equation. That is what Fateman was referring
> to.
I think it was clear I meant Solve[x^p==a] is transcendental in x.
Obviously if you FIRST plug in an integer for p this is no longer the
case.
> Let alone detect that they collapse
> > into finitely many in the limit as the exponent approaches integer
> > values.
> >
> > By the way, the behavior you describe is evinced by most, perhaps all,
> > symbolic software programs (but you knew this because you checked a few,
> > right?).
>
> As was pointed out, Maple, for example, at least does not answer the
> question.
Nonsense.
alexandria.wolfram.com [1] danl> maple
|\^/| Maple V Release 5 (Single User)
...
> solve(x^p=a, x);
bytes used=1000216, alloc=786288, time=0.19
ln(a)
exp(-----)
p
This is mathematically equivalent to the Mathematica result.
> > (i) Mathematica documents clearly how it handles numeric radicals.
> > (ii) Said convention is quite common.
>
> Whether it is common, or not, it is still mathematically incorrect.
No. Mathematically it is entirely correct, given the documentation of
convention used. It simply may not be what you want.
I am getting the impression that you do not work alot with symbolic
equation solving or algebraic extensions. Essentially every serious
program behaves not unlike Mathematica on the problems under discussion,
yet you seem to think (i) some do not, and (ii) it's all wrong. The
fault, dear Brutus...may indeed be with the programs (but you ought to
consider the alternative).
> > (iii) Mathematica makes easy work of simplifying
> > -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9) to zero, given the documented
> > convention.
> > (iv) Other programs cited in the thread use the same convention but
> > cannot do the simplification using their generic "simplify" commands.
>
> This is not necessarily the situation, and if this is offerred as a
> particular strength of Mathematica's Simplify[] command, it is troubling.
> There are situations where one might really want such a form to assume the
> real roots, others where the principal roots are correct, and still others
> where a "continued" choice of roots is the only correct answer, one which,
> based on the equation, comes from evaluating the complex argument at points
> along the circle. Now, why should Mathematica presume one is correct?
It is a question of convention, not presumption. If I write (-1)^(1/7)
in Mathematica (and in most other symbolic math programs), it has a
specific meaning. If I want to use something other than the principal
seventh root of -1 then I can specify that something using an
appropriate power. It is up to me, the programmer, to specify correctly
what I mean. If instead I want to work in an abstract algebraic
extension field where the specific root is left unspecified then I need
to do so using a minimal polynomial and appropriate functions e.g.
GroebnerBasis. Algebraically this is the thing to do. Saying that
Mathematica is somehow "wrong" for ascribing a particular value to
(-1)^(1/7) is ignoring a well-documented and consistently used
convention, and also ignoring the fact that rest of the symbolic
computation world is doing likewise, albeit with some variation in
choice of conventions to follow. You really should look further into
this matter because apparently you think this is not the case.
> > They must instead use less obvious methods. While this is not
> > necessarily a bad thing, but it can hardly be a weakness that
> > Mathematica DOES do the job using Simplify[].
>
> Yes, it is a weakness.
As I said, you are failing to understand what is done by other programs.
> > Of course you can
> > continue to bash Mathematica on this topic, though I think you will only
> > make yourself look pedantically silly. But in a cute sort of way.
>
> Didn't you, earlier, object to "ad hominem attacks"?
Maybe I should have put more emphasis on the fact that a particular
program, Mathematica, is being singled out here. Right or wrong, our
treatment of radicals is in essence the same as in every other program
noted in the thread. But for some strange reason only Mathematica is
called "wrong." People who follow this thread (by now no more than a
handful, I imagine) are not stupid, quite the contrary. They will
recognize that the exclusive bashing of ONE particular program is not,
at least in this matter, justified.
I am beginning to understand the choice of name for this thread.
> --
>
> David L. Johnson dl...@lehigh.edu, dl...@netaxs.com
> Department of Mathematics http://www.lehigh.edu/~dlj0/dlj0.html
> Lehigh University
> 14 E. Packer Avenue (610) 758-3759
> Bethlehem, PA 18015-3174
Daniel Lichtblau
Wolfram Research
Richard Fateman
In article <6kva0s$dpk$1...@dragonfly.wolfram.com>,
Michael Trott <mtr...@wri.com> wrote:
I redid the example, and as Michael Trott shows;
typed in correctly, as he did (and I did not), it works.
I'll have to find a better example, presumably one in which
intermediate simplification of a SYMBOLIC result of the
quartic formula result finishes
in a finite time (hard) and gets a misleading answer.
I am confident that if nothing else screws up, PowerExpand
can be relied on. (In earlier email response to da...@wri.com I asked
him to check that I hadn't made a typo... too bad this took up
sci.math.symbolic bandwidth).
(I typed Solve[p==x,x] instead of Solve[p==0,x]. probably because
macsyma allows you to type solve(p,x)...)
In article <6kva0s$dpk$1...@dragonfly.wolfram.com>,
Michael Trott <mtr...@wri.com> wrote:
<big snip>
Apologies for the buggy example.
Michael Wester
>>> x := -(-1)^(2/9)-(-1)^(8/9)+(-1)^(5/9);
So far in all this discussion, nobody has mentioned Derive. What does Derive
do? Derive has a Manage Branch command (equivalent to assigning a value to the
variable Branch). The default is Principal (which produces 0 for the above
expression). The comment in the manual says that the principal branch is the
most widely accepted systematic choice.
Another value for Branch is Real (which produces -3 for the above expression).
The manual comment says that a real branch is selected even if it is not the
principal branch.
The last option is Any which "allows Derive to use the maximum number of
transformations when it does not matter which branch is chosen. For exanmple,
the plus-or-minus `operator' in the quadratic formula constructs both solutions
no matter which branch is chosen for the square root in the formula. In Any
branch mode, Derive applies the transformations
(z^m)^(1/n) -> z^(m/n)
(z w)^(1/n) -> z^(1/n) w^(1/n)
even if the phases of z and w are unknown" [so (x^2)^(1/2) -> x, for example].
I am not quite sure I completely understand the rationale behind this last
choice, but in any case, the above expression produces -3 once again under
this mode.
Clearly, it would be nice to have a mode that produced _all_ possible results
using all consistent branch choices (which could quickly become complicated for
many expressions), but I do like the ease of choosing which branch choice the
program should make.
--
Michael Wester --- wes...@math.unm.edu --- http://math.unm.edu/~wester/
| ``That may be true,'' he acknowledged, ``but it's completely accurate, and as
| long as the answer is right, who cares if the question is wrong? If you want
| sense, you'll have to make it yourself.'' -- "The Phantom Tollbooth": Juster
Andre Poenitz
Bill Mitchell (mitc...@leadbelly.math.ufl.edu.math.ufl.edu) wrote:
: Much less work with Mathematica, and Mathematica is right 6 times out of 9.
Being 'right 6 times out of 9' is of no use whatsoever for practical
applications - at least in my eyes. ('practical application' being
understood as a series of thousands of 'simplifications')
Modern CAS should provide one fool proof method of simplification
(preferably called [sS]implify ;-) ) that does not assume *anything* that
might not hold in a general setting.
Of course I care a lot whether there are more built-in 'specialized'
simplifier. But I prefer correct answers like "I can't simplify *that*, but
if you force me to make a guess I'd say -3" over uncommented guesses
"The result *is* -3".
If a CAS comes up (sometimes after days) with
a result that is correct in (6/9)^(n*1000) * 100% of all cases
it is of no earthly use - for me.
Just my 2 pence.
Andre'
PS: No, this post says nothing in favour of Maple or any other CAS.
Andre Poenitz
Daniel Lichtblau (da...@wolfram.com) wrote:
: ...
: Your remarks pretty well demonstrate my point. You do not like the
: convention we use (or so I infer), and that IS a matter of taste
: I reiterate: Mathematica made no such assumptions. We have a case where
So what? I have to admit that English is not my first language but I am
inclined to think that 'convention' and 'assumption' could mean the same
thing in this context. In your first statement you admit 'using a
convention', in the second you deny 'making assumptions'?
You leave me puzzled.
: How do you express it if your convention is
: to take (-1)^(1/7) to be -1? And what would you make of (1-3*I)^(1/3)?
: Or of radical solutions for x^3 - 4*x - 2?
One could include a real approximation for the symbolic value.
Yes, I know, this won't help in all cases.
: ...
: Asking for more information is one way around this difficulty. I do not
: believe any system noted in this thread does so for the example posted.
"no solution until 100% correct" *is* a way to handle such problems.
Yes, I know, this tends to be unsatisfactory.
Two more pence.
Andre'
PS:
: ..
: If you really want to take Wolfram Research to task for not handling the
: above Simplify problem by asking questions, then you need to include the
: vendors of every other program cited in this thread, because none handle
: it in the manner you desire.
We don't want to call each other names, do we?
If it makes WRI people sleep easier try my newest favourite Maple feature
readlib(maximize)(x1^2+x2^2+...+x3^2, {x1,x2...xn}, {x1=0..1, x2=0..1,
...})
for n=1,2,3.
Hang on.
It's not documented on page 733.
SCNR.
Daniel Lichtblau
Andre Poenitz wrote:
>
> Daniel Lichtblau (da...@wolfram.com) wrote:
> : ...
> : Your remarks pretty well demonstrate my point. You do not like the
> : convention we use (or so I infer), and that IS a matter of taste
> : ...
> : I reiterate: Mathematica made no such assumptions. We have a case where
>
> So what? I have to admit that English is not my first language but I am
> inclined to think that 'convention' and 'assumption' could mean the same
> thing in this context. In your first statement you admit 'using a
> convention', in the second you deny 'making assumptions'?
>
> You leave me puzzled.
Yes, let me define what I mean. By "convention" I have in mind "common
usage." This is not to say it is the only possible usage, just that it
is common in symbolic math and also documented in our reference.
By "assumptions" I have in mind behavior more like that of the
Mathematica function ComplexExpand, which silently (though in accord
with documentation) "assumes" all arguments not otherwise specified are
to be regarded as real-valued. Assumptions might, for example, restrict
where parameters live (are they real-valued? positive? integer?). They
do not involve explicitly numeric objects. In other words, we are not
"assuming" the user means the principle seventh root of -1 when we
encounter (-1)^(1/7), but rather enforcing the convention that that is
what it means in the Mathematica semantics. Hence if the user has in
mind some other roots, or a set of such, then it must be specified in
some other way.
> : How do you express it if your convention is
> : to take (-1)^(1/7) to be -1? And what would you make of (1-3*I)^(1/3)?
> : Or of radical solutions for x^3 - 4*x - 2?
>
> One could include a real approximation for the symbolic value.
> Yes, I know, this won't help in all cases.
Actually that is how we handle numeric Root objects in Mathematica. For
many purposes these are more useful than radicals. But the fact remains
that radicals should have concise syntax and unambiguous meaning, and
there is no need to add numeric approximations to enforce this.
> : ...
> : Asking for more information is one way around this difficulty. I do not
> : believe any system noted in this thread does so for the example posted.
>
> "no solution until 100% correct" *is* a way to handle such problems.
> Yes, I know, this tends to be unsatisfactory.
>
> Two more pence.
> Andre'
>
> PS:
> : ..
> : If you really want to take Wolfram Research to task for not handling the
> : above Simplify problem by asking questions, then you need to include the
> : vendors of every other program cited in this thread, because none handle
> : it in the manner you desire.
>
> We don't want to call each other names, do we?
Definitely not. I would, however, like to see an even-handed indictment
of the entire industry if, as I maintain, all relevant programs are
exhibiting some flavor of the behavior that has been called into
question.
> If it makes WRI people sleep easier try my newest favourite Maple feature
>
> readlib(maximize)(x1^2+x2^2+...+x3^2, {x1,x2...xn}, {x1=0..1, x2=0..1,
> ...})
>
> for n=1,2,3.
>
> Hang on.
I am guessing this is similar to some functionality in our development
version. Below may be the analog of your code.
In[10]:= PolynomialMin[-(x1^2+x2^2+x3^2),
{0<=x1<=1, 0<=x2<=1, 0<=x3<=1}, {x1,x2,x3}]
Out[10]= {-3, {x3 -> 1, x2 -> 1, x1 -> 1}}
Not sure what the Maple behavior might be, but anyway I prefer a dark
beer before bed.
>
> It's not documented on page 733.
>
> SCNR.
>
> --
> Andre' Poenitz, TU Chemnitz-Zwickau, Fakultaet fuer Mathematik
> poe...@mathematik.tu-chemnitz.de .......... +49 3727 58 1381
Daniel Lichtblau
Wolfram Research
Richard J. Fateman
A simple problematical radical example in Mathematica.
Does a function have a zero in the left half plane? Here's a test..
NonPositive[Re [ (z/.Solve[f[z]==0,z]) ] ]
e.g.
NonPositive[Re [ (z/.Solve[z^2-1==0,z]) ] ]
returns
{True, False}
but
NonPositive[Re [ (z/.Solve[z^a-1==0,z]) ] ] /. a->2
returns
{False}
We could jigger this a bit so that we get only the first
element in the list, in which case we get True and False
respectively.