Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

The New Coffee Room

  1. TNCR
  2. General Discussion
  3. Puzzle time: Compression

Puzzle time: Compression

Scheduled Pinned Locked Moved General Discussion
5 Posts 3 Posters 29 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • KlausK Offline
    KlausK Offline
    Klaus
    wrote on last edited by
    #1

    Somewhat related to Jon's most recent puzzle.

    We all know zip files and the like: Their purpose is to reduce the size of data in such a way that the original data can be reconstructed (usually known as lossless compression).

    Sometimes, however, something funny happens: When you try to compress a file, the compressed version is actually bigger than the original data.

    My question is this: Can there be a lossless compression method that does not suffer from this property: It reduces the size most of the time but the compressed version is never bigger than the original (not even by one bit).

    1 Reply Last reply
    • HoraceH Offline
      HoraceH Offline
      Horace
      wrote on last edited by
      #2

      I don't think so. It's tempting to say that if the compressed size was larger, you'd just switch to an identity compression algorithm, but you'd have to add info to the 'identity compressed' data to indicate that it's unaltered from the original. That information can't be carried at zero size.

      Education is extremely important.

      KlausK 1 Reply Last reply
      • jon-nycJ Online
        jon-nycJ Online
        jon-nyc
        wrote on last edited by
        #3

        Seems like it’s impossible based on the pigeon hole principle alone. If the mapping of uncompressed to compressed is reversible then some files must be larger.

        "You never know what worse luck your bad luck has saved you from."
        -Cormac McCarthy

        KlausK 1 Reply Last reply
        • jon-nycJ jon-nyc

          Seems like it’s impossible based on the pigeon hole principle alone. If the mapping of uncompressed to compressed is reversible then some files must be larger.

          KlausK Offline
          KlausK Offline
          Klaus
          wrote on last edited by
          #4

          @jon-nyc said in Puzzle time: Compression:

          Seems like it’s impossible based on the pigeon hole principle alone. If the mapping of uncompressed to compressed is reversible then some files must be larger.

          Exactly. There is no bijection between sets of different cardinality.

          1 Reply Last reply
          • HoraceH Horace

            I don't think so. It's tempting to say that if the compressed size was larger, you'd just switch to an identity compression algorithm, but you'd have to add info to the 'identity compressed' data to indicate that it's unaltered from the original. That information can't be carried at zero size.

            KlausK Offline
            KlausK Offline
            Klaus
            wrote on last edited by
            #5

            @horace said in Puzzle time: Compression:

            I don't think so. It's tempting to say that if the compressed size was larger, you'd just switch to an identity compression algorithm, but you'd have to add info to the 'identity compressed' data to indicate that it's unaltered from the original. That information can't be carried at zero size.

            That’s why I added the condition that it cannot be even one bit larger. With one extra bit it would be trivial, as you describe.

            1 Reply Last reply
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Users
            • Groups