I suspect the current situation is mostly due to timezones and as the west coast wakes up we‘ll see more cities appear there. It’ll probably take a few days until you can deduce anything about hn-users in general from that map.
And thanks for the comment - made me look outside my immediate surroundings on the map!
Fun fact: I randomly asked chatgpt to repeat an answer in German yesterday and tomy surprise it just did! Then i continued the conversation (I asked it to be a pretend DM for my first, guided D&D experience) in German and it just worked about as well as in English. The same was true when I switched to French during the ‘conversation’.
I absolutely didn’t expect that because I’ve never seen it in the hyped up examples here and on twitter.
Of course your point still stands with smaller languages and/or markets.
What a nice blogpost! I really enjoyed how Bruno leads us through the whole process including his thoughts and strategies to find the code that needs to be modified and how to do it. Luckily the problem - how to get the bytes of a sqlite record - is small enough in scope to solve in a readable blogpost. That’s a „genre“ i really enjoy.
Interesting that he could also do purely by reading the code, or at least presents it that way. I might have started by hooking a debugger to the application and seeing where an insert takes me. Guess many roads lead to rome.
For people who enjoy this article I recommend reading the two-parter “How does SQLite work?” [1] [2] by Julia Evans. It too is an exploration into the inner workings but diving deeper into code.
And for those interested in more details on b-trees, there’s “The Ubiquitous B-Tree” by Douglas Cramer which I enjoyed a lot.
This is pretty much what I'm going for :). At this point in the project we have an einsum that is slow but works for all cases and supports AD. Next steps are splitting up contractions into pairwise contractions, finding optimal orders, evaluating the contractions with the best algorithm (so we might dispatch matrix multiplication to BLAS) and supporting different backends (probably just GPU but if more general tensor types could be supported that'd be great).
As others mention there's alternative approaches. For someone with a physics background thoughm it's very natural to think of matrix - or rather tensor, i.e. more than two indices - operations with indices - it's how we work in (general) relativity and some condensed matter physics.
So while obscurity depends on your background, it is sometimes a bit finicky - I can't count the number of times I switched indices around or wrote an 'i' instead of a 'j' but that's something that I deal with with testing (mostly property-tests in physics).
It's not optimal, but it's the best I know and named-indices would have their drawbacks too.
Heya,
for standard arrays that are small, the einsum-macro from Einsum.jl can be faster than BLAS. Einsum.jl translates the code simply into three loops and if cache-access patterns (presumably what most of BLAS optimisation is concerned with) isn't an issue, the for-loops are very fast.
A quick check shows that for a simple matrix multiplication, Einsum is faster for 5x5 matrices but slower for 10x10. (This is ignoring the compilation-time that calling a julia function for the first time incurs)
And thanks for the comment - made me look outside my immediate surroundings on the map!