I’ve been reading a strange book called ‘De Broncode’ (The source code) by Eric Smit. It’s not the book as such that’s strange (although the style of writing is not 100% my thing), but the subject matter that is rather peculiar. It’s the true story of the Dutch TV repair technician Jan Sloot who claimed to have invented a revolutionary method for storing data in as limited a storage space as possible. It began in 1984 when he started using his PC for keeping a kind of knowledgeware system which held data on TV’s and how to repair them. One needed only to state the brand, type and the failure symptoms, and ‘Repabase’ gave you a comprehensive repair method. He soon discovered that storage was a big limitation for his system. It took him almost 11 years to discover a method for reducing data in size. He deliberately didn’t speak about compression since that was not the same thing in his opinion. He ‘encoded’ the data in a shorter form. It didn’t stop with this discovery. Since Sloot was into TV’s, he wondered if he couldn’t apply his discovery to videos. So he went back to his messy attic to start work on that and soon found a solution for that too. He claimed that he could fit a whole movie, and even a hundred or more, on a single chip card of 128K. He could do this by storing the movie itself on the card, but merely by storing the information pertaining to toning, patterns and other properties and so reducing size by a factor of (roughly) 2 million. I won’t go any further into this topic in order to prevent possible misunderstandings due to errors of translation and so on. Suffice it to say that if you understand Dutch, you can read the patent, the book, the site or watch the documentary for extra info.

##### Dream gone.

The more ingenious a technician Sloot became the worse off his life became on both the social and, most importantly of all, business fronts. His TV repair shop went bust several times and he was continuously in debt. He needed investors, which he managed to find, in order to solve his financial problems. Some of these investors were more dubious than the others, but after a couple of years the “beau monde” of investors and IT people got involved in the project. And then suddenly all this was brutally brought to an end on July 11 th 1999 when Jan Sloot dropped dead in his garden of a heart attack. This was just the day before he was due to sign a billion dollar contract in exchange for his invention. The strange thing is that the messy attic was found spotlessly clean, and not a single sign or reference to his invention has ever been found. The big invention and dream vanished together with Jan Sloot. The book suggests that all of this couldn’t have been coincidental and suggests a conspiracy theory with a certain investor in the main role.

##### First publication.

Now I am in two minds as to whether any of this is true, or whether the invention ever even existed, but I’m mentioning all this since it lead me to the idea of the small footprint. In the second half of the 80’s I was passionate about small and efficient programs (for much the same reasons as Jan Sloot). In fact the first international publication of a source code of mine occurred in 1989 and looked like this:

K# = 2

FOR I = 2 TO 200000

K# = K#*2

