This system will let you store numbers much larger than an int with the same amount of space (excluding the size of the class itself). class BigNum { private: unsigned char Value[4]; public: double GetValue(); void SetValue(double NewValue); }; double BigNum::GetValue() { return Value[0] + (256 * Value[1]) + (256 * 256 * Value[2]) + 256 * 256 * 256 * Value[3]; } void BigNum::SetValue(double NewValue) { for (int i = 0; i < 4; i++) { Value = NewValue % 256; NewValue = (NewValue - (NewValue % 256)) / 256 } } This code is untested, but I think it will work (maybe a slight bug in the SetValue() function). The only problem is that there is a lot more processor work involved with this than in an int. If you make the size of the array Value big enough, and change the rest of the functions to match, it may be possible to make it store large enough numbers to overcome the amount of memory used by the class. I don''t know if this is a new idea or not... just thought I would post it. --------------------

You are not a real programmer until you end all your sentences with semicolons;

Yanroy@usa.com

Visit the ROAD Programming Website

Is this a joke?

That stores no more than an 32 bit int and forces the processor to treat an intrinsic 32 bit type as 4 bytes when the processor can use 32 bit instructions instead.

Maybe I''m misunderstanding something, but I don''t see how this will store numbers larger than an int. In fact, I think all this does is stores the equivalent of an int, but has to do a bunch of math to arrive at the same answer.

aig

this would work, but yanroy mentioned changing the size of the value array. true, the above code could be replaced by a long, but i guess if you wanted a 6-byte number, this would work. although, i would just use a double anyway.



crazy166
some people think i'm crazy, some people know it

This does not save memory, it''s the same as a long, but it would be useful for very large numbers (if you enlarge the array).

Visit our homepage: www.rarebyte.de.st

GA

Judging by the replies, I must have done my math wrong. Here it is:

Max for int: 4294967296 (I think, 2^32)
Max for my thing: 4295048713 (256 + 256^2 + 256^3 + 256^4)

Check that, but I think I did it right.

--------------------


You are not a real programmer until you end all your sentences with semicolons;

Yanroy@usa.com

Visit the ROAD Programming Website

The largest value a byte can hold is 255, not 256. That's where the math is wrong.

You wrote:
(256 + 256^2 + 256^3 + 256^4)

This should be:
(255 + (255*256) + (255*(256^2)) + (255*(256^3)))

aig

Edited by - An Irritable Gent on 4/24/00 11:59:25 AM

Here''s the catch:
yanroy''s calculations "reuse" low - order bits.

To beat a dead horse.

The maximum value of a four byte unsigned integer is (2^32 - 1) not 2^32. The number of values that a four byte unsigned integer can represent is 2^32.

Irritable Gent''s correct answer, (255 + (255*256) + (255*(256^2)) + (255*(256^3))), equals (2^32 - 1) so it is the maximum value not the number of values.

Oh, well. Think of all things we could do with a .00189% increase in the maximum value of a 4 byte integer.

Now maybe if you used kiren_j''s compression algorithm ...

Mike Roberts
aka milo
mlbobs@telocity.com

Actually, Milo, I heard kiren_j''s compression algorithm is based on this system...