|\^/| Maple 15 (X86 64 LINUX)
._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2011
\ MAPLE / All rights reserved. Maple is a trademark of
<____ ____> Waterloo Maple Inc.
| Type ? for help.
> (2 &^ 0) mod 3;
1
> (3 &^ 0) mod 2;
1
> (2 &^ 0) mod 2;
Error, 0^0 is undefined
> (3 &^ 0) mod 3;
Error, 0^0 is undefined
Friday, January 25, 2013
Weird Maple Bug
I've found a few Maple bugs over the years, but this is one of the weirdest. The same weirdness occurs in very old versions, too.
Subscribe to:
Post Comments (Atom)
17 comments:
I give up, what does the &^ operator do? Isn't that a so-called "neutral operator"?
~~ Paul
It suppresses evaluation, so that
(a &^ b) mod c
evaluates a^b (mod c), but does so by the more efficient method where reduction is done at each step to keep the sizes of the numbers small.
Here is another bug:
> log(3);
Error, (in iroot) powering may produce overflow
> ln(3);
Error, (in iroot) powering may produce overflow
But
> log(3.0);
1.098612289
I don't get those errors. What version of Maple are you using?
Yeah, the error is because it reduces the base mos whatever first, so 2^0 mod 3 becomes 1^0 which is still 1, but 2^0 mod 2 becomes 0^0. Problem is I guess they don't error check for 0 powers before reducing the base.
I'm using Maple 15.00 (the only version we have in my department).
These problems can, sometimes, be annoying, e.g., when I have to define a function which involves logarithm using something like
log(1.0*x) instead of log(x), or when I do want to treat integers as integers.
Weird, I am using the same version but mine does not exhibit that behavior. You should report it to
support@maplesoft.com
If &^ does reduction at each step to keep the sizes of the numbers small, then doesn't the output make perfect sense?
(2 &^ 0) mod 2;
First reduce the base mod 2: 2 mod 2 is 0. Then 0^0 is undefined.
Similarly for
(3 &^ 0) mod 3;
0^0 is not "undefined"; it's 1. Anybody who claims otherwise is just being silly.
If you fail to define 0^0 as 1, then you cannot evaluate a polynomial at 0, since a polynomial is defined as sum(a[i]*x^i, i=0..n).
I was taught, @ UW, that 0^0 is undefined because if you attempt to evaluate the limit n->0 of 0^n and limit n->0 of n^0 you get two different answers.
Also, I thought polynomials were defined with the stipulation that 'i' is greater than 0.
Where am I going wrong in my thinking?
x^0 is defined to be 1 for all x. The fact that it may not behave well with respect to limits has nothing to do with the definition.
A polynomial is defined to be an object of the form sum(a[i]*x^i, i=0..n), and there is never any restriction on i.
Mathematica also returns an error when evaluating 0 ^ 0. You might argue that returning 1 would be more convenient, but that is not the standard practice.
Actually, it is the standard. Every programming language I am familiar with, including Maple (!), returns 1 for 0^0.
If Mathematica truly returns an error (which I find hard to believe), it is just being silly.
Look, even google is smarter than Wolfram alpha.
Wikipedia has some history / comparison at:
http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_power_of_zero
(version as of today: http://en.wikipedia.org/w/index.php?title=Exponentiation&oldid=533992037#Zero_to_the_power_of_zero )
Believe. Mma returns "indeterminate expression." Pari gives "1."Having worked without any CAS prior to '91 customize what you have. Like any chess program, if you play well enough you will note all the weaknesses.
Re: Maple, Riel's & Israel's info should help - if it still exists. Vermaseren's FORM is good (I like it anyways).
ANON2
Jeff,
Thanks a lot for suggesting to contact support@maplesoft.com
They replied immediately that certain libraries on the Linux OS could be incompatible with Maple and supplied some patches that fixed the problem.
So, thanks a lot.
Post a Comment