Hierarchy Of Information Loss

I think there is a hierarchy of InformationLoss going from lossless to total loss, about as follows (examples in brackets):

• A) Fully isomorphic transformation (identity, encryption, lossless compression)

• B) Redundancy
  • B1) Adding redundancy (adding checksum, LF->CRLF)
  • B2) Removing redundancy (removing checksum, CRLF->LF)

• C) Semantics
  • C1) Without loss of semantics but only change to human aesthetics (pretty printing)
  • C2) Without loss of semantics but only change to "machine aesthetics" (normalization)

• D) Functionality
  • D1) Without objective functional loss (removing of comments, CeePreProcessor)
  • D2) Without subjective functional loss (jpeg compression above visual detectable level)

• E) Lossy, only parts of the information are retained (compiler, javadoc)

• F) No relation to the original data.

I think, that different kinds of InformationLoss should be treated differently by us and our tools.

-- GunnarZarncke

I agree if we disregard the meaning of useful information. According to my definition of "information loss" as "loss of useful information", all mentioned above cases don't cause "information loss". In the case of jpeg images, we compress them only if extra information is not useful for a specific purpose. In the case of a compiler, all variable names or comments are useless for program execution (unless we need to debug it). More than that, all those mentioned cases cover only secondary information, because humans usually don't edit compressed jpeg images or compiler output or JavaDoc output.

-- AlekseyPavlichenko

1. So, Aleksey, you are now saying: "We must never discard useful information." Isn't this completely obvious?
2. For reference, some humans do edit compiler output. What output? Some compilers will output AssemblyLanguage files, which can be hand-edited (if you're that desperate).

---

I agree that it seems obvious, but something like "Refactoring brings discarded useful information back into the code" or "CopyAndPaste discards useful information" doesn't seem as obvious.

Now as I think about your example about editing compiler output: by editing compiler output you discard useful information (information about your ability to recompile or if you recompile information about your edits). It may not be obvious for people that editing compiler output is a bad thing to do, but something like "We must never discard useful information." can make them think about it and prevent them from doing it. Of course, if you don't have source code and try to crack binary output, then you don't have anything to lose and in that case it's not bad to edit binary files.

Think about "We must never discard useful information." as a helpful test when designing software. It's obvious, but very often people don't follow it, disregard it, don't trust it or make it the lowest priority of consideration. I think that this principle should take highest priority during any system design, higher than any other design rules such as OOP/OOD, normalization or anything else. If someone wants to make a good OOP design, violating "We must never discard useful information.", then he is doing a BadThing.

-- Aleksey