quill VS Halide

https://github.com/Kobo-InkBox/inkbox#readme appears to be the non-ddns.net version, and is GPLv3

Is it really android? that's bad. It will be also propably impossible to port to inkbox

Handwritting notes more efficient than hunting down individual characters on keyboard (aka not a touch typist).

Stenograpy much more efficient than standard keyboard typing.

Likely same reason student(s) hasn't put together open source smart glasses displaying "talk" as text to allow for real time user hightlighting (for what user wants to capture/'note').

This is way more efficient than writing/typing, as can also capture/note non-text presentations. aka inkbox[0]/epireader[1], soli[1] (finger gesture/sign the key(s)), diy open source glasses[3]

[0] : https://github.com/Kobo-InkBox/inkbox

You might be interested: https://github.com/Kobo-InkBox/inkbox

InkBox

inkbox for kobo e-readers is great. It should be possible to port to other e-readers too

if you want a better reader, consider plato or koreader one click packages from niluje: https://www.mobileread.com/forums/showthread.php?t=314220 or inkbox (https://github.com/Kobo-InkBox/inkbox). NOTE: i don't run any of these, but have tried KOReader and Plato in the past.

If CPU/GPU execution speed is the goal while simultaneously code golfing the source size, https://halide-lang.org/ might have come in handy.

This is a task where Halide https://halide-lang.org/ could really shine! It disconnects logic from scheduling (unrolling, vectorizing, tiling, caching intermediates etc), so every step the author describes in the article is a tunable in halide. halide doesn't appear to have bindings for golang so calling C++ from go might be the only viable option.

Probably would have been much easier to do 15 times in https://halide-lang.org/

The idea behind Halide is that scheduling memory access patterns is critical to performance. But, access patterns being interwoven into arithmetic algorithms makes them difficult to modify separately.

So, in Halide you specify the arithmetic and the schedule separately so you can rapidly iterate on either.

It is not the sorting per-se which was improved here, but sorting (particularly short sequences) on modern CPUs with really the complexity being on the difficulty of predicting what will work quickly on these modern CPUs.

Doing an empirical algorithm search to find which algorithms fit well on modern CPUs/memory systems is pretty common, see e.g. FFTW, ATLAS, https://halide-lang.org/

Halide https://halide-lang.org/

It doesn’t apply in this case, but in general if you really want the best vectorization I would suggest using https://halide-lang.org instead of trying to coerce your compiler.

If we drop the "APL" requirement, wouldn't Halide fit your criteria for the third?