• Post Reply Bookmark Topic Watch Topic
  • New Topic
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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

dealing with large numbers

 
Ranch Hand
Posts: 545
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Saloon Keeper
Posts: 10750
86
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows ChatGPT
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 10750
86
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows ChatGPT
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just for grins, here's one that uses BigInteger instead of long. The result for 80 is
71569457046263802294811533723186532165584657342365752577109445058227039255480148842668944867280814080000000000000000000

 
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 10750
86
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows ChatGPT
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ?
 
lowercase baba
Posts: 13089
67
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
What I don't understand is how they changed the earth's orbit to fit the metric calendar. Tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic