SymbolicRegression.jl VS hlb-CIFAR10

Compare SymbolicRegression.jl vs hlb-CIFAR10 and see what are their differences.

Our great sponsors
  • Onboard AI - ChatGPT with full context of any GitHub repo.
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern API for authentication & user identity.
SymbolicRegression.jl hlb-CIFAR10
3 35
494 1,170
- -
0.0 3.5
3 days ago 4 months ago
Julia Python
Apache License 2.0 Apache License 2.0
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of SymbolicRegression.jl. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-07-15.


Posts with mentions or reviews of hlb-CIFAR10. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-12-01.
  • Deep Dive into the Vision Transformers Paper (ViT)
    3 projects | | 1 Dec 2023
    Logged into my personal account for this one! I'm a lead author on a paper that explored exactly. It does enable faster training and smaller model sizes. For reference, you can get 80% accuracy on CIFAR-10 in ~30 minutes of CPU (not using crazy optimizations). There are open questions about scaling but at the time we did not have access to big compute (really still don't) and our goals were focused on addressing the original ViT's claims of data constraints and necessities of pretraining for smaller datasets (spoiler, augmentation + overlapping patches plays a huge role). Basically we wanted to make a network that allowed people to train transformers from scratch for their data projects because pretrained models aren't always the best solutions or practical.



    CPU compute:

    Crazy optimizations (no affiliation): 94% on CIFAR-10 in <6.3 seconds on a single A100 :

    I also want to give maybe some better information about ViTs in general. Lucas Beyer is a good source and has some lectures as well as Hila Chefer and Sayak Paul's tutorials.

    Lucas Beyer:

    Chefer & Paul's All Things ViT:

  • Show HN: 78% MNIST accuracy using GZIP in under 10 lines of code
    5 projects | | 20 Sep 2023
    If you'd like to play around with MNIST yourself, I wrote a PyTorch training implementation that gets ~95.45%+ in <13.6 seconds on a V100, est. < 6.5 seconds on an A100. Made to be edited/run in Colab:

    It's originally kitted for CIFAR10, but I've found the parameters to be quite general. The code is very easy to read and well-commented, and is a great starting place for exploration.

    Min-cut deltas to run MNIST:

    `.datasets.CIFAR10('` -> `.datasets.MNIST('` (both occurences)

  • The Mathematics of Training LLMs
    3 projects | | 16 Aug 2023
    Sure. Basically everything in was directly founded on the concepts in the paper, down to the coding, commenting, and layout styles (hence why I advocate so strongly for it as a requirement for ML. The empirical benefits are clear to me).

    Before I sat down and wrote my first line, I spent a very long time thinking about how to optimize the repo. Not just in terms of information flow during training, but how the code was laid out (minimize the expected value of deltas for changes from a superset of possible code changes), and comments (ratio of space vs mental effort to decode the repo for experienced vs inexperienced developers).

    It's not perfect, but I've used info theory as a strong guiding light for that repo. There's more to say here, but it's a long conversation about the expected utility of doing research a few different kinds of ways.

  • There is no hard takeoff
    2 projects | | 11 Aug 2023
    I think this is a good casual introduction to the marketplace dynamics of how ML will impact the market. I do, however, disagree as this version of things assumes a more open-information set of competitive strategies among potentially ideal agents from a game theoretic perspective, and we can see this is absolutely not the case 'in real life'. To one of his examples -- Exxon-Mobil.

    An updated version: There will be a log-normally distributed set of winners and losers from the exponential effects of ML and 'AI', and the flatness of this curve will be almost entirely solely determined by the governance of the various countries in the world over different economic and/or informational policies. Other than that, the information asymmetry is going to make it a power-bloodbath as we go through our informational-industrial revolution.

    While I'm here, I think Hotz does contribute a lot of good to the field, though I do have a bit of a minor personal beef with him. He said he was going to reimplement in tinygrad, bashed a few parts of the code for a while on stream, and then gave up a few hours later because of the empirical speed/occupancy numbers. >:( I want my fast reimplementation, George.

  • In Defense of Pure 16-Bit Floating-Point Neural Networks
    2 projects | | 23 May 2023
    As a practitioner specializing in extremely fast-training neural networks, seeing a paper in 2023 considering fp32 as a gold standard over pure non-mixed fp16/bp16 is a bit shocking to me and feels dated/distracting from the discussion. They make good points but unless I am hopelessly misinformed, it's been pretty well established at this point in a number of circles that fp32 is overkill for the majority of uses for many modern-day practitioners. Loads of networks train directly in bfloat16 as the standard -- a lot of the modern LLMs among them. Mixed precision is very much no longer needed, not even with fp16 if you're willing to tolerate some range hacks. If you don't want the range hacks, just use bfloat16 directly. The complexity is not worth it, adds not much at all, and the dynamic loss scaler a lot of people use is just begging for more issues.

    Both of the main repos that I've published in terms of speed benchmarks train directly in pure fp16 and bf16 respectively without any fp32 frippery, if you want to see an example of both paradigms successfully feel free to take a look (I'll note that bf16 is simpler on the whole for a few reasons, generally seamless): [for fp16] and [for bf16]

    Personally from my experience, I think fp16/bf16 is honestly a bit too expressive for what we need, fp8 seems to do just fine and I think will be quite alright with some accommodations, just as with pure fp16. The what and the how of that is a story for a different day (and at this point, the max pooling operation is basically one of the slowest now).

    You'll have to excuse my frustration a bit, it just is a bit jarring to see a streetsign from way in the past fly forward in the wind to hit you in the face before tumbling on its merry way. And additionally in the comment section the general discussion doesn't seem to talk about what seems to be a pretty clearly-established consensus in certain research circles. It's not really too much of a debate anymore, it works and we're off to bigger and better problems that I think we should talk about. I guess in one sense it does justify the paper's utility, but also a bit frustrating because it normalizes the conversation as a few notches back from where I personally feel that it actually is at the moment.

    We've got to move out of the past, this fp32 business to me personally is like writing a Relu-activated VGG network in Keras on Tensorflow. Phew.

    And while we're at it, if I shall throw my frumpy-grumpy hat right back into the ring, this is an information-theoretic problem! Not enough discussion of Shannon and co. Let's please fix that too. See my other rants for x-references to that, should you be so-inclined to punish yourself in that manner.

  • [P] 10x faster reinforcement learning HPO - now with CNNs!
    3 projects | /r/MachineLearning | 5 Apr 2023
    In a related but different vein (w/ hardcoded hyperparameters), if you'd like to have a research toolbench that trains rapidly on CIFAR10 (94% in <7 seconds on an A100), I made It's also very breadboard-ized, for lack of a better term, so you can reclone and hack stuff in quickly to see if it works or doesn't. Most things I tested took 5 minutes or less, some a few seconds, and just a few more involved ones maybe half an hour to an hour or so, maybe a little more or less with debugging (depending upon how involved it was). I'm definitely curious about the software in this post though, as there was a lot of painful tuning involved (the reward space is, er, quite noisy).
  • MIT 6.S191: Recurrent Neural Networks, Transformers, and Attention
    2 projects | | 2 Apr 2023
    Karpathy's zero to hero series is excellent, and I really recommend it.

    I also made a few repos that are geared around readability and being a good 'working code demonstration' of certain best-practices in neural networks. If you're like me and you grok code better than symbols, this could be a helpful adjunct as well if you're wanting to dig deep a bit.

  • [P] Introducing hlb-gpt: A rapid prototyping toolbench in &lt;350 lines of code to speed up your LLM research exploration
    2 projects | /r/MachineLearning | 5 Mar 2023
    It's release day again and today we're releasing a new repository: hlb-gpt. It's based on nanoGPT, but smaller with an aggressively-trimmed feature set. In this initial release, the training performs almost exactly the same as Andrej's library, but a tiny bit faster and a tiny bit more accurate due to using PyTorch-native operators. We keep the complexity down by targeting tiny, rapid experiments on a single GPU only. The baseline network we're releasing gets <3.8 validation loss in just over 6 minutes. Having a rapidly training network offers a variety of benefits -- this is something that helped a lot when working on hlb-cifar10. Cycle times are king in research, and we rarely need giant models to get enough of a loss signal when prototyping/experimenting with a method.
  • [R] CIFAR10 in &lt;8 seconds on an A100 (new architecture!)
    2 projects | /r/MachineLearning | 12 Feb 2023
    Reposting as the old post somehow pointed to an old release of mine! Strange! If you want to read the new release, you can do that here:
    2 projects | /r/MachineLearning | 12 Feb 2023

