Time Nick Message 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 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 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:53 MTDiscord 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 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 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 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 I'm not a genius, I just know that it matters somewhat, not how much it matters, if that makes sense 12:24 MTDiscord 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 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 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 Complex numbers I guess 14:01 MTDiscord (complex numbers are NaN and yet pretty determinate) 14:01 MTDiscord Anyway, I don't see why you would consider a NaN mean something 14:01 MTDiscord NaN is unequal when compared against itself 14:03 MTDiscord 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 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 There are no widely accepted specs, all NaNs are used interchangeably and all are not equal to themselves. 14:06 MTDiscord @ExeVirus 14:36 MTDiscord 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 Right, hence why they needed a way to do it to support all of wasm 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] are you a German math teacher or what? 19:55 MTDiscord @rubenwardy do you happen to be in the proximity of a black hole right now 20:02 [MTMatrix] 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 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 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"