ID:134311
 
mob/verb/Check1()
var/hf = 99999999999999999999999999999999999999999
world << num2text(hf,100000)


That outputs exactly "2147483648".

mob
verb
Check2()
var N = 2
while(1)
sleep(1)
N*=2
usr<<"[num2text(N,100000)]"


That manages to approach infinity (and much higher numbers than 2147483648 before reaching infinity).

Is there a reason why one's able to go much higher than the other?
DeathAwaitsU wrote:
> mob/verb/Check1()
> var/hf = 99999999999999999999999999999999999999999
> world << num2text(hf,100000)
>

That outputs exactly "2147483648".

> mob
> verb
> Check2()
> var N = 2
> while(1)
> sleep(1)
> N*=2
> usr<<"[num2text(N,100000)]"
>

That manages to approach infinity (and much higher numbers than 2147483648 before reaching infinity).

Is there a reason why one's able to go much higher than the other?

It seems that different operations yield different limits. For example, numbers can't increment as highly as they can be multiplied:
mob
verb
Check2()
set background = 1
var N = 2
while(1)
var/temp = N
N*=2
if(N == temp)
src << "Non-changing value!"
break

else if(N > 4294967296)
src << "Multiplication extends upwards of 4294967296 + \
[num2text(N-4294967296,100000)]"
break
sleep(0)
N = 0
while(1)
var/temp = N
if(++N == temp)
src << "Addition stops at: [num2text(N, 100000)]"
break

Outputs:
Multiplication extends upwards of 4294967296 + 2147483648
Addition stops at: 16777216


Hiead
In response to Hiead
Keep sleep in the 2nd one...
In response to Revojake
Revojake wrote:
Keep sleep in the 2nd one...

I'd rather not. For the multiplication, it doesn't take long to finish the loop. For the addition, I'd rather not sleep for 1677721.6 seconds(calling sleep(1) 16777216 times). It only takes a moment of processor-intensive looping, and then the result is clearly shown.

Hiead
DeathAwaitsU wrote:
Is there a reason why one's able to go much higher than the other?

This is just how large numbers work on computers. There is only so much data you can store within a given number of bits, so when it goes too large it drops information. After 2,147,483,648; a difference of one is no longer significant enough of a change to record. It's like recording an extra grain of sand on the beach. If you double the size of the beach however, that's a notable change.

This is the same reason that world.realtime is only accurate to within about 6 seconds, so we had to add world.timeofday to get tick accurate time. An individual tick isn't big enough to make a difference to a value as large as realtime.

In response to Shadowdarke
Shadowdarke wrote:
This is the same reason that world.realtime is only accurate to within about 6 seconds, so we had to add world.timeofday to get tick accurate time. An individual tick isn't big enough to make a difference to a value as large as realtime.

Actually, it's now accurate to only every 26 seconds (really 25.6, or 256/10). At 17:38:50 BST on August 10, 2013, we'll lose another bit and drop to 51.2-second accuracy. BYOND 4.0 will be just around the corner then.
In response to Mike H
Mike H wrote:
BYOND 4.0 will be just around the corner then.

Hey, let's not get ahead of ourselves.
In response to Tom
Tom wrote:
Mike H wrote:
BYOND 4.0 will be just around the corner then.

Hey, let's not get ahead of ourselves.

So I take it that this, plus the rumours mentioned in [link] (and earlier than that - that was just the earliest reference I could find), means that BYOND development is actually going backwards; from "just around the corner" in 2003 to "not yet just around the corner" in 2013.

;-P
In response to Shadowdarke
Shadowdarke wrote:
This is the same reason that world.realtime is only accurate to within about 6 seconds, so we had to add world.timeofday to get tick accurate time. An individual tick isn't big enough to make a difference to a value as large as realtime.

world.timeofday is accurate to 10 ticks, not 1 tick. =)