It's nice to see some high-performance linear algebra code done in a modern lanugage! Would love to see more!
Is your approach specific to the case where the matrix fits inside cache, but the memory footprint of the basis causes performance issues? Most of the communication-avoiding Krylov works I've seen, e.g [0,1] seem to assume that if the matrix fits, so will its basis, and so end up doing some partitioning row-wise for the 'large matrix' case; I'm curious what your application is.
You might be interested in ExponentialUtilities.jl then. Julia has a really unique ability to make high performance linear algebra look like the math. See https://github.com/SciML/ExponentialUtilities.jl (specifically src/kiops.jl and src/krylov_phiv.jl) for an example of a good matrix exponential operator in ~600 lines of code+comments.
When did you look and what tooling was missing? Julia's package manager Pkg was pretty heavily inspired by cargo, and IMO it does a very good job. Also in the past 2-3 years Juliaup (modeled after rustup) has become the primary way of installing and managing Julia versions
It's possible to use Tailscale with just a passkey [0], but it's a weird process because they don't let you create a tailnet and a passkey account at the same time. Instead, you need to create an account with a throwaway FAANG credential and send yourself an invite to that account's tailnet, and then use that invite to create a passkey-linked Tailscale account. This account can then create its own tailnet, at which point the original tailnet (and the throwaway FAANG account) can be discarded.
It's a weird process and not particularly user friendly (passkey accounts are tied to a specific passkey and can't have additional ones added, so you need to create a new account if you, say, migrate from one hardware key to another). Hopefully they improve the process before passkey support goes out of beta.
I feel like maybe they should allow adding SSH keys as a login method instead of passkeys.
Though I suppose there is the potential problem of identitiy collision due to public key resuse unless the keys were generated serverside to guarantee uniqueness.
Methane flare. Liquid methane will turn to gas as it warms up, so they need to get rid of it somehow. Nitrogen and oxygen they can just vent. Generally methane is flared to prevent explosive gas buildup and (the worst of) greenhouse gas effects. Sometimes it's cooled back into a liquid, but that is apparently more effort than it's worth because flaring seems common practice.
Edit: just remembered the second stage is hydrogen. So it might be flaring that, or maybe the smaller flare off to the side is hydrogen.
Do you have a feel for how the maneuverability of a B-1 being controlled by the canards compares to that of a typical airliner?
It seems like a system like this would need to respond very quickly to changes in the air mass, and the weight and slow response of an airliner might make this system less feasible unless you could somehow measure airflow a reasonable distance in front of the plane.
Based on my recollection of a conversation with the authors after their STOC talk: the RAM scheme is not efficient enough to be competitive with circuit-based FHE schemes; for problems with low RAM usage, existing circuit-based methods are more efficient, and problems with higher RAM usage are infeasible to run on any FHE method right now.
They were 50/50 on whether or not this technique could be made feasible in the same way that, say, the CKKS scheme is.
Most button accordions and modern electronic instruments (Linnstrument, Soundplane, Eigenharp) are have chromatic layouts... I wonder if you could hook up one of these devices up to a player piano without too much latency.
You'd lose the physical dimension of playing the keys.
For the accordion you adjust the force of the air, so you don't have to use different forces on the buttons. It's OK that you find them with only your fingertips.
That's less OK when the force hitting the key is directly transferred to the string making the sound. You need a dynamic range. It seems to me most of the people here are forgetting that.
Such a layout could probably be used on an organ. But I think keyboard size is less of a problem for organs?
The Linnstrument captures the dynamic range of strike and release velocity, as well as pressure and aftertouch direction; translated to MPE (MIDI Polyphonic Expression).
As someone with relatively small hands for piano, I have been enjoying the wider range of intervals with one hand provided by the Linnstrument's layout.
In terms of trying to break free of dependence on hand optimized kernels: a few people, myself included, have been working on some theoretical approaches to generating cache-efficient rearrangements for neutral net like problems. We've worked it out for convolution like problems [1] and have some upcoming results generalizing these techniques to other problems. Please feel free to email if you'd like to talk.
The author mentions that he would design a system with a continuously monitored pulse oximeter that could trigger the EPS descent mode automatically. Do wrist-mounted versions (fingertip ones would probably be too bulky/uncomfortable for continuous use by someone at the controls) of such continuous oximeters exist at the moment? The Apple Watch apparently has a sensor capable of measuring blood oxygen content, but disabled that functionality for unstated reasons (FDA regs?) [1], and I'm unaware of any extant wrist-worn device with that functionality enabled.
Firefox doesn't deal with touchscreen and touchpad gestures very well. Take, for instance, the two-finger pinch-zoom-in gesture. Chrom(ium), Opera, Edge, Safari etc. all smoothly and instantaneously magnify the area where the mouse is. Firefox, on the other hand, reflows the entire page with each zoom (as the other browsers do when you do a ctrl +/- zoom), which is inconsistent with how we're used to interacting with touchscreen devices, in addition to being quite laggy on a reasonably modern laptop and tending to undershoot or overshoot the desired zoom level. This zoom behavior is also a lot less useful for looking at a particular item on the page, since the reflow-zoom doesn't seem to depend on mouse position on any way (so any element not at the center of the screen will no longer be visible past a certain zoom level, no matter where you put the mouse pointer when zooming in), which makes using it a lot more frustrating on smaller monitors.
I do not own a touch screen device that is not a mobile device, so I have not experienced that. I also realize that my comments only related to the UI portion, not taking into account how responsiveness (or lack of) affects the UX portion.
I am a firefox user but will switch to chrome when using google maps. Simply because using maps on firefox on my windows tablet sucks, but its a breeze in chrome.
Otherwise I completely avoid chrome because of the privacy issues, and because firefox has 'containers' and is a little snappier.
Is your approach specific to the case where the matrix fits inside cache, but the memory footprint of the basis causes performance issues? Most of the communication-avoiding Krylov works I've seen, e.g [0,1] seem to assume that if the matrix fits, so will its basis, and so end up doing some partitioning row-wise for the 'large matrix' case; I'm curious what your application is.
[0] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-..., e.g. page 25. [1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-...