What’s going on in Maple 6?

> restart; > 1/21474836480; Error, division by zero > 21474836480; 0 > 214748364810; 10 > 2147483648; -2147483648 > kernelopts(version); Maple 6, IBM INTEL NT, Jan 31 2000 Build ID 16401

It is corrected with Maple 7. (U. Klein)

That’s a strange bug! Apparently it exists in the code that recognizes numbers in input. You also have e.g.

> 21474836481.234; 1.234

It seems only to aﬀect numbers that start `214748364x`

where x is 8 or 9. The fact
that `2147483648 = 2^31`

is a clue: perhaps there’s some `32-bit`

ﬁeld overﬂowing
here.

This bug was not present in Release 5.1.

Yes indeed, something is very wrong, even in 6.01. I clearly has to do with the sign bits of the new internal representation of integers (a hybrid between base 2 and base 10). Question: When can integer calculations be trusted in version 6?

> 2^31; 2147483648 > 2147483648; -2147483648 > 21474836480413647819643794; 413647819643790)+'--.(--.( > %+1; 413647819643790)+'--.(--.) > kernelopts(version); Maple 6.01, SUN SPARC SOLARIS, June 9 2000 Build ID 79514

This is a terrible bug in Maple 6.0. It did not exist in MapleV R5.1 You can ﬁnd it on other platforms as well. I tried it on Sun and on Dec alpha:

Sun 32- bit machine:

> restart:

Here it works correct!!!

> a1:=2^31; a1 := 2147483648 > a3:=1/a1; a3 := 1/2147483648

Here all is wrong and the result depends upon assigning the starting value to a variable or calculating directly!!!!!!!!!

> b1:=2147483648; b1 := -2147483648 > c2:=21474836480; c2 := 0 > kernelopts(version); Maple 6.01, SUN SPARC SOLARIS, June 9 2000 Build ID 79514

On DEC this part works , but because it is a 64-bit version you ﬁnd the same behaviour near
`2^64!!!!!!!!!!!`

> restart:

Here it works correct!!!

> a1:=2^63; a1 := 9223372036854775808 > a3:=1/a1; a3 := 1/9223372036854775808

Here all is wrong and the result depends upon assigning the starting value to a variable or calculating directly!!!!!!!!!

> b1:=9223372036854775808; b1 := -9223372036854775808 > c2:=92233720368547758080; c2 := 0 > b3:=1/b1; -1 b3 := ------------------- 9223372036854775808 > kernelopts(version); Maple 6.01, DEC ALPHA UNIX, Jun 9 2000 Build ID 79514

I hope its only a question of the wrong conversion of written integers near `2^31 or 2^63`

to
internal form and not a problem of wrong calculations?

I dont know, but I have more "evident" (and inﬁnite?) bugs:

> s:=[seq(2^(31+i)*5^i,i=0..300)]: > map(x->parse(convert(x,string)),s); [-2147483648, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] > kernelopts(version); Maple 6.01, APPLE_PPC_MAC, Sun, Jun 11, 2000 Build ID 79514

But I worry, what about the not evident bugs?

Much as I agree with the feelings expressed, I was under the impression that the bug only occurred on *input* of such integers, i.e. something I type in, not something that appears in mid calculation. I am concerned with what is being said here.

I though that `2147483646+2`

would not cause a fault but `2147483648`

will cause an error
(sign incorrect in this case).

It needs correcting but can someone conﬁrm or otherwise that it is an input only problem, ie not a calculation result error too?

I would like to take this opportunity to address the concerns raised about the integer parsing bug. I am including more details from our developers on exactly when this bug does and does not occur, and why. This way, each user may judge for himself whether or not this issue will aﬀect his work. A workaround is provided so that the problem situation can be avoided entirely.

Because of the exact nature of this bug, the number of users who will run into this problem is very small. However, we still recognize that it is a serious problem that must be corrected. As Sultan Saini stated in a previous posting, this problem has already been corrected in our development version. We are currently determining the best method for getting this correction to our users.

When the Bug Occurs

This bug occurs when Maple is parsing integers whose ﬁrst 10 digits are either
`(+/-)2147483648 or (+/-)2147483649`

(on 32-bit machines) or when the ﬁrst 19 digits are
either `(+/-)9223372036854775808 or (+/-)9223372036854775809`

(on 64-bit machines).
Only integers with those exact preﬁxes are aﬀected.

> 2147483648; > -2147483648; > 21474836480; > 21474836498;

It will occur when the number is explicitly typed into the session, cut and paste into the session, or read in from a ﬁle.

When the Bug Does Not Occur

This problem is caused by a bug in the parser. It will not occur when the number is generated as a result of a calculation.

> 2147483647 + 1; 2147483648 > % + 1000000000; 3147483648

It does not occur in any types of numbers other than integers.

> 2147483648.0;

It does not occur for any integers other than those starting with the two 10-digit preﬁxes above.

Workaround

Since calculated results are not aﬀected, this problem can be avoided by replacing any number starting with one of the two 10-digit problem strings by an equivalent expression that does not use the preﬁx. For example, if your worksheet contains the input line

> f(21474836489);

replace it with

> f(214748364 * 10^2 + 89);

What Caused the Bug

When Maple reads an integer inputted by a user it reads one digit at a time, building up the
result. For small integers this scan can be done using the standard hardware ``long'`

format.
For large integers Maple’s internal INTPOS or INTNEG data structure must be
used. Both scans start by using the hardware format and switch to Maple’s format
only when needed. The bug was in the check for when to switch scan models.
It was checking if the current `integer * 10`

would still ﬁt in a long and then
proceeding to continue with a hardware scan if so. It should have been checking if
the current `integer * 10 + next digit`

would ﬁt. Thus integers of the form
`2^(WORDSIZE-1)... and 2^(WORDSIZE-1)+1...`

written out explicitly were subject to
error.

This bug was introduced in Maple 6 due to a signiﬁcant change in the way Maple stores small vs. large integers. Unfortunately, despite thousands of regression tests and millions of lines of library code this bug was not noticed before shipping the product.

Please be assured that we are taking this issue seriously, and we will inform you once decisions regarding the availability of the correction are made.