It is worth noting that as the length of data increases it becomes extremely unlikely that the index and length of the sequence within pi would actually be smaller than the data.
Can't tell if you're in on the joke or not, but for anyone who is genuinely wondering whether this might work: Consider that there are at most 256 different indexes that could be represented by a 1-byte index value, but if you're trying to store 9 bits of data, there are already 512 different possible things it could be that each need to be represented by a different index value, otherwise you won't be able to tell them apart. Those pigeons aren't gonna fit.
It's recursive as well, you now need to store how many levels of indirection of indices you had to resolve, which will in turn take 20TB to store, unless you store that in pi as well, which in turn...
> Now, we all know that it can take a while to find a long sequence of digits in π, so for practical reasons, we should break the files up into smaller chunks that can be more readily found.
> In this implementation, to maximise performance, we consider each individual byte of the file separately, and look it up in π.
For a given length of data, considering all possible data of that length, it's impossible for the median length to be shorter than the data length. There aren't enough strings of that length that early in the data.
I wonder if it might make more sense to come at it from the opposite angle. Take pi as a sequence you want to compress with. But pi, being random, has redundancies in it that make it less than optimal. So instead, for a given size of block you want to look up, design the optimal number to use for compression. For instance, if you want to compress "594" in the digits of pi, the sequence 253 appears before it twice, which means any attempt to "compress" any three-digit sequence that only first appears after the second 253 is costing you more to get past the second 253, and "pi, but with all the 253s removed after the first one" is clearly a more efficient encoder for 3-digit numbers than pi itself.
So, instead of using pi, design an optimal number to encode with.
What you'll find is that the optimal sequence ends up being equally efficient as listing the blocks in order and indexing by block number itself. There are a number of other solutions; you could use superpermutations to get "all possible subsequences" with fewer digits in your target number, but you'll end up needing to provide the encoder and decoder a table of where the digit sequences appear since they are no longer regular and indexing into that table will cost exactly the same as just writing your number as the concatenation of all the blocks and its efficient method for indexing into them by indexing on the block rather than the digit number.
This actually has some natural overlap with the "normal numbers" in that one of the earlier normal numbers was: https://en.wikipedia.org/wiki/Champernowne_constant I'm not sure whether this is necessarily optimal for an arbitrary block size. (My quick intuitive check suggests it may be, but "my quick intuitive check" in the time of an HN post is not something I'd count on.) In this scheme, you can include the fact that the person using this constant to encode knows the nature of the constant, so they know that if you give index 0-9, it's single digit, and if you index into the two-length blocks, it must have a length of two. Since the encoder and decoder know that, they can also skip the middle of the block and just index into "the n'th number"... which degenerates into "the index of number N is N", which means this is not a compression scheme.
To put all that in a nutshell, if you want to deeply understand why this compression scheme doesn't work, I think you can attain a deep understanding of why by optimizing it.
jshell> "πfs".toUpperCase()
$1 ==> "ΠFS"
Welcome to Node.js v26.3.0.
Type ".help" for more information.
> "πfs".toUpperCase()
'ΠFS'
Python 3.14.5 (main, May 10 2026, 10:21:34) [Clang 21.0.0 (clang-2100.0.123.102)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> "πfs".upper()
'ΠFS'
echo 'πfs' | awk '{print toupper($0)}'
ΠFS
Transparency in a flag is new to me. It's surprisingly effective here. Could this be done with just cloth without synthetics by using thinner threads or thread count?
I also love the transparency and am surprised it hasn’t been used more. Granted, it would be very difficult to achieve with natural materials and also be durable. A flag should be able to withstand an ocean voyage exposed to the elements.
I think you pointed out very well why it hasn't been used more: lack of durability. Either it has to be some kind of plastic foil, in which case it has to be thin enough to fly in the wind the same way as a traditional flag does, so it will degrade very quickly when exposed to the elements. Or the silk organza suggested on the page, but if it's thin enough to be (almost) transparent I'm not convinced that it would fare much better.
So, nice idea, but completely impractical, which makes it a gimmick.
I feel what makes it work well here is also that it's not perfectly transparent so you can still see it wave in the wind and make out it's rectangular shape.
I'd definitely take that into consideration for a digital
version.
The website mentions silk organza at https://1worldflag.com/flag/. That's where my mind went initially, some kind of sheer silk fabric. I don't know how durable it would be in the elements though.
You could make any flag out of non-vegan materials, sure. But that this flag was designed with the basis of cruelty (silk) makes it also conceptually non-vegan.
What a great way to unite the world in a practice of cruelty to its inhabitants
It's a novel and fun idea! I also wonder how it would be represented correctly as a digital image, could be as an actual png or maybe the white/grey checker pattern from PhotoShop? Realistically probably just with a white background
Note those only apply to scene_sad which is used for scene change detection and freeze detection and a few other things like mpdecimate -- it's a very specific use case
This is why I like things like React and Astro, for the most part it is just JavaScript in the end. Other than JSX which is already familiar from using HTML and has applications beyond React
The same concept applies to anything with two loops as well. You can use it to quickly and easily tie together garbage bag loops, or grocery bag loops etc.
Migrate off vite to what exactly? I just migrated a personal project to vite and it simplified the existing webpack thing drastically, I was very impressed.
IDK, I've been purposely limiting the scope of work I can provide by only working with js, html, css. It's extremely limiting but when it comes to basically making one-off splash pages it's nice to not worry about tooling and just deploy what I made instantly. Modern CSS is amazing, there's no need to use sass or postcss. The modern web APIs are amazing as well. You can get a lot done with new base standard across browsers. The only libraries I really pull in nowadays are anime.js + umami for analytics.
I don't even need TS and can get away with js doc annotations + a functional LSP allows me to be slightly more dangerous (think running with scissors in chain mail).
Maybe if you need a specific web app you can reach for the complex tooling but even then I still wonder if it's necessary? The most popular political tool I've shared was a simple HTML page that just fetched the census API for specific codes in a tabular format. Sure I could have used react which would have enabled me to unlock some future value I couldn't foresee at the time but the working alternative is that I have a single html page with minimal JS (around ~2k LOC) that a surprising amount of nontypical devs (think carpenter that is interested in cybersecurity or union negotiators) are able to extend by themselves for their own needs (think adding census codes about snap or public transit).
There is a tremendous amount of value in telling my users how they can modify the source code and see the immediate impact of doing as much.
If this was a project that would have necessitated vite the first thing I would tell them is to install nodeJS and that's where I would lose 99.9999999999% of my users being able.
These projects will never go beyond 500,000 visitors and a CDN is more than sufficient for 90% of the work I do. So that obviously plays a major role but if this is a solo project there are much better choices to make if you want it to be sustainable + low upkeep. Those two qualities are something we as an industry should always value as it makes all our jobs collectively easier.
Excited to see Resolve continue to improve. Hopefully this encourages more improvement in the wider ecosystem as well. Adobe really could do some amazing stuff with Premiere and After Effects.
Finally, tee in the command prompt. I want to like powershell but the way it handles [] in filenames has bitten me so many times and fixing it turns simple things into verbose LiteralPath incantations
reply