| Time |
Nick |
Message |
| 00:00 |
|
SFENCE joined #minetest-dev |
| 00:18 |
|
SFENCE joined #minetest-dev |
| 00:35 |
|
SFENCE joined #minetest-dev |
| 00:53 |
|
SFENCE joined #minetest-dev |
| 01:10 |
|
SFENCE joined #minetest-dev |
| 01:45 |
|
SFENCE joined #minetest-dev |
| 02:04 |
|
SFENCE joined #minetest-dev |
| 02:21 |
|
SFENCE joined #minetest-dev |
| 02:40 |
|
SFENCE joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 07:56 |
|
MisterE12301 joined #minetest-dev |
| 09:10 |
pgimeno |
@exe_virus I'm not quite sure what you're after, but LuaJIT supports u64 constants and calculations out of the box, without requiring ffi; e.g. 3ULL is valid and is of type cdata. |
| 09:11 |
pgimeno |
If you want to separate a double into its parts, there's math.frexp and math.ldexp. |
| 09:18 |
MTDiscord |
<kimapr> oh it does? |
| 10:18 |
sfan5 |
says stdin:1: unexpected symbol near '3ULL' here if I try that |
| 11:26 |
pgimeno |
have you added 'print'? |
| 11:27 |
pgimeno |
> print(1LL + 3) |
| 11:27 |
pgimeno |
4LL |
| 11:27 |
pgimeno |
> = 1ULL + 3 |
| 11:27 |
pgimeno |
4ULL |
| 11:27 |
pgimeno |
> =tonumber(1LL) |
| 11:27 |
pgimeno |
1 |
| 11:27 |
pgimeno |
> =type(3ULL) |
| 11:27 |
pgimeno |
cdata |
| 11:33 |
MTDiscord |
<exe_virus> I am aware of math.frexp, and math.ldexp. They don't get at the actual bits, they get at the rounded value represented. The reason I need exact bits is for determining which type of NaN is occuring for calculations to satisfy WASM requirements. If you are correct about u64 already being available, then yeah the one that's missing is cdata 'double' |
| 11:38 |
pgimeno |
sorry, I should have used a paste |
| 11:38 |
pgimeno |
the error for `1NN` is different, it says "malformed number near '1NN'" (and PUC Lua says "unexpected symbol near '1'"), therefore I'm pretty sure that '1ULL' is indeed working |
| 11:43 |
pgimeno |
@exe_virus hm, LuaJIT uses NaNs for other data types, for example `true`, `false`, etc. In some cases you can get the sign of NaN to know whether it represents an indeterminate or not-a-number, but in a quick test in my LuaJIT, that's not happening. In PUC Lua it works, though. |
| 11:45 |
pgimeno |
Do you need to know the full exact bits of the NaN? |
| 11:46 |
|
Desour joined #minetest-dev |
| 11:53 |
MTDiscord |
<exe_virus> Yep, that's the requirement. The current software solution (wasynth) uses a union of double and u64 to make those bits inspectable. That's really all there is too it. |
| 11:54 |
MTDiscord |
<exe_virus> If you are actually interested, pgimeo, I can make an issue for it and detail the plan |
| 11:54 |
pgimeno |
@exe_virus do you intend to use them on Lua `number`-typed values? |
| 11:55 |
pgimeno |
@exe_virus I can read github but not write. Taking that into account, sure, I'd be interesting in reading about it. |
| 11:55 |
sfan5 |
pgimeno: ah yeah forgot that |
| 11:57 |
pgimeno |
s/interesting/interested/ |
| 11:58 |
sfan5 |
honestly compiling c to wasm and then that to lua sounds more of a weird but cool PoC to me than something you would use in production |
| 11:59 |
MTDiscord |
<exe_virus> Ironically, wasynth supports luau (Roblox) and their mods/games do* use it in production for certain libraries |
| 12:02 |
sfan5 |
huh |
| 12:07 |
pgimeno |
http://www.formauri.es/personal/pgimeno/pastes/f2i2f.lua tested, distinguishes indeterminate from nan |
| 12:11 |
MTDiscord |
<exe_virus> Yep, exactly |
| 12:22 |
pgimeno |
@exe_virus how important is it to distinguish indeterminate from NaN? is it that big of an issue if indeterminates are turned into NaNs? |
| 12:24 |
MTDiscord |
<exe_virus> I'm not a genius, I just know that it matters somewhat, not how much it matters, if that makes sense |
| 12:24 |
MTDiscord |
<exe_virus> I'm not an expert, I just know the requirements and the general architecture of how it's all accomplished |
| 12:27 |
pgimeno |
LuaJIT does not distinguish them for any purpose whatsoever, so I guess it's not that much of an issue |
| 12:29 |
Desour |
pgimeno: what is one supposed to see in the output of your f2i2f.lua? |
| 12:30 |
pgimeno |
Desour: 0/0 is indeterminate, therefore the sign bit (bit 63) is set when converted to integer |
| 12:30 |
Desour |
ah. so you want to distinguish different types of nan? |
| 12:31 |
pgimeno |
@exe_virus does |
| 12:31 |
pgimeno |
I was just trying to lend a hand |
| 12:32 |
Desour |
do you have an example of a nan that is not an "indeterminate"? |
| 12:32 |
Desour |
(ieee 754 doesn't seem to define this term) |
| 12:34 |
pgimeno |
yeah, math.acos(2) |
| 12:34 |
MTDiscord |
<exe_virus> Here's the "runtime" note that the malloc and many other calls to ffi are not required, only the union for u64 and double: https://github.com/Rerumu/Wasynth/blob/trunk/codegen/luajit/runtime/runtime.lua |
| 12:36 |
Desour |
ah, thx :) |
| 12:41 |
MTDiscord |
<exe_virus> Yeah, it'll be a couple hours before I get to writing up the issue. Here's the toolchain example they give: https://github.com/Rerumu/Wasynth/wiki/From-Rust,-to-Lua Note that I use Zig to compile from C/C++ to WASM32... Much much lighter/easier than rust toolchains |
| 12:58 |
pgimeno |
Desour: PUC Lua can distinguish them: http://www.formauri.es/personal/pgimeno/pastes/puc-lua-nan.txt but apparently LuaJIT always generates negative NaN (I guess that's either intentional, or a limitation of the operations on XMM registers). |
| 13:07 |
Desour |
pgimeno: I think it just prints it differently. otherwise, you wouldn't be able to discriminate it with ffi either. (for me, luajit always prints "nan", without "-", btw) |
| 13:20 |
pgimeno |
Desour: for me at least, math.acos(2) generates negative NaN (same as 0/0) in LuaJIT according to the result of f2i(). |
| 13:41 |
Desour |
pgimeno: `print(string.format("%#x", f2i(math.acos(2))))` is 0x7ff8000000000000 for me, no sign bit |
| 13:45 |
pgimeno |
I'll PM you |
| 13:59 |
MTDiscord |
<herowl> Complex numbers I guess |
| 14:01 |
MTDiscord |
<herowl> (complex numbers are NaN and yet pretty determinate) |
| 14:01 |
MTDiscord |
<herowl> Anyway, I don't see why you would consider a NaN mean something |
| 14:01 |
MTDiscord |
<herowl> NaN is unequal when compared against itself |
| 14:03 |
MTDiscord |
<herowl> I.e. local x = 0/0 if x == x then print("equal") else print("x is NaN") end |
| 14:04 |
pgimeno |
after dicussion with Desour privately it turned out to be a LuaJIT 2.0 vs 2.1 thing. I was testing with 2.0 and it always produces negative NaN |
| 14:05 |
MTDiscord |
<herowl> OK, but why to try to make any distinguishing of NaNs? |
| 14:05 |
pgimeno |
not sure why, it was exe_virus who wanted to |
| 14:05 |
MTDiscord |
<herowl> There are no widely accepted specs, all NaNs are used interchangeably and all are not equal to themselves. |
| 14:06 |
MTDiscord |
<herowl> @ExeVirus |
| 14:36 |
MTDiscord |
<josiah_wi> There’s some semantic difference between a quiet NaN and a signaling NaN, no? |
| 14:37 |
pgimeno |
yes but I don't think LuaJIT can generate signaling NaNs |
| 14:37 |
pgimeno |
(nor PUC Lua, for the matter) |
| 15:25 |
MTDiscord |
<exe_virus> Right, hence why they needed a way to do it to support all of wasm |
| 16:31 |
|
fluxionary_ joined #minetest-dev |
| 17:15 |
|
fluxionary_ joined #minetest-dev |
| 17:17 |
|
SFENCE joined #minetest-dev |
| 19:33 |
rubenwardy |
merging #14705 and #14757 in 10 |
| 19:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/14705 -- Fix unnecessary content refreshing by rubenwardy |
| 19:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/14757 -- Fix math.round floating point bug by kromka-chleba |
| 19:50 |
Krock |
10 what? APPLES?? ping rubenwardy |
| 19:53 |
[MTMatrix] |
<grorp> are you a German math teacher or what? |
| 19:55 |
MTDiscord |
<luatic> @rubenwardy do you happen to be in the proximity of a black hole right now |
| 20:02 |
[MTMatrix] |
<grorp> also merging #14762, #14774 in 10 min since we're already at it |
| 20:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/14762 -- Document alternative 'persist' key in noise parameter table by aminothere |
| 20:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/14774 -- Properly escape Markdown markups at minetest.string_to_area by Emojigit |
| 20:09 |
pgimeno |
gah, too late to say something about #14757 |
| 20:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/14757 -- Fix math.round floating point bug by kromka-chleba |
| 20:09 |
rubenwardy |
it's not, we can always revert |
| 20:09 |
Krock |
hmm. MinetestBot didn't announce the commits |
| 20:32 |
pgimeno |
well, according to the comments in https://stackoverflow.com/a/18313481 someone claims that adding 0.49999999999999994 instead of 0.5 should make it work for all numbers, and that's shorter and faster |
| 20:33 |
pgimeno |
I guess rounding to nearest or even would break compatibility, right? |
| 20:36 |
pgimeno |
most people seem surprised by the fact that 2.5 gets rounded down to 2 |
| 20:46 |
Mantar |
yeah that's not a rounding convention I'd want for most cases |
| 20:47 |
pgimeno |
it's the most useful one though, that's why the FPU implements it as default (and it doesn't even support "round to nearest or away from zero") |
| 20:49 |
MTDiscord |
<warr1024> We should just do "unstable equilibrium" rounding. Numbers 0 < n < 0.5 round down to 0. Numbers 0.5 < n < 1 round up to 1. If the value is exactly 0.5, it's perfectly at equilibrium, so it stays as 0.5. |
| 20:49 |
pgimeno |
that's definitely NOT what most people want - they want an integer |
| 20:50 |
MTDiscord |
<warr1024> It's the integest we can do under the circumstances 😏 |
| 21:03 |
Mantar |
my general order of preference would be towards positive/negative > towards or away from zero > towards nearest even or odd number, but each of those suit some uses better than others so the real answer is "it depends on what you're doing" |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
