From Christopher Wellons to ~skeeto/public-inbox
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.
From Christopher Wellons to ~skeeto/public-inbox
> --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.
From Christopher Wellons to ~skeeto/public-inbox
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
From Christopher Wellons to ~skeeto/public-inbox
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.
From Christopher Wellons to ~skeeto/public-inbox
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.
From Christopher Wellons to ~skeeto/public-inbox
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
From Christopher Wellons to ~sircmpwn/public-inbox
> 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.
From Christopher Wellons to ~sircmpwn/public-inbox
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
From Christopher Wellons to ~skeeto/public-inbox
> 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.
From Christopher Wellons to ~skeeto/public-inbox
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.