Hi mates,

I'm having some issues with an unexpected (for me) behaviour of rnd() and tostr() functions.

Why this fragment of code prints value 1 if it's supposed that calling rnd() with no arguments produces values from 0 to 0.99999? Does tostr() perform some kind of ceil()?

local rnd_number = rnd()
printh("rnd_number:"..tostr(rnd_number),"maplog.txt")

Output:

rnd_number:0.3293
rnd_number:0.7758
rnd_number:0.5745
rnd_number:0.3691
rnd_number:1
rnd_number:0.0995
rnd_number:0.1682

I need to avoid that '1' value.

Seems like it's more precision related than ceil() related. If you do this:

print("0.99985: "..tostr(0.99985))
print("0.99986: "..tostr(0.99986))
print("0.99987: "..tostr(0.99987))
print("0.99988: "..tostr(0.99988))
print("0.99989: "..tostr(0.99989))
print("0.99990: "..tostr(0.99990))
print("0.99991: "..tostr(0.99991))

you get this output:

0.99985: 0.9998
0.99986: 0.9998
0.99987: 0.9999
0.99988: 0.9999
0.99989: 0.9999
0.99990: 0.9999
0.99991: 1

If it was ceil() I'd expect it to flip at 0.99985 and definitely not flip to 1 at 0.99991. (Disclaimer: I am a relative PICO-8 n00b, so take what I say with a big grain of salt - this is just my observation/guess).

Yes, but the question is: why?

Why is it not possible to print those numbers correctly? I want to write a log file with the insights of my random map generator, but I can't rely on it because of this issue...

Could someone clarify it?

I think it cuts off at four decimal places because internally numbers are 16b.16b fixed point, so it doesn't have a full fifth decimal place - adjacent numbers differ by approximately 0.00001526.

For debug purposes, the best option is probably to use TOSTR(VAL,TRUE) to get the hexadecimal encoding of the number, which is exact.

If you need decimal, this probably has bugs because we aren't at a PICO-8 to test it, but something like

function tostr_exact(val)
   local str = tostr(flr(val)).."."
   while val>0 do
      val = (10*val)%10
      str..=tostr(flr(val))
   end
   return str
end

should get an exact decimal value.

@packbat Just as I was suspecting, what you says make sense.
Thanks for the chunk of code. I'll test it later.