• Post Reply Bookmark Topic Watch Topic
  • New Topic

dealing with large numbers  RSS feed

 
Adam Chalkley
Ranch Hand
Posts: 518
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys this is an interesting I guess,so I know computer can only address and store the amount of data they have enough memory for I have a 32 bit system so my question is how come when I call my function putting a number in and getting a result bigger then my computer can handle how come the number resets to 0?

for example



when I put 10 in the result is 3628800

but when I put 80 in my function or anything above the result is 0,why does this happen and how do we solve problems like this?
 
Carey Brown
Saloon Keeper
Posts: 3329
46
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try putting in a print statement like this...

You'll see that 20 is the max you can put in before you start getting negative values due to overflow.

Even though your system is 32 bits, you are using longs which are 64 bits regardless off your system architecture.
 
Carey Brown
Saloon Keeper
Posts: 3329
46
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just for grins, here's one that uses BigInteger instead of long. The result for 80 is
71569457046263802294811533723186532165584657342365752577109445058227039255480148842668944867280814080000000000000000000

 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys, here is the output for the following code:




n = 2 ret = 2
n = 3 ret = 6
n = 4 ret = 24
n = 5 ret = 120
n = 6 ret = 720
n = 7 ret = 5040
n = 8 ret = 40320
n = 9 ret = 362880
n = 10 ret = 3628800
n = 11 ret = 39916800
n = 12 ret = 479001600
n = 13 ret = 6227020800
n = 14 ret = 87178291200
n = 15 ret = 1307674368000
n = 16 ret = 20922789888000
n = 17 ret = 355687428096000
n = 18 ret = 6402373705728000
n = 19 ret = 121645100408832000
n = 20 ret = 2432902008176640000
n = 21 ret = -4249290049419214848
n = 22 ret = -1250660718674968576
n = 23 ret = 8128291617894825984
n = 24 ret = -7835185981329244160
n = 25 ret = 7034535277573963776
n = 26 ret = -1569523520172457984
n = 27 ret = -5483646897237262336
n = 28 ret = -5968160532966932480
n = 29 ret = -7055958792655077376
n = 30 ret = -8764578968847253504
n = 31 ret = 4999213071378415616
n = 32 ret = -6045878379276664832
n = 33 ret = 3400198294675128320
n = 34 ret = 4926277576697053184
n = 35 ret = 6399018521010896896
n = 36 ret = 9003737871877668864
n = 37 ret = 1096907932701818880
n = 38 ret = 4789013295250014208
n = 39 ret = 2304077777655037952
n = 40 ret = -70609262346240000
n = 41 ret = -2894979756195840000
n = 42 ret = 7538058755741581312
n = 43 ret = -7904866829883932672
n = 44 ret = 2673996885588443136
n = 45 ret = -8797348664486920192
n = 46 ret = 1150331055211806720
n = 47 ret = -1274672626173739008
n = 48 ret = -5844053835210817536
n = 49 ret = 8789267254022766592
n = 50 ret = -3258495067890909184
n = 51 ret = -162551799050403840
n = 52 ret = -8452693550620999680
n = 53 ret = -5270900413883744256
n = 54 ret = -7927461244078915584
n = 55 ret = 6711489344688881664
n = 56 ret = 6908521828386340864
n = 57 ret = 6404118670120845312
n = 58 ret = 2504001392817995776
n = 59 ret = 162129586585337856
n = 60 ret = -8718968878589280256
n = 61 ret = 3098476543630901248
n = 62 ret = 7638104968020361216
n = 63 ret = 1585267068834414592
n = 64 ret = -9223372036854775808
n = 65 ret = -9223372036854775808
n = 66 ret = 0
n = 67 ret = 0
n = 68 ret = 0
n = 69 ret = 0
n = 70 ret = 0
n = 71 ret = 0
n = 72 ret = 0
n = 73 ret = 0
n = 74 ret = 0
n = 75 ret = 0
n = 76 ret = 0
n = 77 ret = 0
n = 78 ret = 0
n = 79 ret = 0
n = 80 ret = 0

1) Why is it that for n=64, when multiplying with 65 it gives roughly the same number ?
2) Why is it that for n=65, when multiplying with 66 it gives 0 ?! This is even weirder than 1.
 
Carey Brown
Saloon Keeper
Posts: 3329
46
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This will give you an idea as to how the overflow is affecting the return value. Note that longs are 16 hex-digits long. And, once you have a return value of zero, well, zero times anything is zero.



n=63 fact= 7638104968020361216 (0x6A00000000000000) ret= 1585267068834414592 (0x1600000000000000) bigret= 481200612985282756608 (0x1A1600000000000000)
n=64 fact= 1585267068834414592 (0x1600000000000000) ret=-9223372036854775808 (0x8000000000000000) bigret= 101457092405402533888 (0x58000000000000000)
n=65 fact=-9223372036854775808 (0x8000000000000000) ret=-9223372036854775808 (0x8000000000000000) bigret=-599519182395560427520 (0x-208000000000000000)
n=66 fact=-9223372036854775808 (0x8000000000000000) ret= 0 (0x 0) bigret=-608742554432415203328 (0x-210000000000000000) // lower 16 nibbles all zero
n=67 fact= 0 (0x 0) ret= 0 (0x 0) bigret= 0 (0x0)
n=68 fact= 0 (0x 0) ret= 0 (0x 0) bigret= 0 (0x0)
 
Lucian Whiteman
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Carey Brown wrote:This will give you an idea as to how the overflow is affecting the return value. Note that longs are 16 hex-digits long. And, once you have a return value of zero, well, zero times anything is zero.

n=65 fact=-9223372036854775808 (0x8000000000000000) ret=-9223372036854775808 (0x8000000000000000) bigret=-599519182395560427520 (0x-208000000000000000)
n=66 fact=-9223372036854775808 (0x8000000000000000) ret= 0 (0x 0) bigret=-608742554432415203328 (0x-210000000000000000) // lower 16 nibbles all zero
n=67 fact= 0 (0x 0) ret= 0 (0x 0) bigret= 0 (0x0)[/tt]


I do not get it: does JVM make the * operation on hexa numbers ? Does it not make it on binary digits numbers ?
 
fred rosenberger
lowercase baba
Bartender
Posts: 12565
49
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lucian Whiteman wrote:I do not get it: does JVM make the * operation on hexa numbers ? Does it not make it on binary digits numbers ?

They are the same thing. hex is used by humans as a shorthand for binary. It's a pain to write "10101000100101010100100101010101101010101011011101101011010001010101010101010001010010010" when instead one can write <whatever that would be in hex>/

edit: someone who has had more coffee than me says it is 544AA4AAD55BB5A2
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!