On 2/27/2012 10:08 PM, Julian Leviston wrote:
Structural optimisation is not compression. Lurk more.

probably will drop this, as arguing about all this is likely pointless and counter-productive.

but, is there any particular reason for why similar rules and restrictions wouldn't apply?

(I personally suspect that similar applies to nearly all forms of communication, including written and spoken natural language, and a claim that some X can be expressed in Y units does seem a fair amount like a compression-style claim).


but, anyways, here is a link to another article:
http://en.wikipedia.org/wiki/Shannon%27s_source_coding_theorem

Julian

On 28/02/2012, at 3:38 PM, BGB wrote:

granted, I remain a little skeptical.

I think there is a bit of a difference though between, say, a log table, and a 
typical piece of software.
a log table is, essentially, almost pure redundancy, hence why it can be 
regenerated on demand.

a typical application is, instead, a big pile of logic code for a wide range of 
behaviors and for dealing with a wide range of special cases.


"executable math" could very well be functionally equivalent to a "highly compressed" program, but 
note in this case that one needs to count both the size of the "compressed" program, and also the size of the 
program needed to "decompress" it (so, the size of the system would also need to account for the compiler and 
runtime).

although there is a fair amount of redundancy in typical program code (logic 
that is often repeated,  duplicated effort between programs, ...), eliminating 
this redundancy would still have a bounded reduction in total size.

increasing abstraction is likely to, again, be ultimately bounded (and, often, 
abstraction differs primarily in form, rather than in essence, from that of 
moving more of the system functionality into library code).


much like with data compression, the concept commonly known as the "Shannon 
limit" may well still apply (itself setting an upper limit to how much is 
expressible within a given volume of code).
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Reply via email to