rjeli
> ob.patp('0')
'~zod'
> ob.patp2dec('~nidsut-tomdun')
'15663360'
> ob.hex2patq('010203')
'~doznec-binwes'
> ob.patq2hex('~marned-wismul-nilsev-botnyt')
'01ca0e51d20462f3'
> ob.isValidPatq('~marned-wismul-nilsev-botnyt')
> true
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
mirror: https://nitter.net/camrobjones/status/1907086860322480233#m
They link to the webapp which you can play yourself!
(I have a dozen games played and 100% success rate :3)
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?
(was playing with a mod that models ullage, so relighting was quite finicky)
(I am not a C or C++ expert.)
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
In particular, if you choose a group where discrete log is hard (such as prime order elliptic curves), multiset hashing falls out for free
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.
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