MITSardine

Some of the defects are attributable to the critical:

> AI models generate meshes using "isosurface extraction" or similar volume-to-mesh techniques

This creates the "lumpiness", the inability to capture sharp or flat features, and the over-refinement. Noisy surface is also harder to clean up. How do you define what's a feature and what's noise when there's no ground truth beyond the mesh itself?

Implicit surface methods are expensive (versus if-everything-goes-right of the parametric alternative), but they have the advantage of being robust and simple to implement with much fewer moving parts. So it's a pragmatic choice, why not.

3D generative algorithms might become much better once they can rely on parametric surfaces. Then you can do things like symmetry, flatness, curvature that makes sense, much more naturally. And the mesh generation on top will produce very clean meshes, if it succeeds. That is a crucial missing piece: CAD to mesh is hardly robust with human-generated CAD, so I can't imagine what it'd be with AI-generated CAD. An interesting challenge to be sure.

Yes, what's preventing the LLM from running myCommand > /tmp/out_someHash.txt ; tail out_someHash.txt and then greping or tailing around /tmp/out_someHash.txt on failure?

I'm only discovering Literate Programming today, but you seem very familiar so I might as well ask: what is the fundamental difference with abundant comments? Is it the linearity of it? I mean documentation type comments at the top of routines or at "checkpoints".

I'm particularly intrigued by your mention of keeping old code around. This is something I haven't found a solution for using git yet; I don't want to pollute the monorepo with "routine_old()"s but, at the same time, I'd like to keep track of why things changed (could be a benchmark).

With LLMs this fast, you could imagine using them as any old function in programs.

The Portuguese sometimes describe themselves as the "povo de brandos costumes" (people of mild customs).

To be fair, a lot of science doesn't follow the scientific method. I've yet to see an applied mathematician (to speak only of what I know) come up with a hypothesis, it's usually rather: here's how people solve this problem currently, this has this and that drawback, and our paper introduces a new method that solves bigger problems faster/new classes of problems.

The same could be said of theoretical work: here, we tightened up an inequality.

This is also research, not all of it is experimental!

An issue with that, especially now that they might go to LLMs for bibliography / exploratory work rather than google or a library, is that they may be exposed to the solution before even really tackling the problem.

Maybe that's fine, but it seems to me like it spoils the fun.

I'm not sure I understand what you're getting at. Public speaking is itself a skill that the teacher presumably wanted to teach their students. These types of assignments are also quicker to grade (and on class time, no less) and harder to cheat at than written exams: - students copying on their neighbor - students using their smartphone in class or in the restroom - old-school cheats (cheat sheets hidden on their person)

Even disregarding cheating, why should ability at written exams be the only measure of a student? Some crumble under the pressure of the moment and perform poorly as their mind blanks. They don't trust their abilities and find themselves terrified in front of an exam sheet. Having time to research a subject and carefully rehearse it can be reassuring. Others (as was my case) have the opposite problem; they trust themselves fully to improvise their way to a good grade in front of a sheet of paper but freeze up if they have to speak in front of a crowd. But these students already get their way in the 99% of evaluations that are not in this format.

I wonder if some of these could be embedded in the write tool calls?

Well, you still need time (and permission from your employer)! Research is usually a more than full time job on its own.

I find it surprising. The piece of code I'm working on is about 10k LoC to define the basic structures and functionality and I found Claude Code would systematically spend significant time and tokens exploring it to add even basic functionality. Part of the issue is this deals with a problem domain LLMs don't seem to be very well trained on, so they have to take it all in, they don't seem to know what to look for in advance.

I went through a couple of iterations of the CLAUDE.md file, first describing the problem domain and library intent (that helped target search better as it had keywords to go by; note a domain-trained human would know these in advance from the three words that comprise the library folder name) and finally adding a concise per-function doc of all the most frequently used bits. I find I can launch CC on a simple task now, without it spending minutes reading the codebase before getting started.

Hell even my young brain got tired on statistics and algebra. Could part of this also be field mismatch?

Setting the framework (what I short-handed by "definitions") precludes the exploration of results (or at least an efficient one) that would yield to some framework-defining analysis.

The search space is much too rich to be explored anything but greedily in timid steps off the trodden path, and the frameworks (arbitrary) set both the highways and the vehicles by which we move along and out of them.

Now, the argument can be made that the "meta-mathematical" (but outright mathematical, really) setting of frameworks follows the same structure, and LLMs could also explore that space.

