frumiousirc

Yes, for example "swarm optimization".

The difference with "autoresearch" (restricting just to the HPO angle) is that the LLM may (at least we hope) beat conventional algorithmic optimization by making better guesses for each trial.

For example, perhaps the problem has an optimization manifold that has been studied in the past and the LLM either has that study in its training set or finds it from a search and learns the relative importance of all the HP axes. Given that, it "knows" not to vary the unimportant axes much and focus on varying the important ones. Someone else did the hard work to understand the problem in the past and the LLM exploits that (again, we may hope).

FWIW, in Kitty on Linux, SHIFT + mouse-select copies and SHIFT + middle-mouse-button pastes. This use of SHIFT and otherwise using standard Unix style copy/paste is common in a lot of TUIs (eg, weechat).

Frequently returns, "Oh, you are absolutely correct, let me redo this part better."

I don't have direct experience with ChatGPT but those that do that I've talked to place it behind Gemini and Claude models.

Try free Claude or Gemini on the web and see if you have a better experience. Claude free is better than Gemini free. (actually, Gemini free seems extra dumb lately).

Google's AI that gloms on to search is not particularly good for programming. I don't use any OpenAI stuff but talking to those that do, their models are not good for programming compared to equivalent ones from Anthropic or google.

I have good success with free gemini used either via the web UI or with aider. That can handle some simple software dev. The new qwen3.5 is pretty good considering its size, though multi-$k of local GPU is not exactly "free".

But, this also all depends on the experience level of the developer. If you are gonna vibe code, you'll likely need to use a paid model to achieve results even close to what an experienced developer can achieve with lesser models (or their own brain).

FWIW, what you describe maps well to Beads. Your directory structure becomes dependencies between issues, and/or parent/children issue relationship and/or labels ("epic", "feature", "bug", etc). Your markdown moves from files to issue entries hidden away in a JSONL file with local DB as cache.

Your current file-system "UI" vs Beads command line UI is obviously a big difference.

Beads provides a kind of conceptual bottleneck which I think helps when using with LLMs. Beads more self-documenting while a file-system can be "anything".

Slot machines that are biased toward producing jackpots.

And "jackpots" are a metaphor for "training distribution".

    MY_API_KEY=$(pass my/api/key | head -1) python manage.py runserver

My mental model is that LLMs are obedient but lazy. The laziness shows in the output matching the letter of the prompt but with as high "code entropy" as possible.

What I mean by "code entropy" is, for example, copy-paste-tweak (high entropy) is always easier (on the short term) for LLMs (and humans) to output than defining a function to hold concepts common across the pastes with the "tweak" represented by function arguments.

LLMs will produce high entropy output unless constrained to produce lower entropy ("better") code.

Until/unless LLMs are trained to actually apply craft learned by experienced humans, we must be explicit in our prompts.

For example, I get good results from say Claude Sonnnet when my instruction include:

- Statements of specific file, class, function names to use.

- Explicit design patterns to apply. ("loop over the outer product of lists of choices for each category")

- Implementation hints ("use itertools.product() to iterate over the combinations")

- And, "ask questions if you are uncertain" helps trigger an iteration to quickly clarify something instead of fixing the resulting code.

This specificity makes prompting a lot more work but it pays off. I only go this far when I care about the resulting code. And, I still often "retouch" as you also describe.

OTOH, when I'm vibing I'll just give end goals and let the slop flow.

Since you still have C++ involved and if you are still looking for composable dataflow ideas, take a look at TBB's "flow_graph" module. It's graph execution is all in-process while what you describe sounds more distributed, but perhaps it is still interesting.

FWIW, this has become a perfectly cromulent pattern over the decades.

It allows highly concurrent computation limited only by the size and shape of the graph while allowing all the payloads to be implemented in simple single-threaded code.

The flow graph pattern can also be extended to become a distributed system by having certain nodes have side-effects to transfer data to other systems running in other contexts. This extension does not need any particularly advanced design changes and most importantly, they are limited to just the "entrance" and "exit" nodes that communicate between contexts.

I am curious to learn more about your system. In particular, what language or mechanism you use for the description of the graph.

