Curious concept of self adapting values

[DarkLightHitomi]

I'm a totally not knowledgeable person,
But I had an interesting idea to make a number class that adjusts the type and size of a number depending on the need, so if a number was whole it would store that number as an int, then if that number had 0.5 added to it, it would auto change to a float, but it would happen behind the scenes, so the one using the number would not need to account for the datatype. Perhaps even include larger number types for those really big numbers like location in Homeworld 2 (on those maps 16 million kilometers wide) or minecraft on the edgelands or whatever they are called.

Is this done anywhere? Any suggestions on how this could be done? (figure pointers would feature prominently)

[helios]

Yes, it's called arbitrary precision arithmetic. GMP is a commonly used implementation.
Changing the internal type is complex and doesn't really solve much. What's actually done is, numbers are stored as arrays of machine words. So, for example, [0, 0, 3, 0, 5] would be used to represent the number 5*4294967296^4 + 3*4294967296^2. Following the example,
[0, 0, 3, 0, 5] + [1] = [1, 0, 3, 0, 5]
[0, 0, 3, 0, 5] * [0, 1] = [0, 0, 0, 3, 0, 5]
[0, 0, 3, 0, 5] / [2] = [0, 2147483648, 1, 2147483648, 2]

There are various representations used to store and operate on different types of numbers.

Games are very unlikely to use arbitrary precision arithmetic because it's slow. I don't know about Homeworld 2, but I do know that Minecraft uses normal fixed-length integers for its coordinate system. Probably 32-bit integers, but I can't be bothered to check.

[DarkLightHitomi]

I don't know about homeworld either, only that I could define and use maps of very large sizes, but after about 2000 kilometers the units get jittery. I stopped trying to make larger maps after 16 million kilometers cause the jitteryness was practically unplayable.

Not quite what I was thinking of doing, but thanks for the answer.

For those interested,
I was expecting to have an address and a char to know what type is currently used, then when the number is created, a new value is made using "new" and the appropriate type, and the address of that number saved along with the type, when changed to new type, the new number type is created using "new," to which the value is then copied and cast to the new type at the new location, the new address saved, and the old address location deleted.

[MiiNiPaa]

I don't know about homeworld either, only that I could define and use maps of very large sizes, but after about 2000 kilometers the units get jittery. I stopped trying to make larger maps after 16 million kilometers cause the jitteryness was practically unplayable.

Usually a tree-like structure of coarse-precision global coordinate system ("world map") and many local coordinate systems for each area. Alternatively a fixed-point numbers are used (Starcraft 1/2, Warcraft 3) or combination of integer coordinate and floating/fixed point offset (similar to global/local approach)

I do know that Minecraft uses normal fixed-length integers for its coordinate system. Probably 32-bit integers, but I can't be bothered to check.

It uses 32bit integers for blocks and floating point for entities. Previously a simple floats were used which had lead to strang behavior when you went far enough from center of the map (when FP rounding errors are large enough to be seen)

[helios]

I assume the float entity coordinates are relative to the chunk that contains the entity, correct?

[MiiNiPaa]

I assume the float entity coordinates are relative to the chunk that contains the entity, correct?

Nope, they were golobal last time I checked code (which was several years ago). That was what caused that strange behavior: loss of precision on large values of coords. Later it was fixed. I suppose it was done by switching to chunk-local offsets, but I would not be surprised if they just switched to doubles.