Time  Nick      Message
13:56 Krock     Idea: To solve the float network issue on a very simple way (KISS) and without rebuilding the entire float to send and disassemble on receive - let's send (u32)(floatf(x) * 1000)
13:59 sfan5     how does that differ from what we have already?
14:00 Krock     currently it's (u32)(x * 1000). Large and tiny numbers get lost
14:00 Krock     thing is, assembling the float format we want may take more clock cycles than a sqrt operation
14:12 sfan5     oh
14:14 Krock     respectively the sqrtf() function since we only need single precision. The negative sign would then simply be moved outside the sqrtf() function, which makes the function entirely reversible (although with some minor rounding errors)
15:01 nerzhul   interesting idea Krock, but you will floor before multiply
15:01 Krock     sorry?
15:04 nerzhul   floatf(x) * 1000 means you floor the x and then multiply, but it's too late you loss the precision
15:05 Krock     s/floatf/sqrtf/
15:05 Krock     typos
15:05 nerzhul   oh
15:05 nerzhul   then you will have bool(sign)+u32(floatsqrtf) ?
15:06 Krock     (x < 0) ? (u32)(sqrtf(-x) * -MULT) : (u32)(sqrtf(x) * MULT)
15:07 Krock     whereas MULT can be tuned to either allow more precision or higher values
15:07 nerzhul   and you pow on the other side to retrieve, right ?
15:07 Krock     currently doing precision tests
15:07 Krock     exactly
15:08 Krock     not "pow" directly, simply x * x after dividing it by 1000
15:08 Krock     since pow takes doubles as exponent and may result in a very poor performance
15:09 nerzhul   nice
15:17 Krock     https://pastebin.com/raw/L7nBhD3y
15:23 sfan5     it would be a little inconvenient to have 33 bits though
15:24 sfan5     no idea if it's viable to have just 2^31 range for the sqrt
15:26 Krock     it would still be 32 bits. just with the sign handled specially since sqrt(negative value) cannot be expressed with floats
15:27 Krock     the value range would increase a lot, on cost of precision, which is reduced by factor 4
15:27 sfan5     and where do you put the sign if the square root takes up 32 bits?
15:28 Krock     same issue as with the current method. it will need sanity checks
15:33 Krock     1.121305E+12 would be the maximal positive transferable value (0x7FFFFFFF), using the multiplicator 2028 which results in an average precision error of 80 ppm
15:35 sfan5     so you want to transfer an s32, not an u32
15:36 sfan5     do we need signed zero's?
15:36 Krock     it's sent as a u32 anyway and converted back
15:38 Krock     also - do we need inf/-inf and nan? these all would not be handled there
15:39 sfan5     nan is not allowed to be sent, not sure about inf
18:18 celeron55 Krock: is sqrtf really faster than reading float bits from memory?
18:19 celeron55 also on platforms other than x86
18:19 Krock     celeron55, no it's much slower. But to ensure that floats have the correct format, we would need to use the C(++) functions to get the mantissa and exponent bits and assemble it manually together
18:19 Krock     since we can't rely on a portable memory representation
18:20 celeron55 it's common to use the IEEE 754 format though, and optimize it by reading it from memory on platforms that use it, which currently is all platforms MT even builds on, probably
18:21 Krock     and this assemble process (at least two function calls, bit shifting and sanity checks) would probably take much longer than taking the sqrt of it
18:21 Krock     yes. probably.
18:22 celeron55 there might even be a tiny library for doing it on x86 and arm which are the the only current platforms that really are capable of running MT
18:23 celeron55 altough, what's the point of a library when the only thing it does is copy a value to and from memory...
18:23 sfan5     i'm quite sure it'd run on ppc and mips too
18:24 sfan5     anyway, directly copying the float is of course preferable but we'd need to be sure that it works identically on all supported platforms which is not easy
18:24 Krock     also regarding -ffast-math
18:25 celeron55 sfan5: those use ieee754 also
18:25 Krock     we would need to ensure that the compiler does not optimize it
18:25 Krock     IEEE only states how many bits are required, not where they are
18:25 sfan5     optimize it in what way?
18:27 Krock     hm. good question. the instruction set is laid out for only one specific format of floats, so optimizing seems counter-productive
18:28 celeron55 when the value goes to memory, it's going to be in the correct format; register contents don't really matter
18:30 celeron55 in any case, this is quite a common problem, there really should exist a common solution
18:31 nerzhul   Krock more comments on #7394 ?
18:31 ShadowBot https://github.com/minetest/minetest/issues/7394 -- Modernize lua read (part 1): C++ templating insurance by nerzhul
18:32 sfan5     https://github.com/google/protobuf/blob/ba4e54724d2e6a1881c4fe88664d81fbacaf8c08/src/google/protobuf/wire_format_lite.h#L804
18:32 sfan5     this is what protobuf does
18:33 Krock     interesting. I thought union was only an allowed trick in plain C
18:34 p_gimeno  you can even use bitfields: https://stackoverflow.com/questions/15685181/how-to-get-the-sign-mantissa-and-exponent-of-a-floating-point-number
18:35 sfan5     Krock: union exists the same way in c++ but you can't put any non-primitive types in it
18:35 sfan5     roughly speaking
18:36 Krock     clases/structs
18:38 nerzhul   Krock nearly all C tricks works in C++
18:54 celeron55 union is the way you do that, but the question is, what is the set of platforms that works interoperably on (given that you can swap endianess or other simple bit/byte shuffling)
18:57 p_gimeno  I think that changing endianess typically changes both floats and ints, so they still read the same
19:02 nerzhul   it's easy, test BSD vs linux
19:02 nerzhul   one is big endian, other not
19:02 nerzhul   if the map is totally crappy when loaded it's not good :p
19:14 paramat   there doesn't seem to be a build of frozen 0.4.17 for people to test? seems a good idea :)
19:32 paramat   sfan5 ^
19:35 nerzhul   yeah release is on sunday no ? :)
19:38 Krock     yes.
19:45 sfan5     maybe a bit late for a test build then
19:45 sfan5     but i guess i finally get an answer to my question: no there are no more commits that need to be backported
19:49 paramat   it feels under-tested, especially if there isn't a build for it
19:50 paramat   * possibly under-tested
19:57 paramat   the forum thread doesn't ask people to test it either
21:28 paramat   #7393
21:28 ShadowBot https://github.com/minetest/minetest/issues/7393 -- Biomemap: Avoid empty biomemap entry when seabed is below y = -32 by paramat
21:30 paramat   merging game#2135 in 5 mins
21:30 ShadowBot https://github.com/minetest/minetest_game/issues/2135 -- Biomes: Make beaches snowy in snowy biomes by paramat
21:39 paramat   merging
21:40 paramat   done
22:32 paramat   ok, merging game#2128 in 5 mins
22:32 ShadowBot https://github.com/minetest/minetest_game/issues/2128 -- TNT: Raise cost of TNT by adding a TNT stick crafting stage by paramat
22:40 paramat   merging
22:42 paramat   dun
23:20 paramat   #7393 is trivial will merge in 30 mins
23:20 ShadowBot https://github.com/minetest/minetest/issues/7393 -- Biomemap: Avoid empty biomemap entry when seabed is below y = -32 by paramat
23:50 paramat   actually no i won't, it needs more work
23:50 paramat   merging game#2082 in 5 mins
23:50 ShadowBot https://github.com/minetest/minetest_game/issues/2082 -- add optional bones messages for player and log by poikilos