The only AF systems that use LIDAR are the one on the newest Hasselblad medium format mirrorless cameras (since DJI owns Hasselblad and can leverage the tech from drones/cinema cameras) and possibly some phones.
I suspect it's fairly challenging to implement since the LIDAR sensor doesn't operate through the lens, so you'd have to continuously align the depth map with the image to account for parallax; plus it's only useful for close-ish distances (since the lasers can't be too powerful) and can cause unwanted focus behavior with windows or reflections.
Replacing the batteries on the Maxes is actually a fairly straightforward process (no adhesive melting required, just a screwdriver and a pry bar), and spare batteries can be purchased on Amazon or Ebay for around 50 USD. It's one of the better Apple products in that regard, very unlike the in-ear models.
Did that change with the Air Pod Max USB-C, because iFixit says you have to get past adhesive to get to the batteries, after you turn the specialized screws only a quarter turn, and then use a dental pick to separate the pieces after you heat the adhesive being careful not to melt other parts?
>The next round of frustration: adhesive. That's right, releasing the locks and/or removing the screws isn't enough. Out comes the heat gun, which must be wielded very carefully to avoid melting all this plastic.
You don't have to melt through that adhesive - it's incredibly weak and you can just pop it out with a sufficiently thin pry bar. This guide [1] does it with an iSesamo, but I just used a utility knife since I had one on hand and wasn't particularly concerned with scratches (the entire seam is covered by the headphone pads, so scratches around it are invisible).
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.
I suspect it's fairly challenging to implement since the LIDAR sensor doesn't operate through the lens, so you'd have to continuously align the depth map with the image to account for parallax; plus it's only useful for close-ish distances (since the lasers can't be too powerful) and can cause unwanted focus behavior with windows or reflections.
reply