HN user

rjeli

1,701 karma

http://rje.li

[ my public key: https://keybase.io/rjeli; my proof: https://keybase.io/rjeli/sigs/g_UlqZH7q19Y1_4cFMHYmpBANDmW-KNtGysYrIaZP6w ]

https://rjeli.at.hn

Posts4
Comments449
View on HN

the implementations have a distinctly "I wrote this at a 3 AM hackathon" vibe

The LLM handles the natural language interaction and orchestration, while the computer algebra system does what it does best ... exact symbolic manipulation.

this smells like claude :D

Apple M3 Ultra 1 year ago

Wow, incredible. I told myself I’d stop waffling and just buy the next 800gb/s mini or studio to come out, so I guess I’m getting this.

Not sure how much storage to get. I was floating the idea of getting less storage, and hooking it up to a TB5 NAS array of 2.5” SSDs, 10-20tb for models + datasets + my media library would be nice. Any recommendations for the best enclosure for that?

IIRC when I played KSP it was necessary to point slightly down if you wanted to reach orbit in a continuous burn, rather than waiting to burn more at perigee. Is that true in general?

(was playing with a mod that models ullage, so relighting was quite finicky)

Note that the FFT has this property of “convolution is pointwise multiplication” for any cyclic multiplicative group, see https://www.sciencedirect.com/science/article/pii/S002200007... for a more algebraic derivation.

Some call this a “harmonic” fft, and there are also non-harmonic FFTs:

- the “additive NTT” of [LCH14] on GF(2^n)

- the circle fft on the unit circle X^2+Y^2=1 of a finite field [HLP24]

- the ecfft on a sequence of elliptic curve isogenies [BCKL21]

[LCH14]: https://arxiv.org/abs/1404.3458

[HLP24]: https://eprint.iacr.org/2024/278

[BCKL21]: https://arxiv.org/pdf/2107.08473

mactop 2 years ago

Does anyone have recs for doing really low level performance tuning on Apple Silicon? Xcode Instruments isn’t very easy to use or interpret. Things like what % of time is spent on memory stalls, simd units, etc

You can do it without a TEG: https://sci-hub.se/10.1109/48.972077

Essentially you use a fluid which freezes at the bottom of the ocean and loses volume (some kind of paraffin)

And then you hook it up with some actuated valves and N2 accumulators so the volume change and energy harvesting happens "out of phase" - at the surface, you can deflate an external bladder and sink, and at the bottom, you use some stored energy to reinflate the bladder

With a large enough volume you get near infinite range, only have to pay for payload and any onboard electronics

this report has some more info on the absurd efficiency of thermal gliders: https://escholarship.org/content/qt1c28t6bb/qt1c28t6bb_noSpl...

  First, we take some of the safety into our own hands. While this approach won't result in corrupted memory, double frees or accessing freed pointers, it can lead to run-time panics and other problems because we deal in "raw" indices to a vector.
Yeah, I’ve often seen people in discussions about c/zig/rust memory saying “manual memory management is fine, just use an arena and handles!” It’s a strange statement to me because you’re just laundering the unsafe pointer arithmetic behind array indexing

For example, to create a JPEG, part of the process is removing the "high frequency" parts of your image, since those take the most information to store. Here, high frequency refers to noise, or any large difference between neighboring pixels, as opposed to low frequency parts, which are averages over larger groups of pixels. So, at the extreme, if you average the whole image, you only have to store one pixel, so it's obviously less data to store, vs storing info about every single pixel. JPEG (and other lossy compression formats) tries to find a good middle ground between storing every pixel perfectly and storing just one pixel.

So, how do you remove the high frequency parts? You apply a Fourier transform to the image (in this case, it's a "Discrete Cosine Transform", which is extremely similar to a DFT and has no differences for the purpose of this explanation) and get a 2d array. This 2d array has the low frequency parts in the upper left corner, and the high frequency parts everywhere else (to the right and down for horizontal and vertical frequencies). So your compression algorithm will simply zero out the high frequency parts so you don't have to store them. In the simplest case, this is equivalent to a simple blur of the image, but there are some heuristics about how much to remove (zero out) to minimize image degradation.

To decode the image, you take the 2d array and apply the inverse FT to get the original image (now slightly blurry because it's been compressed).

More details here: https://en.wikipedia.org/wiki/JPEG#Discrete_cosine_transform