Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
• Campbell Ritchie
• Bear Bibeault
• Ron McLeod
• Jeanne Boyarsky
• Paul Clapham
Sheriffs:
• Tim Cooke
• Liutauras Vilda
• Junilu Lacar
Saloon Keepers:
• Tim Moores
• Stephan van Hulst
• Tim Holloway
• fred rosenberger
• salvin francis
Bartenders:
• Piet Souris
• Frits Walraven
• Carey Brown

# dealing with large numbers

Ranch Hand
Posts: 543
4
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?

Bartender
Posts: 7202
65
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
Bartender
Posts: 7202
65
Just for grins, here's one that uses BigInteger instead of long. The result for 80 is
71569457046263802294811533723186532165584657342365752577109445058227039255480148842668944867280814080000000000000000000

Ranch Hand
Posts: 62
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
Bartender
Posts: 7202
65
• 1
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

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 ?

lowercase baba
Posts: 12871
62

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