HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
astroautomata
PySR
Python2022–2026
astroautomata / PySR

PySR

Symbolic Learning in Python and Julia

9Distinct people
9Mentions
0Explicit recommenders
4.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Symbolic Learning in Python and Julia

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year9 dated mentions

Observed mentions: 2022-05-11 04:52:54 UTC to 2026-10-25 00:59:32 UTC.

0122022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20242025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC211

What Hacker News says

9 sources
PySR itself is still alright, mostly because of previous development. But not for long. Quality control has collapsed, and e.g. the examples in the repo are now embarrassing vibeslop. Pangram reports 100% AI on most comment blurbs in the examples directory. That in itself is not the problem, AI-generated code could still be valid. But in this case, the AI-generated examples have the characteristic shape of slop: plausible sounding technical jargon, combined with zero actual understanding of either the target domain, or even evolutionary search (loss function design). They were vibed by people who had no idea what they were doing. I suggest taking a look at the "evolved PRNG" example [1]. First, its loss function is basically designed to reward discovering linear feedback shift registers (LFSRs) only. It deliberately gives a massively lowe
Read the rest
r loss to LFSRs than most other functions. The AI slop phrased this in terms of "certifying the period", but the period certificate used only identifies LFSRs of max period, is unsound on the rest of the search space, and gives a meaningless very high loss to most non-LFSRs. So the regression will almost always just return an LFSR. Whoever designed the example (Codex I suppose) also knew that most LFSRs are defective, and make poor random number generators. Thus, they included a "shear" penalty to detect such defective LFSRs, but of course they slopped it together. The 360 correlations they measure should have been added together (having just one strong correlation is bad, and having two strong correlations is twice as bad as havin one). Instead, they take the MEAN of the correlations, so a perfect correlation contributes only 1/360=0.00278 to the loss. And indeed, the result of their example run, reported in the docs [2] has such a perfect correlation: bit 29 is copied to bit 31 every two iterations. [1] https://github.com/astroautomata/PySR/blob/master/examples/p... [2] https://pysr.ai/v2.7.0/examples/objectives#inventing-a-pseud...
In Symbolic Learning in Python and Julia
Inspired by this post & TF comment I tried symbollic regression [0] Basically it uses genetic algorithm to find a formula that matches known input and output vectors with minimal loss I tried to force it to use pi constant but was unable I don't have much expreience with this library but I'm sure with more tweaks you'll get the right result from pysr import PySRRegressor def f(n): if n % 15 == 0: return 3 elif n%5 == 0: return 2 elif n%3 == 0: return 1 return 0 n = 500 X = np.array(range(1,n)).reshape(-1,1) Y = np.array([f(n) for n in range(1,n)]).reshape(-1,1) model = PySRRegressor( maxsize=25, niterations=200, # < Increase me for better results binary_operators=["+", "*"], unary_operators=["cos", "sin", "exp"], elementw
Read the rest
ise_loss="loss(prediction, target) = (prediction - target)^2", ) model.fit(X,Y) Result I got is this: ((cos((x0 + x0) * 1.0471969) * 0.66784626) + ((cos(sin(x0 * 0.628323) * -4.0887628) + 0.06374673) * 1.1508249)) + 1.1086457 with compleixty 22 loss: 0.000015800686 The first term is close to 2/3 * cos(2pi*n/3) which is featured in the actual formula in the article. the constant doesn't compare to 11/15 though [0] https://github.com/MilesCranmer/PySR
In Solving Fizz Buzz with Cosines
I spent some time toying around with LLM-guided "symbolic regression", basically having an LLM review documents in order to come up with primitives (aka operators) that could be fed into github.com/MilesCranmer/PySR I didn't get very far because I had difficulty piping it all together, but with something like this I might give it another go. Cool stuff.
In SymbolicAI: A neuro-symbolic perspective on LLMs
> Yes, julia can be called from other languages rather easily This seems false to me. StaticCompiler.jl [1] puts in their limitations that "GC-tracked allocations and global variables do not work with compile_executable or compile_shlib. This has some interesting consequences, including that all functions within the function you want to compile must either be inlined or return only native types (otherwise Julia would have to allocate a place to put the results, which will fail)." In practice, this means that you can therefore not use the base library in your own programs. PackageCompiler.jl [2] has the same limitations if I'm not mistaken. So then you have to fall back to distributing the Julia "binary" with a full Julia runtime, which is pretty heavy. There are some packages, such as PySR [3], which do this. It seems pretty usable for re
Read the rest
search I'd say, but difficult to put in production. There is some word going around though that there is an even better static compiler in the making, but as long as that one is not publicly available I'd say that Julia cannot easily be called from other languages. [1]: https://github.com/tshort/StaticCompiler.jl [2]: https://github.com/JuliaLang/PackageCompiler.jl [3]: https://github.com/MilesCranmer/PySR
In Potential of the Julia programming language for high energy physics computing
I encourage everyone to read this paper. It's well written and easy to follow along. To the uninitiated, SR is the problem of finding a mathematical (symbolic) expression that most accurately describes a dataset of input-output examples (regression). The most naive implementation of SR is basically a breath first search starting from the simplest program tree: x -> sin(x) -> cos(x) ... sin(cos(tan(x))) until timeout. However, we can prune out equivalent expressions and, in general, the problem is embarrassingly parallel which alludes to some hope that we can solve this pretty fast (check out PySR[1] for a modern implementation). I find SR fascinating because it can be used for model distillation: learn a DNN approximation and "distill" it to a symbolic program. Note that the paper talks about the decision version of the SR problem. ie: ca
Read the rest
n we discover the global optimum expression. I think this proof is important for the SR community but not particularly surprising (to me). However, I'm excited by the potential future work for this paper! A couple of discussion points: * First, SR is technically a bottom up program synthesis problem where the DSL (math) has an equivalence operator. Can we use this proof to impose stronger guarantees on the "hyperparameters" for bottom up synthesis. Conversely, does the theoretical foundation of the inductive synthesis literature [2] help us define tighter bounds? (EDIT: I was thinking a bit more about this and [2] is a bad reference for this... Jha et al give proofs for synthesis w/ CEGIS where the synthesizer queries a SMT solver for counterexamples until there are none... kinda like a GAN. Apologies.) * Second, while SR itself is NP hard, can we say anything about the approximate algorithms (eg: distilling a deep neural network to find a solution[3])? Specifically, what proof tell us about the PAC learnability of SR? Anyhow, pretty cool seeing such work get more attention! [1] https://github.com/MilesCranmer/PySR [2] https://susmitjha.github.io/papers/togis17.pdf [3] https://astroautomata.com/paper/symbolic-neural-nets/
In Symbolic Regression is NP-hard

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.