Why did you go with a publisher rather than publishing it yourself?
Readit Newspineapple_sauce commented on Show HN: I got laid off from Meta and created a minor hit on Steam · Posted by u/newobj
pineapple_sauce commented on Ask HN: Is anybody building an alternative transformer? · Posted by u/taiboku256
Related: There was buzz last year about Kolmogorov Arnold Networks, and https://arxiv.org/abs/2409.10594 was claiming KANs perform better than standard MLPs in the transformer architecture. Does anyone know of these being explored in the LLM space? KANs seem to have better properties regarding memory if I'm not mistaken.
I believe KAN hype died off due to practical reasons (e.g. FLOPs from implementation) and empirical results, i.e. people reproduced KANs and they found the claims/results made in the original paper were misleading.
Here's a paper showing KANs are no better than MLPs, if anything they are typically worse when comparing fairly. https://arxiv.org/pdf/2407.16674
> 12GB max is a non-starter for ML work now.
Can you even do ML work with a GPU not compatible with CUDA? (genuine question)
A quick search showed me the equivalence to CUDA in the Intel world is oneAPI, but in practice, are the major Python libraries used for ML compatible with oneAPI? (Was also gonna ask if oneAPI can run inside Docker but apparently it does [1])
Someone reinvented tramp-mode.
This appears to be a significantly better implementation. Tramp mode is god awful slow and does not maintain a persistent connection.
pineapple_sauce commented on The future of Deep Learning frameworks neel04.github.io/my-websi... · Posted by u/lairv
PyTorch is the javascript of ML. sadly "worse is better" software has better survival characteristics even when there is consensus that technology X is theoretically better
How is Jax theoretically better than PyTorch? The author is ignorant of torch.compile and biased as other commenters have pointed out.
"Meat produced" - why not just say it how it is? "Animals killed" ...
MacPorts is strictly superior to HomeBrew and does not take the same eff you stance towards its users that HB has in the past.
The last time I used MacPorts it fell out of popularity and did not have nearly as many packages as Homebrew had. It's unfortunate. Homebrew is dogshit slow.
pineapple_sauce commented on State of Text Rendering 2024 behdad.org/text2024/... · Posted by u/behdad
On rasterization & basic typesetting (no ligatures/gsub lookups): check out pixie https://github.com/treeform/pixie
pineapple_sauce commented on Misconceptions about loops in C dl.acm.org/doi/10.1145/36... · Posted by u/matt_d
Recursion is more beautiful.
But take a newbie, and "do this 3 times" in a loop is far more clear than the recursive equivalent.
How do you measure beauty? You can't: "beauty" is subjective. And even if you try e.g. count the times you use recursion vs. iteration: that metric is subjective and not grounded in reality.
Sometimes recursion does allow you to reason about code more easily or come to a working solution faster, sometimes it does not.
Measure the concrete: CPU time and memory consumed. Iteration will likely trump recursive methods w.r.t both these metrics. If it doesn't, you can likely transform your iterative algorithm to one that utilizes SIMD (not always).
pineapple_sauce commented on Don't DRY Your Code Prematurely testing.googleblog.com/20... · Posted by u/thunderbong
One of the #1 issues I’ve seen with DRY over the years seems to stem from a misunderstanding of what it means.
DRY is not just about code duplication, it’s about information/knowledge duplication, and code happens to be one representation of information.
Hyper focusing on code duplication quickly gets into premature optimization territory, and can result in DRYing things that don’t make sense. Focusing on information duplication leaves some leeway for the code and helps identify which parts of the code actually need DRY.
The difference is important, and later editions of the Pragmatic Programmer call this out specifically. But the concept of DRY often gets a bit twisted in my experience.
How is applying DRY entering premature optimization territory (maybe relative to LOC?)? I argue it is instead: premature abstraction.
Optimization is specialization (which is the opposite of DRY): to enable DRY you likely need to generalize the problem (i.e. abstract) such that you remove duplication.