IF LEN(STR$(INT(K#)) > LEN(STR$(INT(I))) THEN K# = K#/10

IF INT(K#) = I THEN PRINT I

NEXT

This little QBASIC program solves the following riddle: determine all numbers X between 0 and 200000 where the result of 2 to the power X starts with X. Eg. 2^6 = 64, 2^10 = 1024. The program gives you 6, 1542, 77075 and 113939 back.

##### Need for speed.

Another important factor in those days was the language you chose. Yes, back in the 80’s the discussion on which language the best was for applications was hot. The conclusion was always that there was no single ideal language, and that it all depended on the application one wanted to build. More important to me was how the algorithm was written. Take for instance the following riddle (which was also published in that article): which 6 digits numbers can be split in to two numbers of three digits in such a way that if you calculate the sum of those two numbers and determine the square of it, you obtain the original number. In other words: ABCDEF should be (ABC + DEF) * (ABC + DEF).

Back in the old days it took 21 minutes and 13 seconds with a QBASIC program, and 4 minutes and 50 seconds with a Turbo Pascal version. However if you replaced the single loop with two loops, thereby leaving out the MOD and DIV calculations, it only took 50 seconds. In order to clarify things (and for the fun), here’s the ABAP version :

REPORT ZCALCULTEST.

* slow loop

data: number type I, head type I, tail type I, result1 type I, result2 type I.

number = 100000.

write / sy-uzeit.

while number le 999999.

head = number div 1000.

tail = number mod 1000.

result1 = ( head + tail ) * ( head + tail ).

if result1 eq number.

write / number.

endif.

number = number + 1.

endwhile.

write / sy-uzeit.

* efficient 2 loops

head = 100.

write / sy-uzeit.

while head le 999.

tail = 0.

while tail le 999.

result1 = head * 1000 + tail.

result2 = ( head + tail ) * ( head + tail ).

if result1 eq result2.

write / result1.

endif.

tail = tail + 1.

endwhile.

head = head + 1.

endwhile.

write / sy-uzeit.

##### Size does matter.

Both versions will show you the numbers 494209 and 998001 within a second. The latter may indicate that the way you write your program isn’t of any importance anymore due to the ever improving performance of the machinery. Despite that, nice, small and READABLE code still makes my day. I suppose it’s because I was raised like that, but it’s still important to me. Resources may seem unlimited these days but efficient small code still seems like a good idea to me.

It just memorizes me a situation I trapped myself:

Back in ~1990 I’ve been at local programming Olympiad where we had task to find how many possible valid combination could be composed from N pairs of parenthesis “(“ / “)”. As far as I know Pascal & C, I preferred to use recursion just to iterate all valid combinations. Sadly enough, tests contain cases up to N = 19, and my program was simply hanging on anything greater then 14 (ok, it works more then time frame given, 3 minutes AFAIR. Do anyone remember CPU speed of those days ;-).

But there were guys who knows only Basic and therefore had no option to use recursion. This force them _to think_. I do not remember the exact algorithm, but in fact the result value correspond to one of coefficients of (a + b) pow N expansion and could be found linearly.

Sometimes I have a strong feeling that the more power developers have with tools / libraries / language the less attention is given to mathematics, algorithm, and, as consequences, efficiency. And that is really sad.

VS

The purist in me agrees with you, but often I feel that too much emphasis is put on “elegant” solutions that are highly efficient, but often more complex than they need to me.

In a world where business requirements and the resources who need to deliver them change often, in my mind the emphasis should be more on maintainability. Is the program easy to understand, and can somebody other than the original author maintain it?

So when developing, I prioritise in the following sequence:

– Does it work?

– Is it simple?

– Can it be changed easily?

– Is it efficient?

– Does it take advantage of new technologies?

I think this is particularly true of ABAP developments, where normally you are extending an existing application (R/3) rather than writing from scratch (where I believe there is more of a need to optimise design).

Brad

I remember you talking about the story at SDN Meets Labs. Nice to get some pointers. Searching for his name I stumbled over this recount of the story: http://www.cs.unimaas.nl/p.spronck/Sloot.htm

Love the alien tale in it: “There is a story (I can’t remember who told this story first, but it was probably Martin Gardner) about an alien that lands on Earth. The alien wishes to return home with the knowledge of all books on Earth. Unfortunately, his spaceship is so small that he can only take with him a small stick. So what he does is the following. First, he digitizes each book. This translates each book in one huge, but finite, number. Then he attaches all these numbers to each other, which results in an enormous, but still finite, number. In front of this number he places “0.”, turning it into a fraction between zero and one. Setting the length of the stick to one, he makes a small cut in the stick at precisely the fraction. When he returns home, he only needs to measure the place of the cut, to get back the fraction, and thus the number, and thus the codes for all the books.”

Best, Mark.

But remeber: The question is “What’s SIX multiplied by NINE?”<br/><br/>–

<br/><br/>#include <stdio.h><br/>#define SIX 1 + 5<br/>#define NINE 8 + 1<br/><br/>int main(void)<br/>{<br/> printf( “What do you get if you multiply %d by %d: %d\n”, SIX, NINE, SIX * NINE );<br/> return 0;<br/>}<br/><br/>—

<br/><br/>(copied out of the englisch Wikipedia)