purplesyringa

5 ms·

1.
by purplesyringa 4d ago
I think you might be interested in reading the post Are We Really Engineers ( https://www.hillelwayne.com/post/are-we-really-engineers/ ), which in part covers the point about whether "engineer" is closer
2.
by purplesyringa 4d ago
I won't lie, of course my code has bugs. The difference, as I see it, is the kinds of bugs that manifest, and how well they can be avoided. There are two steps to writing the program: building a model in your head to map understanding
3.
by purplesyringa 2mo ago
To expand on this, the imprecision arises the moment you write 0.1 (decimal) in source code and the compiler converts it to binary; the arithmetic itself is (mostly) exact. So as long as you use numbers that look "good enough" in
4.
by purplesyringa 2mo ago
`log_a x < log_b x` is the mathematically correct result. Due to inherent rounding from floats being a finite representation of real numbers, `log_a x <= log_b x` would be expected from any correct implementation using floats. So eith
5.
by purplesyringa 2mo ago
I sort of needed to do that. I needed to compress data with an approximately geometric distribution, and as part of that process I needed to invert its CDF, which is `CDF = 1 - (1 - p)^x`. That translates to `x = log_(1 - p) (1 - CDF)`, whi
6.
by purplesyringa 2mo ago
That's interesting! On my PC it reproduces under Lua 5.5 (`log_a x > log_b x`), but not under LuaJIT (`log_a x = log_b x`). I took a look at LuaJIT's implementation ( https://github.com/LuaJIT/LuaJIT/bl
7.
by purplesyringa 2mo ago
Thank you! This point has been driving me mad for the last couple of years. While answering a sibling comment, I found a paper analyzing various libms for their precision: https://homepages.loria.fr/pzimmermann/papers&#
8.
by purplesyringa 2mo ago
Thank you! I completely agree with this, floats are treated as a lot more magical than they actually are. I myself often rely on their exact guarantees for fun tricks (e.g. fast precise int<->float conversion: https://purpl
9.
by purplesyringa 2mo ago
The log base is a parameter, not a function, so that doesn't typecheck. Multivariate monotonicity isn't really a popular term, as far as I'm aware, so I'm not aware of good terminology for this. Maybe "log is non-mo
10.
by purplesyringa 2mo ago
Python, PHP, and Rust do indeed use libm. Not LLVM's libm specifically, though, but rather just about anything they can find in runtime, and those libraries can have suboptimal accuracy. Node uses V8, which notably implements a ton of
11.
by purplesyringa 2mo ago
> PHP uses a JIT from Lua. Wow, TIL! I was certain this is a mistake, but apparently PHP uses DynAsm ( https://wiki.php.net/rfc/jit ), which was developed for LuaJIT ( https://luajit.org/dynasm.html ).
12.
by purplesyringa 2mo ago
Yeah, I simplified it a little. Though I must say I'm surprised pretty much every library I looked at uses the natural logarithm specifically, and not log2, which would seemingly be easier to compute with floats. Does anyone here know
13.
by purplesyringa 2mo ago
> small source files How small are we talking? We've had great success with bzip-style compression on ~400 KB (about 20% better than gzip), but I don't know if it scales well. It's also relatively fast to decode (something
14.
by purplesyringa 2mo ago
We considered it, but that requires knowing the path to the file and being able to open it, which I don't think is possible in general (e.g. if the file is loaded with `loadstring`, or if it's loaded from tmpfs and then deleted, e
15.
by purplesyringa 2mo ago
Thanks! I relayed this to Yuki and we'll make sure to fix the issues. > You can include the start delimiter in the string: At first I had no clue why we thought that didn't work, in fact, my prototype had a fun commit specifica
16.
by purplesyringa 2mo ago
> the fence basically means "resolve all funny business with this variable before proceeding" Thanks, that's a good explanation! I understand it better now. > What I'd actually worry most about is poisoning the pre
17.
by purplesyringa 2mo ago
> A huge part of the problem here is that you're playing with the 8-bit registers. [...] That's an interesting thought, though in this particular case I think it's a little misguided. 8-bit arithmetic (or, god forbid, 16-b
18.
by purplesyringa 2mo ago
The right-shift is the problem. You need to shift right by `j * 8`, which itself requires a shift to compute (`j << 3`), so you have two shifts on the critical path, resulting in a latency of 2 cycles. It's better than a load,
19.
by purplesyringa 2mo ago
I knew the loop was latency-bound and I couldn't easily decrease the latency, so I knew I had to somehow avoid the dependency chain at all. I remembered that CPUs predict some properties of memory accesses (e.g. they might predict that
20.
by purplesyringa 2mo ago
The optimization in the post is only advantageous if `next_j[i][j] == j` holds often enough. Without prior knowledge, the compiler can't know if it's going to improve performance, and the worst losses are greater than the best win
21.
by purplesyringa 2mo ago
That would be great, if only it worked as intended! From the perspective of an optimizing compiler, `a == b ? a : b` is worse than `b` regardless of the probability you assign to `a == b`. ETA: someone on Lobsters ( https://lobste
22.
by purplesyringa 2mo ago
Thanks!
23.
by purplesyringa 5mo ago
My brain does not understand how one can see `(+ a b)` in text and read it as `a b +`. I suppose you can argue that moving operators to the right and removing all parentheses converts `(+ a b)` to `a b +`, sure, but that applies to pretty m
24.
by purplesyringa 5mo ago
There used to be hype about Wasm, now it's a technology as any other. It's still used, and used a lot; it just doesn't get focused on as much.
25.
by purplesyringa 5mo ago
> tl;dr: the LISP syntax is just syntax sugar. The textual format is as "stack-like" as the binary format. Not that you're technically wrong, but I think you're begging the question. Stack-based languages/encodin
26.
by purplesyringa 5mo ago
There's just so many "but"s to this that I can't in good faith recommend people to treat floats as deterministic, even though I'd very much love to do so (and I make such assumptions myself, caveat emptor): - NaN bi
27.
by purplesyringa 5mo ago
And here are the constants for the ostensibly more useful 54x54->108 product: https://play.rust-lang.org/?version=stable&mode=release&edit... I tried to go even higher, but the bounds seems to break at 55 bits.
28.
by purplesyringa 5mo ago
I think it fails because it seems like the difference between 32-bit and 64-bit floats is 2x, but in reality we should look at the mantissa, and the increase from 23 bits to 52 bits is much greater. Although I managed to tweak this method t
29.
by purplesyringa 5mo ago
> Very tangential, but I could swear QBasic included an on-disk documentation system accessible from the editor. Maybe only later versions? Perhaps my installation didn't include it, or maybe you're confusing it with QuickBASIC
30.
by purplesyringa 5mo ago
I don't think it's possible to apply this trick to 64-bit floats on 64-bit architecture, which OP mentions in the last sentence. You need a 52 x 52 -> 104 product. Modular 64 x 64 -> 64 multiplication gives you the 64 bottom

More ›