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.

    |\^/|     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;

> (3 &^ 0) mod 2;

> (2 &^ 0) mod 2;
Error, 0^0 is undefined
> (3 &^ 0) mod 3;
Error, 0^0 is undefined


Paul C. Anagnostopoulos said...

I give up, what does the &^ operator do? Isn't that a so-called "neutral operator"?

~~ Paul

Jeffrey Shallit said...

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.

Takis Konstantopoulos said...

Here is another bug:
> log(3);
Error, (in iroot) powering may produce overflow
> ln(3);
Error, (in iroot) powering may produce overflow

> log(3.0);

Jeffrey Shallit said...

I don't get those errors. What version of Maple are you using?

hpgross said...

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.

Takis Konstantopoulos said...

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.

Jeffrey Shallit said...

Weird, I am using the same version but mine does not exhibit that behavior. You should report it to

Douglas S said...

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;

Jeffrey Shallit said...

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).

Phil said...

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?

Jeffrey Shallit said...

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.

leftygomez said...

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.

Jeffrey Shallit said...

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.

Jeffrey Shallit said...

Look, even google is smarter than Wolfram alpha.

displayname said...

Wikipedia has some history / comparison at:

(version as of today: )

Anonymous said...

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).

Takis Konstantopoulos said...

Thanks a lot for suggesting to contact
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.