 |
|
List Archives > 
Maple User Group List Archive > 
Archive by date > 
This Month By Date > 
This Month By Topic
[MUG] Re: Bug?
| [MUG] Re: Bug? |
|
Author: Maple Group
Posted: 19/01/2001 21:15:31 GMT
|
Subject: Bug?
Date: Fri, 19 Jan 2001 10:32:01 +1300
Looks like 32 bit signed (2's complement) arithmetic:
2147483648 = 0x80000000 (unsigned hexadecimal)
i.e. only the most significant bit set which how the signed number
-2147483648 (the greatest -ve number possible in 32 bits) is stored.
21474836480 = 2147483648 *10
or 0x80000000 * 0xA = 0x500000000
but only least significant 32 bits kept, hence this becomes
0x00000000 == 0
214748364810 = ((21474836480 ==0 as per above) +1) *10 = 10
i.e. its 32 bit integer arithmetic overflow.
-----------------------------------------------------------------
Andrew Heald (Electronics Engineer)
Industrial Research Ltd Email
Communications Voice +64-4-569-0114
PO Box 31310 or +64-4-569-0444 ext 4114
Lower Hutt or +64-4-569-0000 ext 4114
New Zealand Fax +64-4-569-0754
-----------------------------------------------------------------
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Date: Thu, 18 Jan 2001 14:41:53 -0800 (PST)
From: Robert Israel
To:
Subject: Bug?
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.
Robert Israel
Department of Mathematics http://www.math.ubc.ca/~israel
University of British Columbia
Vancouver, BC, Canada V6T 1Z2
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
From: Luis Goddyn
Date: Thu, 18 Jan 2001 19:51:02 -0800 (PST)
To:
Subject: Bug?
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
Luis Goddyn
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Date: Fri, 19 Jan 2001 10:10:23 +0100
From: Heike Koch-Beuttenmueller
To:
Subject: Bug?
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?
With best regards
Heike Koch-Beuttenmuller
|
[View Complete Thread]
Previous by date: [MUG] Re: Geodesics, Maple Group
Next by date: [MUG] Re: Listing all variables, Herman Jaramillo
Previous thread: [MUG] Compound matrix of order p, Juan Manuel De Olazabal
Next thread: [MUG] Listing all variables, Francois DEBROUCKE
|
|
|