macOS Working with Very Large Numbers in Objc

[CaptainZap]

Is there a way of storing very large integers such as 317584931803? Or will I have to find a work around for it?

 

[Eraserhead]

I believe using the long type, or NSNumber numberWithLong: should do it...

 

[FredAkbar]

Unless Obj-C is different, I think long int is the same as int: 4 bytes. It's from the days when an int was by default 2 bytes, so a long int was twice as much. 4 bytes will only get you +/- 2,147,483,648.

For whatever reason, I had trouble finding much specific info on it, but you can try long long int if there is such a thing (I think I saw it somewhere), or else just use double or long double, 8 and 12 bytes respectively: plenty for what you need.

 

[slooksterPSV]

I believe using the long type, or NSNumber numberWithLong: should do it...

True, I wonder if: unsigned long long would hold it, cause unsigned long long is a way of doing 64-bit

EDIT: yes it does work

 

[kainjow]

Check out this page for more suggestions.

 

[GothicChess.Com]

Is there a way of storing very large integers such as 317584931803? Or will I have to find a work around for it?

Just make sure your compiler is set to at least ISO C90 or later and you will have no problems accessing the long long data type. I recently had the same issue with an older version of XCode that was only allowing 32-bit calculations.

 

[GeeYouEye]

To make your code more portable across different bitted architectures, use the uint64_t type instead (assuming you don't need negative numbers).

 

[ChrisA]

Is there a way of storing very large integers such as 317584931803? Or will I have to find a work around for it?

What do you need to do with such large numbers?

The problem with using 64 bit ints is if you have to multiply a few of
them together. They will overflow. What you want in this case is decimal numbers where each digit takes one byte. The old IBM 360 had decimal math in hardware.

But today, there are libraries that will handle arbitrarily long numbers up to many thousands of digits. One example is the one inside "bc" In the example below I divide two very large numbers and show the result with 100 digits of precision. I've tried using 1,000,000 digits and that works too. took about 1/2 second to compute on my system.

bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
scale=100
58472623758697896785747375868979708908968574364758569790848567463764 / 3374858697857463647657897867463647586890896746353758798

17325947245085.95533113891021018132316244477988782887003468551702952\
40688227458861161364260222872968621624114609019

As a last resort you could always pas the numbers off to "bc". it can do math with numbers up to any size so long as they fit in memory. I'm pretty sure bc ships with mac OSX but you are best off using bs's internal library to do the work

 

[GothicChess.Com]

What do you need to do with such large numbers?

The problem with using 64 bit ints is if you have to multiply a few of
them together. They will overflow. What you want in this case is decimal numbers where each digit takes one byte.

In most cases you just need large counters, not large multipliers.

Also, in my extremely rare case, I need to do a shift operation with 64 bits at the register level. Computer chess programs have one binary digit per square on the board per piece type. So, a binary number such as 0000000011111111000000000000000000000000000000000000000000000000 would be the location of all of the white pawns. If this was stored in a 64-bit int named white_pawns, then all I would need to do is white_pawns >> 8 & empty_squares and with one VERY FAST shift and one VERY FAST bit-and, I have executed 8 quasi-legal pawn moves simultaneously.

This applies to maybe 0.00001% of all of the readers, but it does represent one reason why some geeks need 64-bit numbers

 

[CaptainZap]

I got it to work! Thanks for the help guys!