35 karma · joined November 24, 2014
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
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).
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.
In this way: you can avoid the need for the `final` keyword and do the optimization the keyword enables (de-virtualize calls).
>Yes, it is very hacky and I am disgusted by this myself. I would never do this in an actual product
Why? What's with the C++ community and their disgust for macros without any underlying reasoning? It reminds me of everyone blindly saying "Don't use goto; it creates spaghetti code".
Sure, if macros are overly used: it can be hard to read and maintain. But, for something simple like this, you shouldn't be thinking "I would never do this in an actual product".
You could use Keras inside of Mojo since Mojo is Python-compatible/embeds a Python interpreter.
It’s an extension from Mercurial as the blog post states.
> written by homebrew author (brew is notoriously slow)
> written in typescript
hmmm... I have my doubts on that claim, especially when there is no evidence to support it.
(1) cannot be achieved without a custom linker or using a JIT such as LLVM or compiling to WASM and embedding a WASM runtime into the binary
I really hope Nim gets some language/compiler upgrades due to this.
Also, just fyi, Google's alternative to Stable Diffusion/DALLE-2, Imagen is not CLIP guided. Thus being CLIP guided is not necessary for the problem.