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 affect 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 field overflowing
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 find 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 find 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 infinite?) 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 confirm 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 affect 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 first 10 digits are either
(+/-)2147483648 or (+/-)2147483649 (on 32-bit machines) or when the first 19 digits are
either (+/-)9223372036854775808 or (+/-)9223372036854775809 (on 64-bit machines).
Only integers with those exact prefixes are affected.
> 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 file.
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 prefixes above.
Workaround
Since calculated results are not affected, 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 prefix. 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 fit 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 fit. 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 significant 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.