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
The default setup is pretty crappy but with some tweaking of the ssh connection setup, It does a decent job and I used it for actual work for several years.
It's been a long time. Most of the stuff I was able to get from conversations on the Emacs IRC channel of freenode. Many of those "tricks" are documented here https://www.emacswiki.org/emacs/TrampMode but I don't know if it's out of date.
Curious to know how the OP is biased when they have no conflict of interest, and they explicitly mention the `torch.compile` stack like... a few dozen times in the blog?
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.
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).
> How do you measure beauty? You can't: "beauty" is subjective
Let me try: in classical dance, martial arts, or even skateboarding, advanced skills manifest as effortlessness: the movements comes naturally, they're not forced, things just flow.
If you compare a typical functional (recursive + pattern matching, but the point would stand even with a fold) factorial with an imperative one (for loop), the functional approach is more effortless, you have to be less explicit about what's going on. It's more eloquent.
However as you seem to imply, when we're programming, the focus should be on delivering something that works as expected; this particular kind of aesthetic is secondary at best.
This is a painfully stemlord response. 'Aesthetic qualities cannot be objectively measured therefor they do not exist'. Christ. Its fine to pick a metric to evaluate one thing against another, its another to deny that there are other ways to value things.
I never understood anyone who used such strong language like "beauty" when talking about something mundane like recursion. I suspect it's just in-group language like how a cult understands the meaning of their own words, while to outsiders it would appear nonsensical. I have seen other groups appropriate the word "beauty" too, like people who chronically overeat.
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.
I've always seen "Premature Optimization" as an umbrella that covers a variety of cross-cutting concerns, ranging from:
- Performance
- Code structure / abstraction
- Data structure
- Team organization / org structure
I'd argue that DRY (and a focus on abstractions more generally) are optimizations of the codebase. Not all optimizations are optimizing the same thing.
Yeah, it's like reminding people that code can change, so it's ok to have known flaws day 1. Something forgotten too often.
One thing that really goes against the usual programming grain is DBMSes. We're taught to always decouple/abstract things, but I'm convinced that it's impossible to abstract away your DBMS in most applications. It's just too big of an interface, and performance considerations leak right through it. It's always one of the selling points of an ORM, "you can switch databases later," and then nobody actually switches.
