• whereitsat@lemmy.zip
    15·
    6 hours ago

    brilliant satire that critiques all of magazine journalism.

    i love going to [insert publication here] and reading another article about ‘so and so is ready for their next chapter in life.’ the so and so always an uninteresting, overly wealthy fuckwit that hasn’t accomplished anything other than going to college and having a wealthy parent.

  • tal@lemmy.todayEnglish
    62·
    4 hours ago

    It’s humorous, but last I checked, the best general-purpose compressors with the highest levels of compression—even lossless, which is probably not what most people think of when they think of neural nets—are neural net based.

    Neural net-based compressors are computationally expensive, which is why we don’t normally use them for most day-to-day tasks, but they really can produce really small outputs.

    I’m going to take the text of the US Constitution and stick it in a text file.

    $ wget https://www.gutenberg.org/cache/epub/5/pg5.txt
$ stat -c %s pg5.txt 
48326

    Okay, so 48326 bytes.

    Let’s do lzo. You’d expect a limited amount of compression — LZO is “fast” compression, usually only used where compression speed is really important, like where you want to be compressing stuff that’s going to be decompressed once and your bottleneck is throughput to disk:

    $ lzop <pg5.txt >pg5.txt.lzo 
$ stat -c %s pg5.txt.lzo
24843

    Okay, how about gzip? That’s Deflate, an older, but pretty-widely-used general-purpose compression algorithm.

    $ gzip <pg5.txt >pg5.txt.gz
$ stat -c %s pg5.txt.gz
16660

    Okay, what about LZMA? That’s a newer, more-CPU-intensive thing that’s probably a good general-purpose choice that’ll generally give better compression ratios. It’s the kind of thing that I’d probably use in a lot of cases. (Personally, these days, I tend to use pixz, which provides both indexed access for tarballs and parallel compression and decompression, which is important for modern processors.)

    $ xz <pg5.txt >pg5.txt.xz
$ stat -c %s pg5.txt.xz 
15488

    Okay, now PAQ, a neural-net-based compressor:

    $ zpaq a pg5.txt.zpaq a pg5.txt -method 5
$ stat -c %s pg5.txt.zpaq 
13063
    • BradleyUffner@lemmy.worldEnglish
      2·
      4 hours ago

      “Neutral net based” compression isn’t even in the same universe as “compressed to a prompt” via LLM

      • tal@lemmy.todayEnglish
        11·
        3 hours ago

        It actually is. I mean, it’s building a dictionary off of a variety of content ahead-of-time, rather than training it on the specific item in question, but that’s not uncommon for non-general-purpose compressors.

        I mean, doing so to a (probably short) prompt is (a) lossy (and I gave a lossless example) and (b) lossy to an extreme degree, to where it’s probably not incredibly useful option for the kinds of systems that exist today.

        But…existing diffusion models aren’t actually intended for this, either. I’d bet that you could train a model to do image compression along these lines, with a large dictionary, that could do usable compression along the lines of what is (jokingly) described in the article. Probably have a larger compressed form than what they’re thinking of.

        EDIT: At one point in time, about over a quarter-century ago now, I went out and banged on a neural net post-processor for JPEG artifacts. The idea here is that JPEG very probably isn’t optimally representing the final image, as a human, using their knowledge of what the world looks like, can manually (if time-consumingly) clean these up. I didn’t meet with a lot of success; I only wanted to put a small amount of time into it, and I was working with much weaker hardware than people are running neural nets on today. But that generated a pre-existing dictionary, a pre-trained neural net, off a training corpus of uncompressed images. It didn’t try to reconstruct the image from scratch, the way something like this would, just clean up artifacts, but it has that same pre-generated neural net approach.

  • Snapz@lemmy.world
    1·
    3 hours ago

    ♪ Hey, hey, billy, can you

    compress the Buick ? ♪

    Well, all right, but

    he’ll probably Pu-ick.

  • M1k3y@discuss.tchncs.de
    131·
    6 hours ago

    The sad thing is that this has been possible for decades using convolutional autoencoders, but with LLMs we forgot that AI architectures other than transformers still exist.

    • CanadaPlus@lemmy.sdf.org
      5·
      5 hours ago

      Yeah, it’s really awful. With any luck, AI winter will follow AI summer, like usual, and the serious people can come out again. Although, aren’t CNNs more of a this century thing? I guess two decades is still decades…

      IIRC autoencoders actually produce the same image to within our ability to notice, as well.

  • Richard@lemmy.world
    5·
    6 hours ago

    This is not funny, you don’t understand how long and how many nights i spend overengineering compression pipelines for family photos and videos…

    • lad@programming.devEnglish
      15·
      13 hours ago

      That’s nice, albeit I want to point out for anyone wondering that this is only conjectured and not guaranteed:

      One of the properties that π is conjectured to have is that it is normal, which is to say that its digits are all distributed evenly, with the implication that it is a disjunctive sequence, meaning that all possible finite sequences of digits will be present somewhere in it.

      There is no guarantee for any specific sequence to appear in π, but for short chunks chances are better (it’s not really a probability, but it’s simpler to say and I can’t explain in details anyway). That’s because (from wiki):

      It is widely believed that the (computable) numbers √2, π, and e are normal, but a proof remains elusive.