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).
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.
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.
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.
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.
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.
Credit card data sharing has been around for a while. Fortunately, financial institutions appear to be marginally less pathological about allowing people to control how their personal data is used than certain large social media companies, and there are opt-outs for pretty much all of the major financial institutions.
According to the article, users can also opt out of the tracking on Google's side using Google's privacy controls. However, I think it's probably best to opt out of that data being collected in the first place, since the financial companies are probably selling that data to other companies.
Here's the link for Mastercard: https://www.mastercard.us/en-us/about-mastercard/what-we-do/... (the language is kind of strange - "To opt-out from our anonymization of your personal information to perform data analyses" - I'm hoping it refers to opting out of sharing your anonymized personal info, not opting out of the anonymization so they can sell your un-anonymized personal info, but someone should confirm this by sending them a letter).
Amex seems to be somewhat better about this, saying "We only share your personal data with third parties where it is necessary to provide you with products or services or as part of the nature of our relationship with you, where we have previously informed or been authorized by you, in connection with our efforts to reduce fraud or criminal activity, or as permitted by law." (source: https://www.americanexpress.com/us/content/customer-privacy-...). Whether anonymized data is considered 'personal data' isn't clear, though - the definition given is "any information that relates to an identified or identifiable individual." Whether the "relates to" property persists after anonymization is not specified.
It's also worth noting that opting out of data sharing by a credit card network does not limit data sharing by the bank that issues the card - for that, you probably have to contact them separately (Chase, for instance, has a privacy number you need to call to opt out of data sharing https://www.chase.com/digital/resources/privacy-security/que...).
Davis says the buried structure caused the drought-stricken plants above ground to ripen at different rates, because the earth was deeper in some places than in others. This created a green-and-brown pattern in the plants that corresponded to the buried ruins.
Can someone please explain why this is the case? Is it because plants try to grow their roots deeper during droughts in order to access water that can't be obtained at the surface?