Even assuming that, a major roadblock remains: mathematics should remain understandable by humans, and yield fast progress in desirable (by whom? until now, by humans) directions, so the constraints on admissible frameworks are not as simple as "yields to coherent results".

Also, to take a step back, I wonder what the pertinence of using numerical math is to derive analytical math when we can already solve a great deal of problems through numerical methods. For instance, is it worth spending however many MWh on LLMs to derive an analytical solution to an optimization problem, which might itself be very expensive to compute (human-derived expressions tend to be particularly cheap to evaluate precisely because we are so limited; machines (formal calculus for instance) will happily give you multi-page formulae with thousands of operations to evaluate), when there's a vast array of algorithms at the ready to provide arbitrarily precise solutions?

What remains is the kind of math that, arguably, is much more precious to understand than to derive.

LLMs can write theorems, but can they come up with meaningful definitions?

There's a major difference between chess and scientific research: setting the objectives is itself part of the work.

In chess, there's a clear goal: beat the game according to this set of unambiguous rules.

In science, the goals are much more diffuse, and setting those in the first place is what makes a scientist more or less successful, not so much technical ability. It's a very hierarchical field where permanent researchers direct staff (postdocs, research scientists/engineers), direct grad students. And it's at the bottom of the pyramid where the technical ability is the most relevant/rewarded.

Research is very much a social game, and I think replacing it with something run by LLMs (or other automatic process) is much more than a technical challenge.

I'm a bit puzzled because this seems backwards from what I thought had been the evolution of things.

Didn't companies historically own their own compute? And then started offloading to so-called cloud providers? I thought this was a cost-cutting measure/entry/temporary solution.

