At least for C and C++, unless there are specific constraints — such as 
printing intermediate results not computed by FFT, or more likely, strict 
floating point error rounding (i.e. -fno-fast-math) — compilers are free 
to do this per the abstract machine. Only the DFT outputs are observable, 
not the inner workings.

IMHO, a compiler that transforms a generic DFT into FFT without having 
been programmed for that specific pattern is entering AI territory. I've 
noted in the past[1] that I've been a little freaked out at just how far 
optimizer reasoning can go. Both GCC and Clang can optimize non-tail 
recursive algorithms into iterative algorithms — without it being some 
specific algorithm — and your DFT example is really just a sophisticated 
version of this idea.

> --input-files *.jpg

This has no way to indicate where the arguments stop such that option 
processing can continue, so this option must go last. If it must go last, 
then these are really just positional arguments. If you do choose some 
sentinel to mark the end (perhaps "--") then there's the risk of an 
argument unintentionally matching as a sentinel, such as blog expansion. 
As you noted, stopping at the first option-like argument (a la argparse) 
is similarly unsound.

You mentioned repeated arguments, probably the most conventional way to 
supply multiple arguments for a particular option. For instance, there's 
ffmpeg's -i option. Though as you also noticed, this isn't friendly to 
globbing.

You can reflect cl-defstruct to convert records to plists. For instance:

(cl-defstruct poi name category latitude longitude)

(defun struct-to-plist (struct)
  (cl-loop for i upfrom 1
           for (slot . _) in (cdr (cl-struct-slot-info (type-of struct)))
           collect (intern (concat ":" (symbol-name slot)))
           collect (aref struct i)))

Then, say, convert to JSON:

(json-encode
 (struct-to-plist

I know almost nothing about Org, so I can't really help with that part. As 
for Elfeed itself, bind T in elfeed-search-mode-map to your new function. 
In your function use elfeed-search-selected to get the struct for the 
entry under the point, interrogate it using elfeed-entry-* accessors, then 
call the appropriate Org functions with what you found. As a convenience, 
you might also want your function to advance the point to the next line so 
that you can quickly make a sequence of decisions for all visible entries.

Thanks, Dimitrije! I've learned something new, so my exercise continues to 
serve its purpose. My mistake seems really obvious after having it spelled 
out. Alternative to your suggested fix, it seems HMAC would have rescued 
this MAC as well. I'd have been better off skipping the "swap" trick 
altogether and just relying on that.

Thanks for sharing your article, Rusty! Your list of downsides are all 
true and accurate.

> I'd be interested in hearing your opinion about locking subranges of a 
> large overall purgeable allocation.

If you're talking about adding this as a feature to my library, that 
implementation exists primarily as a proof of concept for my article, so 
outside of fixing defects I consider it frozen. The idea isn't that 
anyone would rely directly on my repository like a package. Instead, 
they would copy and embed it into their project, taking ownership of 
their fork — with the ubiquity of per-language package managers, a dying 
art these days — and making modifications if necessary to support that 
project. Or they would build their own using mine as a guide, e.g. when

> It also is more computationally expensive to display HTML emails, 
> requiring more power and newer hardware, reinforcing the "buy a new 
> one" upgrade loop

IMHO, this is a much larger issue than the rather insignificant extra 
server and network resources spent handling HTML emails vs. plain text. 
So much perfectly good hardware is routinely turned into e-waste simply 
because it cannot interoperate with an increasingly and unsustainably 
resource-hungry web ecosystem. It's something that really bothers me.

Regarding mkproof: In the interests of leveling the playing field 
between regular users and attackers, I've made an implementation that, 
on a conventional laptop, turns those tens of minutes into tens of 
seconds:

https://git.sr.ht/~skeeto/mkproof-fast

Since I did not make any effort for its outputs to "blend in" (trivially 
corrected), and as part of being (nearly) deterministic, its proofs have 
an interesting look:

argon2id:10:12:5:561cade5761a05cd67c9efae93a6fc6d
57210000000000300000000000000000

> but your polynomial is a trivial case of NN with single layer and 
> linear activation functions, which already makes this statement false.

My point is that the non-linear properties of a neural network — the 
main reason to use a neural network in the first place — are unnecessary 
for navigating a driver around a racetrack in a manner described in the 
NN video, and I prove that by using a linear model to successfully 
navigate several courses like the one in the NN video. My model being a 
trivial linear NN doesn't change this. Lots of things are NN subsets, 
but it's not useful to call them NNs.

> Again it was trivial use of that algorithm with just one single 
> generation.

Thanks for sharing, Kaligule! I like that you included your own 
animations — very illustrative of the usefulness in debugging. I've 
added a link to your article from my article. Once it's ready, I'm 
interested in seeing a link to your Rust source in your article.

You're right about my code. I do normally make a final pass to clean up 
for ease of reading / understanding. I was mostly interested in testing 
my idea, so I did some janky things that should have been done better, 
like the way I simultaneously overdraw and underfill my car rectangles. 
Since I didn't tidy up this time, I hid the source code link at the 
bottom of my article, and instead focused on the concepts rather than my 
particular implementation of them.