Time |
Nick |
Message |
00:06 |
|
Tmanyo joined #minetest-dev |
00:16 |
|
book` joined #minetest-dev |
00:21 |
|
octacian joined #minetest-dev |
00:26 |
|
jcalve joined #minetest-dev |
01:07 |
|
Ruslan1 left #minetest-dev |
01:20 |
|
TC01 joined #minetest-dev |
02:20 |
|
paramat joined #minetest-dev |
02:59 |
|
AndroBuilder joined #minetest-dev |
03:01 |
|
Tmanyo joined #minetest-dev |
03:13 |
|
DI3HARD139 joined #minetest-dev |
03:48 |
|
AntumD joined #minetest-dev |
04:47 |
|
Foz joined #minetest-dev |
04:56 |
|
AntumD joined #minetest-dev |
05:24 |
|
AntumDeluge joined #minetest-dev |
06:55 |
|
longerstaff13 joined #minetest-dev |
07:00 |
|
behalebabo joined #minetest-dev |
07:47 |
|
p_gimeno joined #minetest-dev |
07:47 |
|
Wayward_One joined #minetest-dev |
07:47 |
|
fireglow joined #minetest-dev |
07:47 |
|
dzho joined #minetest-dev |
07:50 |
|
fireglow joined #minetest-dev |
07:56 |
|
ensonic joined #minetest-dev |
09:36 |
|
AntumD joined #minetest-dev |
09:38 |
|
Wuzzy joined #minetest-dev |
10:19 |
|
Fixer joined #minetest-dev |
10:41 |
|
entuland joined #minetest-dev |
12:58 |
|
CBugDCoder joined #minetest-dev |
13:02 |
|
proller joined #minetest-dev |
13:36 |
|
Krock joined #minetest-dev |
13:39 |
|
Beton joined #minetest-dev |
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) |
14:38 |
|
antims joined #minetest-dev |
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 |
17:04 |
|
Gael-de-Sailly joined #minetest-dev |
18:17 |
|
Gael-de-Sailly joined #minetest-dev |
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:09 |
|
Hillbilly joined #minetest-dev |
19:10 |
|
Foz joined #minetest-dev |
19:11 |
|
book` joined #minetest-dev |
19:12 |
|
paramat joined #minetest-dev |
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:14 |
|
proller joined #minetest-dev |
19:26 |
|
ensonic joined #minetest-dev |
19:29 |
|
Tmanyo joined #minetest-dev |
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 |
20:09 |
|
EvergreenTree joined #minetest-dev |
20:29 |
|
ssieb joined #minetest-dev |
20:41 |
|
Tmanyo joined #minetest-dev |
21:16 |
|
proller joined #minetest-dev |
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 |
21:49 |
|
Gael-de-Sailly joined #minetest-dev |
21:51 |
|
EvergreenTree joined #minetest-dev |
22:00 |
|
johnnyjoy joined #minetest-dev |
22:15 |
|
proller joined #minetest-dev |
22:17 |
|
Foz joined #minetest-dev |
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:05 |
|
proller joined #minetest-dev |
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:30 |
|
paramat joined #minetest-dev |
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 |