Or is this targeting a scale well beyond the typical HPC cluster (few dozen to few hundred nodes)? I ask because those are found in most engineering companies as far as I know (that do serious numerical work) as well as labs or universities (that can't afford the engineers and technicians companies can).

Also, what is the meaning of calling an on-prem machine "cloud" anymore? I thought the whole point of the cloud was that the hardware had been abstracted (and moved) away and you just got resources on demand over the network. Basically I don't understand what they're selling if it's not what people already call clusters. And then if the machine is designed, set up and maintained by a third party, why even go through the hassle of hosting it physically, and not rent out the compute?

How do you know you haven't unknowingly broken something when you made a change?

I think if: - the code base implements many code paths depending on options and user inputs and options such that a fix for code path A may break code path B - it takes a great deal of time to run in production such that issues may only be caught weeks or months down the line when it becomes difficult to pinpoint their cause (not all software is real-time or web) - any given developer does not have it all in their head such that they can anticipate issues codebase wide

then it becomes useful to have (automated) testing that checks a change in function A didn't break functionality in function B that relies on A in some way(s), that are just thorough enough that they catch edge cases, but don't take prod levels of resources to run.

Now I agree some things might not need testing beyond implementation. Things that don't depend on other program behavior, or that check their inputs thoroughly, and are never touched again once merged, don't really justify keeping unit tests around. But I'm not sure these are ever guarantees (especially the never touched again).

Numerical simulation is a well explored field, we know how to do all sorts of things, the issues lie rather in the tooling and robustness of it all put together (from geometry to numerical results) than in conceptual barriers. Finite Differences have existed since the 1700's! What hadn't for the longest time, is the computational power to crunch billions of operations per simulation.

A nice thing about numerical simulation from first principles, is it innately supports arbitrary speed/precision, that's in fact the backbone of the mathematical analysis for why it works.

In some cases, as is the case for CFD, we're actually mathematically screwed because you just have to resolve the small scales to get the macro dynamics. So the standard remains a kind of hack, which is to introduce additional equations (turbulence models) that steer the dynamics in place of the small (unresolved) scales. We know how to do better though (DNS), but it costs an arm and a leg (like years to milenia on a super computer).

It's just the name, BREP stands for Boundary REPresentation.

I can't help but find this comment a little insulting. It's very similar to saying "if, while, else, malloc. The LLM can figure the rest out!" as if CS were a solved thing and the whole challenge weren't assembling those elementary bricks together in computationally efficient and robust ways.

Also more to the point, I doubt you'll have much success with local optimization on general surfaces if you don't have some kind of tessellation or other spacial structure to globalize that a bit, because you can very easily get stuck in local optima even while doing something as trivial as projecting a point onto a surface. Think of anything that "folds", like a U-shape, a point can be very close to one of the branches, but Newton might still find it on the other side if you seeded the optimizer closer to there. It doesn't matter whether you use vanilla Newton or Newton with tricks up to the gills. And anything to do with matrices will only help with local work as well because, well, these are non-linear things.

"Just work in parameter space" is hardly a solution either, considering many mappings encountered in BREPs are outright degenerate in places or stretch the limits floating point stability. And the same issue with local minima will arise, even though the domain is now convex.

So I might even reduce your list to: Taylor expansion, linear solver. You probably don't need much more than that, the difficulty is everything else you're not thinking of.

And remember, this has to be fast, perfectly robust, and commit error under specified tolerance (ideally, something most CAD shops don't even promise).

I should have shared this more recent page directly on the manual with examples to begin with: https://flexcompute.github.io/EngineeringSketchPad/EngSketch...

If anyone is interested, you can try EngineeringSketchPad (https://acdl.mit.edu/ESP/) which is very similar but much more mature. It also supports simple geometric primitives and boolean operations via a scripting language, but also more general rational curves and surfaces (i.e. BREPs). It has other nice features like differentiation, application-specific views (think structural vs CFD), and an attention to water-tightness/correctness.

I have a terrible memory for details, I'll admit an LLM I can just tell "Find that paper by X's group on Method That Does This And That" and finds me the paper is enticing. I say this because I abandoned Zotero once the list of refs became large enough that I could never find anything quickly.

Speaking of conferences, might this not be the way to judge this work? You could imagine only orally defended work to be publishable, or at least have the prestige of vetting, in a bit of an old-school science revival.

If I may be the Devil's advocate, I'm not sure I fully agree with "The hard part always has been, and always will be, understanding the research context (what's been published before) and producing novel and interesting work (the underlying research)".

Plenty of researchers hate writing and will only do it at gunpoint. Or rather, delegate it all to their underlings.

I don't see an issue with generative writing in principle. The Devil is in the details, but I don't see this as much different from "hey grad student, write me this paper". And generative writing already exists as copy-paste, which makes up like 90% of any random paper given the incrementality of it all.

I was initially a little indignated by the "find me some plausible refs and stick them in the paper" section of the video but, then again, isn't this what most people already do? Just copy-paste the background refs from the colleague's last paper introduction and maybe add one from a talk they saw in the meantime, plus whatever the group & friends produced since then.

My experience is most likely skewed (as all are), but I haven't met a permanent researcher that wrote their own papers yet, and most grad students and postdocs hate writing. Literally the only times I saw someone motivated to write papers (in a masochistic way) were just before applying to a permanent position or while wrapping up their PhD.

Onto your point, though, I agree this is somewhat worrisome in that, by reaction, the barrier to entry might rise by way of discriminating based on credentials.

LaTeX is already standard in fields that have math notation, perhaps others as well. I guess the promise is that "formatting is automatic" (asterisk), so its popularity probably extends beyond math-heavy disciplines.

The representation might not need to explicitly encode "meaning", if it does so implicitly by preserving essential properties of how things relate to each other.

For instance, a CAD object has no notion of what an airplane wing or car wheel are, but it can represent those in a way that how a wing relates to a fuselage is captured in numerical simulations. This is because it doesn't mangle the geometry the user wanted to represent ("what it means", in a geometric sense), although it does make it differ in certain ways that are "meaningless" (e.g. spurious small features, errors under tolerances), much like this representation might do with words.

Back to words, how do you define meaning anyways? I believe I was taught what words "mean" by having objects pointed to as a word was repeated: "cat", says the the parent as they point to a cat, "bird", as they point to a bird. Isn't this also equality/correspondence by relative frequency?

Are meshes not used instead of gaussian splats only due to robustness reasons? I.e., if there were a piece of software that could reliably turn a colored point cloud into a textured mesh, would that be preferable?

But isn't this what the author is doing already? That's what I got from the video. SDF is sampled on a sparse grid (only cells that cross the level set 0) and then values are sampled by interpolating on the grid rather than full reevaluation.

One possibility, a little backwards maybe, is to produce a discrete SDF from e.g. a mesh, by inserting it in an octree. The caching becomes the SDF itself, basically. This would let rendering be done via the SDF, but other logic could use the mesh (or other spatial data structure).

Or could the engine treat animated objects as traditional meshed objects (both rendering and interactions)? The author says all physics is done with meshes, so such objects could still interact with the game world seemingly easily. I imagine this would be limited to characters and such. I think they would look terrible using interpolation on a fixed grid anyways as a rotation would move the geometry around slightly, making these objects appear "blurry" in motion.