| Time |
Nick |
Message |
| 00:27 |
|
YuGiOhJCJ joined #luanti-dev |
| 03:12 |
|
SFENCE_arch joined #luanti-dev |
| 03:54 |
|
jjb joined #luanti-dev |
| 04:00 |
|
johnnyjoy joined #luanti-dev |
| 04:57 |
|
calculon joined #luanti-dev |
| 05:00 |
|
MTDiscord joined #luanti-dev |
| 07:03 |
|
mrcheese_ joined #luanti-dev |
| 12:28 |
|
SFENCE_arch joined #luanti-dev |
| 12:29 |
|
YuGiOhJCJ joined #luanti-dev |
| 12:38 |
|
Wuzzy joined #luanti-dev |
| 12:40 |
Wuzzy |
Is a 'double' data type in Luanti C++ code guaranteed to be 64-bit on all systems? |
| 12:41 |
Wuzzy |
(i know that 'int' is forced to be 32-bit minimum via CMake, haven't found an equivalent for double so far) |
| 12:47 |
sfan5 |
c++ does not guarantee this |
| 12:58 |
repetitivestrain |
Wuzzy: all modern 32-bit and 64-bit systems have a word size (int) that is at least 32 bits wide and all architectures luanti could feasibly support have IEEE binary floating point |
| 13:00 |
repetitivestrain |
C (i'm not certain as regards C++, but the requirements should only be more stringent over there) defines its minimum requirements for floating point precision decimally, and a double must be capable of representing any integral value with 10 digits without loss of precision |
| 13:01 |
repetitivestrain |
i.e., -9999999999 to 9999999999 |
| 13:01 |
Wuzzy |
i know but i wondered if *Luanti* has some built-in restriction like for int where it just refuses to compile if it discovers a double is not 64bit on this system |
| 13:01 |
Wuzzy |
i wonder if there is any system where a) Luanti supports it and b) a double is (for some reason) NOT 64 bit |
| 13:02 |
repetitivestrain |
those systems don't exist in PCs any longer |
| 13:02 |
repetitivestrain |
for instance, the only system GCC continues to support without IEEE floating point (but with doubles that have 52 bit mantissas, i think) is the vax, and vaxen have not been manufactured for 30 years |
| 13:03 |
repetitivestrain |
and luanti is just not capable of functioning on motorola DSPs or other embedded or legacy systems that only provide archaic floating point formats which only satisfy the minimum criteria required by the C standard |
| 13:03 |
Wuzzy |
interesting |
| 13:04 |
repetitivestrain |
Wuzzy: also, the number of bits occupied by the representation is not relevant to lua's capacity to represent integers without loss of precision, but the number of significand digits and its radix |
| 13:06 |
repetitivestrain |
you could have "64-bit" (8 byte) doubles in some bcd format that only affords you a significand with 11 decimal digits too, which wouldn't be adequate, but these machines no longer exist for most intents and purposes, and certainly not at all for video games |
| 13:07 |
repetitivestrain |
Wuzzy: you should also mention that numbers beyond the representable range should not be provided to PcgRandom, particularly not values derived by addition or subtraction from the world seed |
| 13:07 |
repetitivestrain |
it's a very widespread mistake i observe all the time in mineclonia and elsewhere |
| 13:07 |
repetitivestrain |
since seeds are unsigned 64 bit integers, they cannot be represented as lua numbers without loss of precision |
| 13:08 |
repetitivestrain |
instead it's necessary to implement your own 64 bit integer library and PRNGs |
| 13:08 |
sfan5 |
"you shouldn't try to use values you can't represent" sounds redundant |
| 13:08 |
Wuzzy |
ohh so you mean in mineclonia they put in <world seed> + <some number>? |
| 13:08 |
repetitivestrain |
yes |
| 13:08 |
repetitivestrain |
sfan5: currently the documentation states that `seed' is a "64-bit unsigned seed" |
| 13:08 |
repetitivestrain |
> * `seed`: 64-bit unsigned seed |
| 13:09 |
repetitivestrain |
which is quite liable to mislead |
| 13:09 |
sfan5 |
my point is tonumber(core.get_mapgen_setting("seed")) is already wrong |
| 13:09 |
Wuzzy |
yes |
| 13:09 |
sfan5 |
whether you add or subtract anything doesn't matter |
| 13:10 |
repetitivestrain |
sfan5: yes, exactly, but the documentation on pcgrandom very frequently misleads programmers into adopting this approach |
| 13:11 |
sfan5 |
it's not there's an alternative. but people should be aware that reading the seed into lua will truncate it. |
| 13:11 |
repetitivestrain |
since the seed is 64-bit and so is the seed argument to PcgRandom in the words of the documentation, programmers assume that it's perfectly alright to do so |
| 13:11 |
Wuzzy |
so how to fix it? should I just claim the integer range for PcgRandom is actually only the "lua-safe integer range"? |
| 13:11 |
repetitivestrain |
yes, that would be ideal |
| 13:11 |
repetitivestrain |
sfan5: well the alternative is to implement 64 bit integers |
| 13:12 |
repetitivestrain |
either by luanti as a builtin library or by modders individually |
| 13:12 |
sfan5 |
we're not inventing any lua extensions |
| 13:12 |
Wuzzy |
or by upgrading to Lua 5.4 :) |
| 13:12 |
sfan5 |
(luajit ffi has them, I know) |
| 13:12 |
repetitivestrain |
Wuzzy: there's no luajit for 5.4... |
| 13:12 |
Wuzzy |
and 5.3? |
| 13:12 |
repetitivestrain |
sfan5: yeah i wasn't suggesting that you implement any lua extensions |
| 13:12 |
repetitivestrain |
Wuzzy: luajit only implements 5.1 |
| 13:12 |
repetitivestrain |
just a library that implements 64-bit integers as tables or some such |
| 13:13 |
Wuzzy |
i could add a note that world seeds from the lua side should only be used as strings to be safe |
| 13:13 |
Wuzzy |
and that conversion to number is evil/dangerous |
| 13:13 |
repetitivestrain |
Wuzzy: that's good too, but pcgrandom shouldn't claim that `seed' is 64-bit either |
| 13:14 |
sfan5 |
you can pass a string to luaL_checknumber or luaL_checkinteger IIRC, but it will *still* be truncated |
| 13:14 |
sfan5 |
there is no way to get 64-bit numbers into pcgrandom. period. |
| 13:15 |
repetitivestrain |
sfan5: i think set_state could perhaps be abused to do so, but i've never attempted it |
| 13:15 |
repetitivestrain |
mineclonia implements its own RNGs in Lua |
| 13:15 |
repetitivestrain |
also TIL that luaL_checknumber coerces strings |
| 13:18 |
repetitivestrain |
> u64 state[2]; s_state_0 >> std::hex >> state[0]; s_state_1 >> std::hex >> state[1]; |
| 13:19 |
repetitivestrain |
yes, i think set_state should be suitable if you implement whatever routine it is by which this PRNG derives its initial state from a seed in lua |
| 13:23 |
repetitivestrain |
Another circumstance that may be material is that core.hash_node_position cannot function unless the lua number significand width is at least sufficient to represent any 48 bit binary number |
| 13:29 |
pgimeno |
FWIW love2d allows *two* Lua numbers for seeding its PRNG, to account for not having enough bits to complete the 64 bits that it needs |
| 13:31 |
pgimeno |
to account for _a Lua number_ not having* |
| 13:32 |
pgimeno |
a function that converts a string to a 64-bit integer split into two numbers, and 64-bit addition functions, would suffice to deal with these cases |
| 13:39 |
pgimeno |
64-bit addition is easy to implement in Lua; to_64bit no so much (doable but not sure how much faster a C implementation would be) |
| 14:03 |
repetitivestrain |
pgimeno: yeah, so does mineclonia |
| 14:04 |
|
johnnyjoy joined #luanti-dev |
| 14:09 |
|
johnnyjoy joined #luanti-dev |
| 14:13 |
Wuzzy |
OK, I fixed PcgRandom range in my integer PR |
| 14:23 |
johnnyjoy |
I sent a PR adding PostgreSQL support to the rollback backend — happy to adjust or revise as needed. |
| 14:50 |
Wuzzy |
I noticed something strange. the C++ comment for ModApiEnv::l_set_node_level claims the level arg can only be from 0 to 63 but I thought node level can go from 0 to 127. is this comment a mistake/outdated? |
| 14:51 |
Wuzzy |
node levels above 63 seem to be supported, given that other functions and docs generally refer to a 127 upper limit instead of 63 |
| 15:24 |
|
vampirefrog joined #luanti-dev |
| 18:50 |
|
mrcheese joined #luanti-dev |
| 19:18 |
|
SFENCE joined #luanti-dev |
| 19:28 |
|
SFENCE joined #luanti-dev |
| 19:38 |
|
johnnyjoy joined #luanti-dev |
| 20:06 |
|
SFENCE joined #luanti-dev |
| 20:18 |
|
jstein joined #luanti-dev |
| 21:09 |
|
turtleman joined #luanti-dev |
| 23:32 |
|
panwolfram joined #luanti-dev |