This definitely agrees with my experience. But a corollary is that written human language is very cumbersome to encode some complex concepts. More and more I give up on LLM-assisted programming because it is easier to express my desires in code than using English to describe what forms I want to see in the produced code. Perhaps once LLMs get something akin to judgement and wisdom I can express my desires in the terms I can use with other experienced humans and take for granted certain obvious quality aspects I want in the results.

I'm now trying to contemplate what a truly 1D pong game would be. We can't escape time so we would have to remove positional and chromatic dimensions. That leaves us with a single blinking monochromatic LED.

Perhaps the game would resemble Richmond's flashing lights.

Names capture ideas. Only if we name something can we (or at least I) reason about it. The more clear and descriptive a name for something is, the less cognitive load is required to include the thing in that reasoning.

TFA's example that "weight" is a better variable name than "w" is because "weight" immediately has a meaning while use of "w" requires me to carry around the cumbersome "w is weight" whenever I see or think about "w".

Function names serve the same purpose as variable names but for operations instead of data.

Of course, with naming, context matters and defining functions adds lines of code which adds complexity. As does defining overly verbose variable names: "the_weight_of_the_red_ball" instead of "weight". So, some balance that takes into account the context is needed and perhaps there is some art in finding that balance.

Comments, then, provide a useful intermediate on a spectrum between function-heavy "Uncle Bob" style and function-less "stream of consciousness" style.

It is correct to say "0.0046237213 Hz which is 0.27742328 BPM". My mistake was to interpret 0.27742328 BPM as the limit of frequency resolution in units of BPM. Rather, any BPM measured must be an exact multiple of 0.27742328 BPM.

Thanks for pointing out my mistake!

> (regardless of track length, which already smells suspect)

Frequency resolution being dependent on the number of samples is a very well known property of basic sampling theory and signal analysis.

In fact, one can interpolate the frequency spectrum by zero-padding the time samples. This increases the resolution in an artificial way because it is after all an interpolation. However, a longer song has more natural frequency resolution than a shorter song.

Note, this frequency resolution is not related to fidelity which is some messy human related thing that is over a sliding window of shorter duration that I don't pretend to understand.

BTW, the opposite is also possible. You can zero-pad the spectrum as a means of resampling (interpolating) the time domain. This is slower but more spectrally correct than say time-domain linear or cubic interpolation.

These techniques require an FFT and so are somewhat expensive to apply to long signals like an entire song, as I did for the plot. Daft Punk's HBFS takes about 8 seconds on one CPU core with Numpy's FFT.

Besides the sample period, the total number of samples matter for frequency resolution (aka BPM precision).

44100 Hz sampling frequency (22.675737 us period) for 216.276 s is 9537772 samples (rounding to nearest integer). This gives frequency samples with a bandsize of 0.0046237213 Hz which is 0.27742328 BPM.

Any claim of a BPM more precise than about 0.3 BPM is "creative interpretation".

And this is a minimum precision. Peaks in real-world spectra have width which further reduces the precision of their location.

Edit to add:

https://0x0.st/Pos0.png

This takes my flac rip of the CD and simply uses the full song waveform. This artificially increases frequency precision by a little compared to taking only the time span where beats are occurring.

Water is most transparent in the middle of the "visible" spectrum (green). It absorbs red and scatters blue. The atmosphere has a lot of water as does, of course, the ocean which was the birth place of plants and eyeballs.

It would be natural for both plants and eyes to evolve to exploit the fact that there is a green notch in the water transparency curve.

Edit: after scrolling, I find more discussion on this below.

Some supposition: A Fourier amplitude image should show that pattern as peaks at a certain angle/radius location. The exact location may be part of the identification scheme. Running peak finding on the Fourier image and then zeroing out the frequencies in the peak should remove the pattern. Modeling the shape of the peak would allow mimicking the application of a legit SynthID signature.

If anyone tries/tried this already, I'd love to see the results.

1-2 seconds is an eon for audio latency so I guess something else is going on than anything BT related in the headphones. Unless you have particularly bad luck in what headphones you use.

FWIW, I use a variety of cheap and not so cheap BT headphones across multiple devices and apps including AnkiDroid and have not perceived any latency.

If switching to wired removes the latency then it does seem to indicate something in the BT stack of your device. I wonder if you experience the lag when using AnkiDroid + BT on another device.