- You nailed it - that's my criticism :)
I've worked with a lot of code like this (particularly C libraries and litanies of return codes), and it's fine... But I prefer something like Java-style exceptions. And with Java lambdas or Kotlin the trend is unfortunately away from checked exceptions these days...
I too am interested in your other reasons!
- I'm the opposite - I really like checked exceptions in Java because it's very easy to see how developers are handling errors and they also form part of the function signature.
Most functions will just pass on exceptions verbatim so it's better than error return values because with them the entire codebase has to be littered with error handling, compared to fewer try catch blocks.
setjmp, etc. are like unchecked exceptions, so I'm also not a fan, but I use this occasionally in C anyway.
- We purposefully didn't use shared_ptr and hence weak_ptr. With these, it is all too easy to construct the "bad" version which has the stub reference count and pointer stored far away in memory from the object itself requiring a double dereference to access the object which is bad for cache performance. Instead we derived off a shareable class that has the reference count to make sure it is close in memory.
We were happy to use unique_ptr, however.
- Was also gonna jump in with the old way of doing circle boundaries, which can be done all integer: https://en.m.wikipedia.org/wiki/Midpoint_circle_algorithm
- For my day job I'm either "Getting things done" or Zettelkasten anyway because it's more about retrieval than memory.
But for languages, SRS is great.
And I'm also glad I memorised a whole bunch of math formulas way back. E.g. Boolean algebra I keep using an identity that I couldn't find on identity sheets by web search.
- Totally expected the "desirable difficulties". For SRS to work effectively it has to "be yours" and that only works effectively if you're building your own cards.
With Duolingo it kind of encourage small bursts rather than the hour (minimum) per day you need with Anki for better or worse.
- Nice write up!
I've got a soroban but never got around to learning it. Definitely should pick that up again.
When I was at Uni (electrical engineering) I noticed that the Chinese students would reach for their calculator way less than western students and assumed that was because of the abacus.
Side note: they tried to shape a control theory subject (everyone was getting 100%) by disallowing calculators in tests. It was rough having to do things like long division for the first time in decades. Still everyone got 100% haha.
- Yeah it's probably field specific and I guess Gaussian-based uncertainty would be more about statistical sampling rather than tolerances. I've noticed that if arithmetic is being done on it it's almost certainly Gaussian. I just mean whenever I see uncertainty like this, I don't know what is meant!
- On the scheduling end, I'm surprised the article didn't mention https://github.com/fasiha/ebisu which uses Bayesian statistics.
When I was studying Japanese, I was thinking how it's always best to learn words in sentences and that it would be good if the sentences for a particular word were random.
Extending that, the sentences could be picked such that the other words are words scheduled for today meaning much more bang for buck per learning hour.
- I had kind of written off using types because of the complexity of physical units, so I will be having a look at that!
My biggest problem has been people not specifying their units. On our own code end I'm constantly getting people to suffix variables with the units. But there's still data from clients, standard library functions, etc. where the units aren't specified!
- Totally missed that, thanks! I don't know the library very well, but as far as I can tell they don't support .xyxy style sizzling with the SIMD Vec4 type.
They're using the same "proxy object" method I was doing for their sizzling which I'm pretty sure won't work with SIMD types but would love to be proven wrong!
I haven't deep dived into the library as I'm no longer doing this kind of code.
- Unfortunately GLM doesn't use SIMD instructions.
I really wanted something that's compatible with shaders and fast so we can quickly swap between CPU and GPU because it was time consuming to port the code.
I've been down this road before. If you aren't doing SIMD it's pretty easy to implement but relies on UB that works on all the compilers I tried (C++ properties would make this better and portable). I got something working with SIMD that unfortunately doesn't compile correctly on Clang!
I saw interlaced NTSC video in the digital days where the combing was much more obvious and always assumed it was only an NTSC thing!