Question

I’ve got a strange problem here, and i’m sure it’s just something small.

I recieve information about files via JSON (RestKit is doing a good job).
I write the filesize of each file via coredata to a local store.

Afterwards within one of my viewcontrollers i need to sum up the files-sizes of all files in database. I fetch all files and then going through a slope (for) to sum the size up.

The problem is now, the result is always negative!

The coredata entity filesize is of type Integer 32 (filesize is reported in bytes by JSON).
I read the fetchresult in an NSArray allPublicationsToLoad and then try to sum up. The Objects in the NSArray of Type CDPublication have a value filesize of Type NSNumber:

for(int n = 0; n < [allPublicationsToLoad count]; n = n + 1)
{
    CDPublication* thePub = [allPublicationsToLoad objectAtIndex:n];
    allPublicationsSize = allPublicationsSize + [[thePub filesize] integerValue];
    sum = [NSNumber numberWithFloat:([sum floatValue] + [[thePub filesize] floatValue])];

Each single filesize of the single CDPublications objects are positive and correct. Only the sum of all the filesizes ist negative afterwards. There are around 240 objects right now with filesize-values between 4000 and 234.645.434.123.

Can somebody please give me a hit into the right direction !?
Is it the problem that Integer 32 or NSNumber can’t hold such a huge range?

Thanks

MadMaxApp
}

Answer 1

The NSNumber object can’t hold such a huge number. Because of the way negative numbers are stored the result is negative.

Negative numbers are stored using two’s complement, this is done to make addition of positive and negative numbers easier. The range of numbers NSNumber can hold is split in two, the highest half (the int values for which the highest order bit is equal to 1) is considered to be negative, the lowest half (where the highest order bit is equal to 0) are the normal positive numbers. Now, if you add sufficiently large numbers, the result will be in the highest half and thus be interpreted as a negative number. Here’s an illustration for the 4-bit integer situation (32 works exactly the same but there would be a lot more 0 and 1 to type;))

With 4 bits you can represent this range of signed integers:

0000 (=0)
0001 (=1)
0010 (=2)
... 
0111 (=7)

1000 (=-8)
1001 (=-7)
...
1111 (=-1)

The maximum positive integer you can represent is 7 in this case. If you would add 5 and 4 for example you would get:

0101 + 0100 = 1001

1001 equals -7 when you represent signed integers like this (and not 9, as you would expect). That’s the effect you are observing, but on a much larger scale (32 bits)

Your only option to get correct results in this case is to increase the number of bits used to represent your integers so the result won’t be in the negative number range of bit combinations. So if 32 bits is not enough (like in your case), you can use a long (64 bits).

[myNumber longLongValue];