Oh, come on, if they do well on benchmarks people question how applicable they are in reality. If they do well in reality people complain that it's not a reproducible benchmark...
What do you mean? Is the non-existent millionth floor of the Empire State Building still part of the Empire State Building?
Also, I'm assuming we're in agreement that software should not accept invalid GPS coordinates from untrusted peers regardless of semantics about whether or not they're within Earth's bounds.
Conversely, I often find coding agents privileging the existing code when they could do a much better job if they changed it to suit the new requirement.
I guess it comes down to how ossified you want your existing code to be.
If it's a big production application that's been running for decades then you probably want the minimum possible change.
If you're just experimenting with stuff and the project didn't exist at all 3 days ago then you want the agent to make it better rather than leave it alone.
Probably they just need to learn to calibrate themselves better to the project context.
The tradeoff is highly contextual; it's not a tradeoff an agent can always make by inspecting the project themselves.
Even within the same project, for a given PR, there are some parts of the codebase I want to modify freely and some that I want fixed to reduce the diff and testing scope.
I try to explain up-front to the agent how aggressively they can modify the existing code and which parts, but I've had mixed success; usually they bias towards a minimal diff even if that means duplication or abusing some abstractions. If anyone has had better success, I'd love to hear your approach.
Just brainstorming, but perhaps a more tangible gradient, with social backpressure?
Imagine three identical patch tools: "patch", "submit patch", and "send patch to chief architect and wait". With the "where each can be used" explained or even enforced. Having the contrast of less-aggressive options, might make it easier to encourage more aggressive refactoring elsewhere. Or pushing the impact further up the CoT, "patch'ing X requires an analysis field describing less invasive alternatives and their un/suitability; for Y, just do it, refactor aggressively".
To get the agent to think for itself sometimes it feels like I have to delete a bunch of code and markdown first. Instruction to refactor/reconsider broadly has such mild success, I find.
I'll literally run an agent & tell it to clean up a markdown file that has too much design in it, delete the technical material, and/or delete key implementations/interfaces in the source, then tell a new session to do the work, come up with the design. (Then undelete and reconcile with less naive sessions.)
Path dependence is so strong. Right now I do this flow manually but I would very much like to codify this, make a skill for this pattern that serves so well.
So, the typical "It's only okay when the elites do it." Although, it's almost certain that such crowdfunding practices will lead to a radical democratization of society as a whole.
Today, any bloody dictator, tyrant, or autocrat continues to kill people en masse simply because society lacks a sufficiently effective tool to guarantee the reliable transfer of funds to one of their henchmen should the issue with him be effectively resolved
EDIT: Oh, I initially thought that you thought that I was saying that it's OK for the government to coordinate assassinations but not OK for other people to coordinate assassinations. Which is not what I said, I only said (implied) that it's not OK for other people to coordinate assassinations. I made no representation regarding whether I think it's OK for the government to coordinate assassinations.
However, what I now think you're saying is that assassination markets would lead to fewer assassinations rather than more, because... if ordinary people could trade in assassination markets then they would choose to assassinate the government's assassins, and then the government would not react or respond in any way, so then the government would no longer be able to coordinate assassinations, and the general public would stop using the assassination market, and then the problem is solved. Is that right?
> you thought that I was saying that it's OK for the government to coordinate assassinations
Oh no, I think you misunderstood. I'm not saying you think this is acceptable. I'm saying the elites are ALREADY doing it. And you're expressing your extreme disapproval not of the phenomenon itself, but of the hypothetical situation in which not only the elites but also ordinary people would gain access to such tools (which, of course, would also be very illegal and unacceptable. Well, until these terms still exist).
> I now think you're saying is that assassination markets would lead to fewer assassinations rather than more
I think we are rather talking about an increase in the number of assassinations to a level that literally threatens the destruction of human civilization in its modern form. Purely because of the irreversible nature of this tool acquisition by society. It's just that at one point in time, society doesn't yet have access to it, and at another, it has, and now it's everywhere, for everyone, and there's no turning back. The entire planet is living in a new socio-political-economic reality.
But this does not in any way contradict the radical democratization of society.
Only if it becomes obvious why it is flaky. If it's just sometimes broken but really hard to reproduce then it just gets piled on to the background level of flakiness and never gets fixed.
To get around this, I have it log the relevant inputs, so it can be reproduced.
The whole concept of allowing a flaky unit test to exist is wild and dangerous to me. It makes a culture of ignoring real failures in what, should be, deterministic code.
Well, if people can't reproduce the failures, people won't fix them.
So, yes, logging the inputs is extremely important. So is minimizing any IO dependency in your tests.
But then that runs against another important rule, that integration tests should test the entire system, IO included. So, your error handling must always log very clearly the cause of any IO error it finds.
I was working on an SDF-based CAD tool but gave up when I couldn't find a good way to do fillets.
It's very deceptive because the easy way works so well (Use smoothmin instead of min and you get smooth blends for free! You can even use a circular approximation of smoothmin and get proper fillets!). But when you want the user to be able to pick a couple of surfaces and fillet between them, it gets really hard.
It worked by rewriting the expression tree so that the blend arguments become sibling nodes and then applying the blend to the union/intersection that is their parent.
That works every time if you only want 1 single targeted blend, but if you want several of them then you can run into unsatisfiable cases where the same object needs to blended with several others and can't be siblings of all of them.
So I gave up :(. For me, CAD without fillets and chamfers is no CAD at all.
(Also, apropos for this thread: the discontinuity in the chamfer was a floating point precision problem...)
Well, user picking a couple of surfaces is literally an operation on a boundary representation, so of course it's a PITA with fields :)
I think the future is CAD is combined fields and breps. They're literally dual, one is covariant, the other contravariant (breps facilitate pushforwards, fields facilitate pullbacks).
One without the other is necessarily going to be limited in some way.
The distance field tells you the distance to the nearest surface at any point. You can have a "surface id field" tell you the id of the nearest surface to any point, and then when you raymarch to find the intersection of a line with a surface, you can read out the ID from the ID field after finding the intersection point. (Of course the ID field is also implemented as a function mapping points to surfaces).
So when the mouse is hovered or clicked in the 3d view you can easily find the ID of the surface under the pointer, and you can draw that surface in a different colour to show it is selected. No boundary representation needed.
The hard part is, given 2 surface ids, how do you add a fillet between them in the general case?
Another idea I had was to set the fillet radius on every min/max node based on the derived surface id's from the child nodes, but I couldn't find a good way to do this without making the field discontinuous.
That depends on what we mean by surfaces, and in the case of filleting, the user really wants to be picking adjacent faces (as in: an edge between two adjacent faces). That, or even a region to roll a ball along to generate a fillet.
The semantics of fillets even in the simplest case is that it's doing something to the edges, i.e. elements of the boundary representation, so that's a more natural structure for filleting.
>The distance field tells you the distance to the nearest surface at any point.
What you're describing isn't the same. You really are picking solids, not faces.
This wouldn't work even in the simplest case of a cube.
You can define a cube by a distance field:
f(x, y, z) = max(|x|, |y|, |z|) - 1
If the user wants to fillet just one the edges, then what? You only have one surface (the boundary of a cube), and one ID.
The field doesn't know anything about the edges.
OK, OK, we can ignore this edge case (badum-tss), but even if you only allow filleting "two surfaces", those two "surfaces" (really: boundaries of solids) aren't necessarily going to intersect along one edge (which is what the user wants to fillet).
The intersection may have multiple components. Or may not be manifold.
As a concrete example:
f(x, y, z) = z - cos(x)
g(x, y, z) = z - cos(y)
Look ma, no absolute values! Let me smooth-talk a little though:
f(x, y, z) = z - cos(x)cos(y)
g(x, y, z) = z - 0.25
.....and that's before we get to the reality where the user's understanding of "edge" isn't topological (as in, component of intersection between surfaces), but geometric (sharp corners).
B-reps can get away with making no distinction between them... Until you have messy geometry from elsewhere.
Say, an STL file from a scan. Or a mesh that came from an F-rep by marching cubes. Or whatever unholy mess OpenSCAD can cook with CGAL.
It doesn't matter if you use F-rep or convert to one: chisel out a cube as an intersection of half-spaces, then cut with half-spaces that narrowly touch the edges.
It'll look like a cube, and it'll be a cube functionally if you manufacture it.
Good luck with that one.
>If you have good ideas for this I'd love to hear them and resume working on Isoform
Well. The good news is that putting fillets on every edge is kind of easy with fields because you can do it with offsets.
If F(x, y, z) is a distance field that defines a solid, G(x, y, z) = F(x, y, z) + c offsets F inwards by c.
G is not a distance field anymore though, it's giving values that arent distances on the outside of convex corners.
Renormalize G to be a distance field, call it G'.
Now offset G' outwards by c: H = G' - c.
Ta-da! Concave corners aren't touched, convex corners are rounded.
Flip the + and -, and you're filleting concave corners (G = F - c is a field that defines an outwards offset that fails to be a distance field inside the body near concave corners; compute G' — the distance field for G; offset G inwards: H = G' + c).
Now, the "just normalize a field into a distance field" is doing a lot of heavy lifting here.
It works in the case of a cube if you define the cube to be the intersection of 6 half-spaces. There is a video demonstration of it working (partly) on a cube defined this way in the YouTube link in my comment above.
I define a surface to be the region of space where a particular SDF evaluates to 0. You define a solid to be the region of space where that SDF evaluates to <0, but they're broadly the same concept.
It is no problem to ensure that all primitives & all extruded sketches are defined so that each face gets a different surface id, and you would of course want to do this if you want to be able to fillet them.
You're right that there is a difference between an edge and between a pair of surfaces, but finding edges in SDFs is much harder than finding pairs of surfaces. If they intersect along more than one edge then you'll get the fillet along more than one edge. SDFs don't even have concrete "edges" in the general case. I'm not worried about this. Being able to fillet the intersection of 2 surfaces (solids) would satisfy me, but I haven't even got that far.
I'm not trying to find a solution that involves treating edges as "special". That's B-rep thinking. I don't mind if a "fillet" between 2 surfaces that do not touch but are closer together than the fillet radius creates a bridge between them, as long as it is smooth, continuous, and predictable.
It doesn't have to approximate the B-rep way, it just needs to be practically useful for turning sharp edges into rounded ones in a way that lets the user decide where.
reply