Michael Spencer wrote: > Claudio Grondi wrote: > >> ...I analysed the outcome of it and have >> come to the conclusion, that there were two major factors which >> contributed to squeezing of code: >> >> (1). usage of available variants for coding of the same thing >> (2). sqeezing the size of used numeric and string literals >> > ....not only squeezing the size of the literals, but the combined size > of the compressed data and the code to expand it. In this respect it > turned out to be a surprisingly rewarding challenge, and a nice > reinforcement of the Pythonic mantra of seeking performance gains by > optimizing algorithms. > > Michael > You are right. I have overseen that aspect which makes the contest a kind of Python scripting language related compression challenge.
I haven't done it yet, but I consider it interesting to check out how compression algorithms are doing on the three lines 7 segment LCD mimicking text representations of a decimal number generated by seven_seg() compared to size of input string plus the size of the module. I suppose, as the input string is not of minimal possible size compared to the information it carries, compression schemes should be able to beat the 'compression' by seven_seg(). Interesting in this context for me is also, that if I understand it right, according to Kolmogorov complexity law, it will be never possible to state if the achieved solution is the shortest possible as it will be also not possible for any other provided (shorter) solution. Claudio -- http://mail.python.org/mailman/listinfo/python-list