What are some alternatives?

When comparing SymbolicRegression.jl and hlb-CIFAR10 you can also consider the following projects:

hlb-gpt - Minimalistic, fast, and experimentation-friendly researcher's toolbench for GPT-like models in ~<365 lines of code. Reaches <3.8 validation loss on wikitext-103 on a single A100 in ~138 seconds.

FromFile.jl - Julia enhancement proposal (Julep) for implicit per file module in Julia

nanoGPT - The simplest, fastest repository for training/finetuning medium-sized GPTs.

symreg - A Symbolic Regression engine

tinygrad - You like pytorch? You like micrograd? You love tinygrad! ❤️

mnist_1_pt_2 - 1.2% test error on MNIST using only least squares and numpy calls.

ModelingToolkit.jl - An acausal modeling framework for automatically parallelized scientific machine learning (SciML) in Julia. A computer algebra system for integrated symbolics for physics-informed machine learning and automated transformations of differential equations

minGPT - A minimal PyTorch re-implementation of the OpenAI GPT (Generative Pretrained Transformer) training

label-errors - 🛠️ Corrected Test Sets for ImageNet, MNIST, CIFAR, Caltech-256, QuickDraw, IMDB, Amazon Reviews, 20News, and AudioSet

umap_paper_notebooks - Notebooks in support of the UMAP paper

Metatheory.jl - General purpose algebraic metaprogramming and symbolic computation library for the Julia programming language: E-Graphs & equality saturation, term rewriting and more.

PySR - High-Performance Symbolic Regression in Python and Julia