Time Nick Message 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 + ? 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: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