I think the person is most likely talking about minimum capital requirements (which are not a “deposit outside of their doors”) and doesn’t quite understand the system.
To understand the regulatory framework for banks, the best place to start is the BIS and Basel III. https://www.bis.org/committees/bcbs/standards
Generally speaking, international banks follow Basel III in addition to their domestic regulators’ capital requirements (which are probably also derived from Basel III, but have differences just to make things tedious).
However, BIS and Basel III (and the previous Basels) are just what's currently in force for most of the world. I suspect most people would be better served by more of an historical overview. But it also depends on what one is interested in.
Aw man! Some serious nostalgia-bait there, with two of my personal faves on the front cover. People may not realise, but HP used to make really amazing devices, primarily targeting scientific and engineering users.
The computer in the back with the magnetic tape drive and thermal printer is an HP85a. We had one of those in about 1982-ish, which my dad bought for home use since they used HP equipment in his lab at work. My friend who had a Sinclair ZX-81 would marvel at the fact that (since we had an expansion cartridge) it had a mighty 32K of ram! Absolutely vast in comparison to the 1k of a ZX-81. The HP85a came with really great manuals which taught you how to program in basic, and had a wonderful keyboard. I have a ton of mechanical keyboards and I only once managed to get keycaps that feel as nice as the ones on the HP85a.
That calculator (which I think is an HP-67) also has some history for me. I can’t be exactly sure of the model number, but that looks like the one which was the first RPN calculator I ever programmed. My dad gave me some pocket money to translate a FORTRAN program he had written (which estimated something or other to do with some chemical process) to run on that calculator. He was really excited by the fact that a program he had written to run on an enormous university mainframe that took a whole floor now could run on a thing he could carry well, if not in his pocket (it’s a pretty chunky calculator) at least in his briefcase. That calculator has a really cool red segment display. Really an incredibly capable device due to wonderful design, it (like all HP RPN calculators) allows you to program literally any repeatable algorithm you can execute by hand on the calculator because it’s just a stack machine and you have everything you need (eg conditional branches etc). So that first program I wrote on it was using Newton-Raphson for something or other for example.
HP calculators used to be wonderfully robust so even a clumsy 10-ish year old like I must have been at the time was able to mess around with it in complete confidence that I wasn’t going to break my dad’s work device. There is a legend that a zookeeper was using an HP-12c calculator once to calculate ratios of ingredients and dropped it into the feed. The story goes that the calculator passed through the digestive tract of a hippo and was still able to calculate the yield to maturity on a bond (after cleaning). Source for the story (search for “tough construction): https://www.hpmuseum.org/hp12c.htm
The calculator survived the hippo's digestive process as well as the washing that followed.
Many decades ago, all HP measurement instruments were delivered with wonderful service manuals, which explained in great details the schematics and the mode of operation.
I have learned much more from those manuals (and also from the manuals of many other companies which have disappeared or from which only empty skeletons survive, even in the case when they still have big revenues, e.g. Tektronix, Motorola, National Semiconductor, Fairchild, General Electric, Philips, Siemens, Thomson and many others) than from most university textbooks.
Named after Kepler, who went from Tycho Brahe’s observational data to the laws of planetary motion (as mentioned in the article). But one really inspiring thing about Kepler is not mentioned there is that he started with a different theory and then changed his mind when the observational data showed he was wrong. We have the laws of planetary motion because of a feat of tremendous intellectual humility where a really smart person was prepared to admit that the theory they had invested a huge amount of time and effort into formulating didn’t match the observational data, _so they changed their mind_.
Kepler’s original theory was that the orbits in the solar system were defined by polygons and their inscribed/circumscribed spheres. This seemed very attractive because at that time they knew of 6 planetary bodies and this fitted in somehow (I don’t remember exactly) into this model with nested platonic solids and the spheres around them. Then Kepler realised that the predictions of this very elegant model were worse than the heliocentric model.
So when Brahe’s observations became available he basically threw all that out and started again, to develop his wonderfully elegant laws of planetary motion based around elliptical orbits which also have the significant benefits of predicting planetary motion beautifully and were later found to be entirely derivable from Newton’s laws of motion using calculus (there is a wonderful presentation of this derivation in Spivak for anyone who is interested).
I have a faster solution for N-body gravity with orbital resonance that predicts the perihelion of Mercury than gravity from QED scattering, with Gr_C(2,4) in Lean 4 and Rust/WASM that I haven't yet published.
I noticed "Kepler" in the title and cool story about Kepler so now I'm mentioning it;
"Grassmannian Gravity from QED & Gauge Scattering Amplitudes: Complex Gr_C(2,4) Orbital Precession, Mercury's Perihelion, N-Body Dynamics, and Dilatant Dark Fluid (DDF) Unification in Lean 4" (2026)
westurner/sustainablefactory/docs/grassmannian-gravity-from-qed-scattering-paper.md at main · westurner/sustainablefactory https://github.com/westurner/sustainablefactory/blob/main/do... :
> An arXiv-ready formal verification paper deriving planetary orbits, Mercury's 42.98 arcsec/century perihelion precession, and N-body gravitational dynamics from flat-space QED/gauge scattering amplitudes, BCJ double copy on Gr_C(2,4), and Dilatant Dark Fluid (DDF) hydrodynamics in Lean
There's already gravity that fits the Perihelion of Mercury from QED scattering (Partanen, M., and Tulkki, J. (2025). "Gravity Generated by Four One-Dimensional Unitary Gauge Symmetries and the Standard Model" / "Perihelion Precession of Planetary Orbits Solved from Quantum Field Theory"). FWIU, I've here contributed the use of Grassmanian Plückers and a Complex Grassmannian - GrC(2,4) both with and without connections to DDF Dilatant Dark Fluid (Fedi).
I had created a simple particle wave visualization tool with 3js and then on a whim AI-added a double slit and a detector screen, and I asked for Huygens-Steiner Parallel-Axis Intensity as the model to simulate superposition because of [Qian and Izadi] and then I had to keep working on that instead. First the model differencing in the simulator in JS to compare the difference in model predictions in the double-slit experiment against Pilot Wave Theory and Wigner function and then with Fraunhofer and Lean 4 and Rust and a crisp symbolic error term for each model of photonic and electronic superposition. It looks like GrC(2,4) is the most efficient model for photonic and electronic superposition, too.
"Huygens–Steiner Barycentric Coherence, Complex Gr_C(2,4) Plücker Channels, and Multi-Model Double-Slit & OAM Relative Predictive Error in Lean 4" (2026)
> An arXiv-ready formal verification paper uniting Qian–Izadi Huygens–Steiner parallel-axis coherence, complex Gr_C(2,4) Plücker double-slit interference, de Broglie–Bohm pilot-wave hydrodynamics, Wigner phase-space marginals, and Orbital Angular Momentum (OAM) relative predictive error in Lean
Useful to create a devcontainer with lean4 and rust. Still working through verifying the URLs of each citation to publish some of this paper series per the latest terms for AI articles.
The first line was intriguing but the rest of it is a mishmash of buzzwords and handwaving. It looks like you are bidding for consideration of a grand unified theory, and that's great, I am one of the people that enjoys considering new proposals that unify or align previously disconnected areas of physics or mathematics.
But even though I understood (most of) the individual assertions you are trying to cram into your abstract-of-an-abstract, showing which things you are combining, how you are combining them,and how you are keeping reproducibility and provability as your top priorities, the effect of trying to communicate so many data points at once comes off as earnest but incoherent, like a bus-stop conversation with a schizophrenic.
Ideas are not self-propagating. If you just want to feed your thoughts back into other AIs in a way that lets provide useful input toward an intellectual singularity, publish it on your own blog. If you are publishing it in a social space, take some time to articulate in plain language what you think you've found, why it's important, and why other people might find it worthwhile to invest some time in wrapping their heads around it. If that seems too vague go read some Quanta articles and ponder why they read a wider audience than hyper-technical abstracts in math journals.
I'm not finding this feedback to be helpful. I wish you luck with your own approach.
> incoherent, like a bus-stop conversation with a schizophrenic.
This is impolite and disrespectful. Do you have code or math to contribute? What tools could you use to interpret for example this the first sentence of my post?
> I have a faster solution for N-body gravity with orbital resonance that predicts the perihelion of Mercury than gravity from QED scattering, with Gr_C(2,4) in Lean 4 and Rust/WASM that I haven't yet published
I also found your post lacked coherence, but I agree GP’s feedback is delivered a bit harshly
- the way you jump right in is kind of off topic with tons of details, your connecting sentence about Kepler would have been better framing context to lead with (but it also needs revision because it reads like you’re elbowing into the conversation)
- HN is a general (technical) audience, your opening statement and the rest of your post assumes a lot of specialized knowledge. It needs some scaffolding and some distillation for a broad audience to understand what’s important about what you did
- that opening sentence isn’t grammatical? Your solution is faster than some quantum theory of gravity? Or maybe you missed a word and mean it’s more accurate than QED? And it’s a theory of gravity that predicts orbital resonance?
- you’re mixing conceptual and implementation details with the effect of information overload. Is the interesting part the theory of gravitation or the fact that you used Rust and WASM? I would lead with the scientific part, then add a separate sentence on the computational tools you used so they both get the focus they deserve
- the rest of your post is long and kind of alternates between what looks like pasted autogenerated link summaries, jargon-filled descriptions of the research, and some descriptions of visualization tools that don’t clearly connect (to someone without expertise in this field) to the rest of the post
- there’s a flood of crap science being cranked out with agents. Maybe your project is not one of these, but you’re fighting an uphill battle against everyone’s heuristics to filter out the noise. If you want to be engaging you have to distill, clarify, and adapt to your audience
I think (looking also at his website) that he is trying to make some sort of honeypot for agents. The lean code is completely nonsensical- tons of broken latex, dense references in the docstrings and the proofs are all very long names to obscure the fact that there’s nothing there. All they do is instantiate structures with lots of arguments and then assert one of the arguments.
I don't hate AI preprints, I hate slop grenades, which is what this is. Either you did that on purpose (which was what I thought looking at your website - that you created a honeypot to trap agents) or you don't realise that's what you're doing, in which case this makes me very sad.
It's tragic that you spend time harassing and diminishing about your subjective aesthetic response instead of learning to check the machine-checkable proofs using the tools.
Test coverage in Lean might be a good feature to contribute.
It's justified to mention GrC(2,4) for modeling orbital gravity here because the OP's (and Kepler's) methods will not ever derive the scattering amplitude basis for gravity or the Grassmannian geometric manifold for calculating the 1-loop scattering because of algorithmic insufficiency at the universal function approximation problem.
What I took the time to share here saves many years of false starts at modeling gravity; which - ironically - Kepler's doesn't sufficiently model either.
A question to research:
What's wrong with Keplerian gravity?
GrC(2,4) is probably more efficient than for example how NASA SPICE toolkit models gravity rivers.
For some reason I’m not allowed to respond to the child comment so I’m putting this here:
Perl 5 was released in 1994. Palo Alto Networks was founded in 2005, so Perl 5 was certainly available when they built their first products and would have been a superior choice to either PHP or Perl 4.
The difficult part isn't rendering the UI, it's the work that's done between the UI and the back end components/services that's difficult. PHP is used for more than just web pages.
My last comment on this: it is not "one URL" or "just configuration pages", it is an entire application, it does not have distinct "pages" that can be replaced with something written in a different programming language.
You can always take a look at the UI of a PAN device and use your browser in developer mode to see how it works and understand the concept of a web application.
> You can always take a look at the UI of a PAN device
I do not have a PAN device.
> it is not "one URL"
I never implied it was.
> it is an entire application, it does not have distinct "pages"
> the concept of a web application
Those are usually written in javascript and the client part could stay the same. If anything that kind of design makes it easier to replace the backend one URL at a time becasue the responses from the backend are simpler.
If they have something where the UI state is kept on the server and is relayed to the browser, that would be difficult to do anything with. But that's an especially terrible design that causes other problems, so if you're accusing them of having a design that bad please be explicit.
There are some (typically small) simplifications that computers are indeed good at. These could be thought of as analogous to compiler optimizations - they’ll see that your proof is basically composing several lemmas and that some of the work in the middle can be removed so it can just do that. In many cases with lean if you post a short to medium-length proof into an llm it can suggest these types of small improvements for you.
What they’re not that great at is the type of improvements that really make a big difference: big simplifications etc. This is not super suprising when you understand how this works.
Firstly proofs in lean (and I think many other assistants) are essentially functions which take hypotheses and instantiate a particular type. That type being equivalent (due to the Curry-Howard correspondence) to a proof of some proposition. The assistant uses dependent type theory to make sure all the types match up at each step, which is what makes it rigorous. So the task of simplifying a proof is basically finding a route through an infinite-dimensional space where you know your starting location and the desired end point, but at any step you can go in basically any direction you like so long as you can justify your step. You justify a step by either choosing from a (vast at this point) library of lemmas and theorems that are in your standard library, or by recursively building the proof/function you need to justify the step you want to take using this same process you’re trying to use for simplification. This is incredibly flexible, but means you’re actually spoiled for choice and planning is hard.
Secondly, in “pen and paper” proofs, LLMs don’t know the difference between steps which are important/easy/hard/intuitive/non-intuitive for human mathematicians, so lots of the proofs they produce are extremely clunky and pedantic in places and dwell for ages over details that are obvious and would usually be skipped over and then will move very fast through things that justify more attention. This unevenness is part of what makes their proofs hard for humans to work through, but also means they are generally poor judges of what would actually constitute a decent simplification.
It’s not an exciting advancement if it’s just the AI equivalent of google wave. It’s totally reasonable to be skeptical of marketing and want to try something for yourself.
Google wave was eventually released to the public but initially it required an invitation. So if you had a friend at google you could get in but if not you were out of luck. This killed early momentum and when they eventually opened up the product was dead on arrival.
I think there are a lot of practical applications where something that works few-shot and doesn't require training is quite appealing if the cost of inference is low. That's the sweet spot for Jev and similar models. If you have time and an eval set to train it, clearly a "real" special-purpose classifier should have much better performance (and for most applications cheaper cost/faster inference), but Jev and friends are way better than using a full-fat transformer LLM for a classification task.
As an example, I've been using winnow running locally as a decision model in openchamber to select between llms for doing various tasks. I don't have an eval set of different coding and other tasks that I could use to train a proper classifier. This I just download off huggingface and it works out of the box and has cut my token spend to a fraction of what it was. So it's good enough to be beneficial.
As an aside, the professor in question is Richard Borcherds, fields medalist. He is probably most well known for proving the “Monstrous Moonshine” conjecture of Conway and Norton that there is some sort of correspondence between modular functions and representations of the Monster Group. When the conjecture was made in the 1970s, it was purely because someone noticed that a certain number was the same as the cardinality of the monster group. It seemed a crazy coincidence, so John H Conway said (playfully) that it was “Moonshine”. Hence the name “Monstrous Moonshine”.
> the professor in question is Johnny Doe, with access to 100+ unrestricted Mythos agents
Yet the folks with access to unrestricted Mythos agents tackling mathematics are hiring credentialed mathematicians. Your heuristic, applied to itself, rejects itself.
We’re a long way from that world. Does your company even interview people who don’t fit the requirements of a job position? No, of course not. So what are you filtering on, if not credentials.
This guy doesn’t just have credentials. He has record of proven results.
To understand the regulatory framework for banks, the best place to start is the BIS and Basel III. https://www.bis.org/committees/bcbs/standards Generally speaking, international banks follow Basel III in addition to their domestic regulators’ capital requirements (which are probably also derived from Basel III, but have differences just to make things tedious).
reply