aconz2

summary: given a program template/skeleton and a fitness function (# correct results, shorter programs, etc), generate a population of programs with LLM, use a prompt that generates a new program from k other versions (they found k=2 is good, kinda biological eh), run the programs on inputs and score them with the fitness function, uses the island model for evolution

I think the prompt looks in principle something like

  def foo_v1(a, b): ...
  def foo_v2(a, b): ...
  # generate me a new function using foo_v1 and foo_v2. You can only change things inside two double curly braces like THIS in {{ THIS }}
  # idk not a "prompt engineer"
  def foo(a, b): return a + {{}}

They achieved the new results with only ~1e6 LLM calls (I think I'm reading that right) which seems impressively low. They talk about evaluating/scoring taking minutes. Interesting to think about the depth vs breadth tradeoff here which is tied to the latency vs throughput of scoring an individual vs population. What if you memoize across all programs. Can you keep the loss function multidimensional (1d per input or input bucket) so that you might find a population of programs that do well in different areas first and then it can work on combining them.

Did we have any prior on how rare the cap set thing is? Had there been previous computational efforts at this to no avail? Cool nonetheless

Yes, but most numbers I've seen on nozzle size / kerf size are too big by a factor of 2. In the worst-ish case for a cutting process that cuts a pill shape (rectangle with semicircle ends from a translating circular cut) by plunging in from the edge, my total tooth height is 0.3mm so if I aim for 0.1mm of flat, then that leaves 0.2mm of radius == 0.4mm kerf. Most typical numbers I've seen are more like 0.9mm and the Wazer for example is 1.2mm.

Maybe worth another look though to see if there are more specialized machines. The thickness & total amount of material I'm removing is nothing so maybe there's something out there

Oops, thanks for the catch. That is just a typo though, so the following price is still correct (500 * $0.25 == $125). Retail price per blade is $0.20 - $0.25.

I've thought about the price premium and think it could go either way. The blades from at least one manufacturer are already produced from a single ribbon before being separated, so the process to produce longer blades shouldn't be too different (hopefully!). And if there's a 2x premium, that's fine, if its closer to 10x I would re-evaluate.

Around 50 blades per month for the first year

Based on retail price of the existing blades (50 x 100mm blades == 1 x 50m blade) puts it around $125. If they make them for ~25% of that, each blade is ~$30. Though I anticipate a higher cost to develop the process if necessary.

I've come across those in my searching before, they are very cool! There is a guy on YT that did a CNC wire cutter for cutting sculptures out of big blocks of granite.

For my application (wooden puzzles), the kerf is essential to be ~0.2mm so I can't use this. The 50m blade length won't be all in one stretch, it is unwound off a spool and wound onto another; though that is a great/funny sight to imagine

Idk, not a welding expert, maybe you're trying to tell me it is a-okay? What about the heat affected zone? What welding process are you thinking?

> Any particular reason the reciprocating action of a normal scroll saw doesn't work for your application?

It works... just not well. Reciprocating is only 50% time efficient (only cutting on the down stroke!), wears out the blades by rubbing on the up stroke, and the very small length wears out quickly so they have to get changed often

Yep! Easy to specify, hard to do!

I did contact some band-saw blade makers and the smaller dimensions I'm looking for are a different ball-game for them for so I only got "sorry, no can do" answers.

Responded to another welding comment, I am pretty sure its a no-go, but thanks for the thought!

> Is this a one-off/prototype-type project?

It is a prototype but I'd be looking for ~10 blades to start and then 100+ from there

Thanks for the thoughts!

> Can an equivalent length of available-size blades be welded together (maybe trimming the ends first, if they lack teeth)?

I don't think so, these blades are very narrow and thin -- 0.2mm x 0.3mm cross section at the spine -- and I'm pretty sure a weld would not hold and if it did, you'd still have to grind it down flush. And I'd guess the joint would also fatigue which is an issue since the blade needs to get wound/unwound repeatedly during cutting. Also, I think the heat of the weld would probably effect the already hardened steel.

> I wonder what the required blade tension would be

The tension on existing scroll saws is 10 - 20 lbs for blades of this size.

> how machine will maintain tension on the blade

The blade gets unwound off a spool which maintains the tension through a torque motor.

> I wonder why the blade needs to be so long.

Minimum usable length is ~10m, but I figure if you can make 10, you can make 50. The longer the blade, the longer you can cut before you have to rewind. And the longer the blade lasts before the teeth are dull and needing to be replaced

You've made a silly mistake and just did 1/8th the work, so of course it was 8x speedup. I am still wondering how the numbers would look if you could inline atan2f from libc. Too bad that isn't easier

Nice writeup and interesting results. I hadn't seen the use of perf_event_open(2) before directly in code which looks cool.

The baseline is at a huge disadvantage here because the call to atan2 in the loop never gets inlined and the loop doesn't seem to get unrolled (which is surprising actually). Manually unrolling by 8 gives me an 8x speedup. Maybe I'm missing something with the `-static` link but unless they're using musl I didn't think -lm could get statically linked.

Latest update adds an option to unhide all bodies before exporting. Thanks for pointing this out! https://github.com/aconz2/Fusion360Exporter/commit/f3203902c...

Thanks for the feedback.

File paths are always tricky and I will add something that removes some bad characters.

Noted on the visible bodies, I haven't had much time to verify the output so I will look into that this weekend. Thanks again.

Came to say the exact same thing, all the problems mentioned aren't unique to continuations. I'm not saying this makes a positive argument to use coroutines everywhere, but it's not their fault.

As ajuc mentioned, long-running processes and early/late bound is always a thing. Same with database migrations. Heck, even clients accessing a versioned api (foo.com/api/v1/bar) vs not has the same consideration.

> How long do you wait before invalidating the session and free its resources?

Same decision has to be made for explicit session data like login state and pagination cursors in eg. Facebook's graph API. Continuations are larger and therefore this question may have more weight.

> What resources does a continuation hold on to?

Anything reachable (static and/or dynamic analysis). And if you run your program in a monad (or other restricted, pure manner), then you can control when a function can suspend, like not in the middle of paging a database.

> Does opening a new tab duplicate any held resources by the continuation?

If you live in an immutable world, you get duplication for free with structural sharing. Same goes for an OS loading a shared library once and giving the same pages to multiple programs.

I do agree that having a blob of stuff serialized isn't very nice. Same goes for closures as well. The example I always compare in my head is a functional representation of a set vs. any other data structure.

I toyed around with an interpreter that would let you reflect a closure (same could be applied to continuations) to a program, which is akin to a residual program in partial evaluation. Then you could do whatever you want with the source of the closure/continuation. For the early/late bound question above, you could analyze the reflected continuation and decide exactly which bits you want to rebind before continuing the continuation.

I see something like this and think about how much an ensemble approach to the data structure would help. This keeps popping up in places where you have a very general abstraction (like the DOM) and want to support a broad set of operations and use cases (read-only, insert heavy, traversal heavy, etc.) and so you often choose the structure which supports most of these cases pretty well. But you sacrifice a lot of perf by doing so.

What I'm wondering is how well you could do perf-wise by having the DOM be comprised of a heterogeneous set of structures, each of which is chosen based on the history of what operations have been performed on it (ie. we're appending a lot here, let's use a vector of children). This is all similar in spirit and goals of:

- JIT compiling, but for the data structures, and not code

- This work on composing allocators in D https://www.youtube.com/watch?v=LIb3L4vKZ7U

- ML ensemble methods

Sure we're all making software which is just bits in memory, but I think that's an extreme simplification. Maybe you're thinking of how we're all just editing text to make programs? But then that doesn't account for what you do with the program you just wrote.

I think you're thinking of using more horsepower for strong scaling, which is a good use, but I'm more referring to weak scaling. You can work on bigger problems with more horsepower, not just solve the smaller ones faster.

"If you want to write yesterday's software, use a laptop" - me / paraphrase of Alan Kay I think?

I get why people are still blacksmiths making door handles and I think that's great. But I'd rather be in a giant machine shop making aircraft carriers.

I'm 2 for 2 personally and 3 for 3 on family recommendations buying refurbished Dell Latitudes. I currently have the E6430u which is very nice and light with good Linux support; that's a bit old now but I just checked and you can get an E7250 (i5, 256GB SSD, 8GB RAM, HD Screen) for under $600! And you can upgrade the memory... yourself!

Just make sure you double check the wireless card support on Linux. The Latitudes use a variety of different chips.

Where does all the hardware go when one decides to shut down an operation that large? Can I buy it?

The first part about comparing the callbacks in Javascript vs do notation in Haskell is super misleading. The do notation desguars to code that looks essentially identical to the Javascript version. Sugar is not a negligible consideration in system choice, but that kinda thing just bugs me.

> I wrote this article because it seems to me the basic income discussion is orchestrated by people, notably in technology, who are unaware of politics and reluctant to get their hands dirty.

While I myself am a programmer and support basic income, I have talked with many people outside the technology world who are also in favor of such a system. YC is getting their hands dirty with their research project and Finland's government is most definitely aware of politics. The only way for us (US citizens) to get our hands dirty in politics when not voting is talking about these things.

> ... energy thrown in BI-related discussions is wasted while it could be invested in favor of universal health insurance for instance ...

BI and health insurance, universal or not, solve very different issues. Both deserve attention and one doesn't preclude the other. I do think that a very important part of BI discussions is what programs it can replace, what it can supplement, and what it doesn't solve.

Bravo! Thank you for the full story.

Would fusing many tightly coupled Gs (lots of send's and recv's to each other) into a larger G by transformation into a state machine be a way to reduce scheduler overhead? Of course, you may not frequently know ahead-of-time which Gs are tightly coupled.

  Location:            TN, USA
  Remote:              Yes
  Willing to relocate: No
  Technologies:        OCaml, Racket, Python, C, Haskell
  Résumé/CV:           aconz2.github.io
  Email:               aconz2@gmail.com

Seeking work on programming languages, compilers, DSLs, and static analysis.

Most of the current comments are not abiding by the Show HN comment guidelines.

  In Comments
  
  Be respectful. Anyone sharing work is making a contribution, however modest.
  
  Ask questions out of curiosity. Don't cross-examine.
  
  Instead of "you're doing it wrong", suggest alternatives. When someone is learning, help them learn more.
  
  When something isn't good, you needn't pretend that it is. But don't be gratuitously negative.

In addition, not all software on the internet is meant to replace other software, compete with other software, or even be deployed in a production environment. The internet is more than large enough for lots of wheels of all shapes and sizes. Contributing to existing projects is good and so is writing your own programs.

I understand the underlying sentiment people are getting at - this seems similar to Redis - but we should keep an open mind. Maybe he wanted to write C++ instead of C? Maybe he was trying out boost::asio? Maybe he just wanted to write some code?

I hear you on expressiveness of using the language. Of course (and as you mention) the strength of restricting the expressiveness is that it becomes decidable in some amount of acceptable time for most programs.

I agree with your last sentiment but I don't think it has to be any less "formal" than something like Coq. I just think we shouldn't be so concerned with proving all properties of a program before running. And then we can turn the knob to adjust how much to prove during vs. before running.

Yep you are totally correct. I only point this out because the tool presented here does not do the same thing as other contract systems, but could (as you say) be used as a building block to get there.

> Instead of encoding constraints as type signatures, the Clojure folks (true to character) encode them in data.

I've never bought this line of thinking when the "Clojure folks" also say "code is data", because then a syntactic type signature you write down is also just data. If you want to consume the type signature (or spec signature or whatever) as syntax (as a sibling comment suggests), use a macro or any other program which consumes programs.

The thing I do see as being important is not how you write these things down, but whether they have an accessible representation at run/read/compile/whenever time.

Lastly, I strongly disagree these approaches are meant as a replacement for static typing or formal verification because (as far as I can tell) a value can be checked against a spec on demand, but makes zero guarantees as to what that value does in other parts of a program. This is also in contrast to Racket contracts, which will give you the correct blame information between parties using and not using contracts.

I think many may take your response as a bit off-the-cuff, but I share this sentiment. You could even go so far as to write the longest C program you could dream of to solve it, then simply feed it into

   tr -d '\n'

and call it one line! Again, many will find this pedantic and unsatisfactory but programmers should really be more precise in what they mean by lines of code.

What I think most people are really referring to is information content. To achieve the same program in shorter length, the rest of the information has to lie somewhere else (in the scala implementation or nqeensolver.h). We can increase the density of the information needed to specify a program, but not decrease it.

I actually just wrote something about this concept yesterday:

https://aconz2.github.io/programming/2016/04/09/power_of_pl....