Could I be the Emperor of Greece (My Thoughts on the Crisis in the EU)

     First a pair of disclaimers:
1. The title of this post is probably a little off-putting if you are a Greek citizen. But I only say it because, imperial fiat is about the only way all of this would happen.
2. I'm not an economist, or expert in Greek/EU laws and there are probably several problems with what I'm going to say.

    The Greek economy needs to be reset, rebooted, whatever you want to call it. There are two main problems that I am aware of. First the level of spending, and entitlements of the Greek government. Second the population's aversion to taxes (of course everyone hates taxes). My suggestions would be this: Tear up your tax code, which would probably be difficult as a EU member. In replace all of the income taxes, value-added taxes, inheritance taxes, corporate taxes, the whole shebang with a single, inclusive retail sales tax. That is the top X% of the sales price of all goods, and service at the retail level would be sent to the government. This tax would be displayed as part of the price of the goods and not added on at the cash-register.
   Second completely eliminate all the entitlements to the citizens, all pensions, food assistance, unemployment insurance, all of it, and replace them all with a national income. That is ALL citizens of Greece living in the country would receive a minimum salary from the government. This salary would be enough income to take their citizenry to the poverty line. There would be no means testing, no complications, just a fixed check going to each of age citizen living in the country. Coupled with this would be the liberalization of the job market. Closed professions would need to be opened, wage fixing would need to be repealed.
    Many would balk at the lack of means testing, but I believe that this makes the law more difficult to game. And for the rich the extra income would be a drop in a bucket, and would probably not change their behavior any, if at all. For the poor this would be a great boon, to suddenly not have to worry about where their money is coming from. Also without the means testing the poor, and middle class have a strong incentive to work, income from jobs does not threaten their check from the government. So every extra dollar they make is truly theirs, and can be used to  increase their standard of living.
    The reason for the retail sales tax is one of transparency. Taxes levied on businesses are passed through to the customer, but are hidden in the price of the good they purchased. By only levying the taxes at the retail level determining your taxes becomes as easy as Total * X% = Taxes paid. So there would need to be a system to identify business expenditures, to remove the tax from them. This also reduces the number of points of tax collection from every citizen to just retail businesses. Which should make such a system easier to police just because it's relativity smaller group. Also this allows the Greeks to shift a portion of their tax burden onto foreign tourist, in the way that the state of Florida loves to shift their burden onto other state's citizens in the US.

Taxes

CSB time... One of my sisters once had to memorize a poem as a homework assignment. She chose "Homework, oh homework" by Shel Silverstein and, I believe, to this day can still recite parts of it. Well earlier today I was struck by inspiration to try and write a somewhat more adult version of that poem:

Taxes, oh taxes I hate you, you stink.
If I don't pay you I'll end up in the clink.
Gobs of figures and little fiddly bits,
taxes oh taxes you've just too many nits.

I'd rather go see a loan shark,
or sub my toe just for a lark.
Attend meetings galore, and repeat them ten times,
than tackle the taxes my government assigns.

Taxes oh taxes YOU'RE LAST ON MY LIST.
Though I can see why you exist.
If you were just simpler it would tickle me pink.
Taxes oh taxes I hate you, you stink.

Can you guess what I was doing today class?.... I knew you could.

Hoof-beats

"When you hear hoof-beats behind you, don't expect to see a zebra." Is a common charge used in medicinal circles (or so I'm told). It applies equally well to debugging. For several weeks I was looking for a bug. This one bug was blocking the customer's in house testing from continuing, so on several occasions I went looking for it. We tested and poked and pondered, but no cause for the bug was apparent. To make it worse we could not reliably reproduce the problem. I was racking my brain for ways this might happen, and the scenarios got more and more far fetched. We verified hardware, checked versions everything was matching between the customer's environment and ours. Well we finally got the customer to send us the piece of hardware they were using, setup in the way they were using it. Low and behold the problem became apparent. The hardware was using a 3rd party service that the hardware had to be set up with. Well the test account they were using and the one we were using were setup different. I could have kicked myself. So when a bug is entrenched, seems to be growing horns and taunting you remember its probably a horse not a zebra.

wrung out YAML

Because of a project at work I have recently become interested in compression algorithms. The only one I was exposed to at school was the famous Huffman Algorithm which is often used as an archetypal greedy algorithm. In particular we need to compress some very small YAML documents, at most a thousand bytes or so for transmission over modem channels. Yes the dinosaur dial up kind.

So we went looking so far we have tried LZW, the Burrows-Wheeler transform followed by run length encoding and a really simple one called Byte Pair encoding. LZW does not have time to really get going before it runs out of data and ends up increasing the size of the message. BWT-RLE gives us some savings but the very simple byte-pair-encoding seems to be winning the day right now.

The algorithm is easy. Basically you count how many times each pair of bytes is in the message, you replace the most often occurring one with a byte that does not appear elsewhere in the message. The pair must appear at least 4 times to get any savings. The way my particular implementation the expansion dictionary is pre-pended to the message. The algorithm runs multiple passes over the data and the dictionary is pre-pended at the end of each round. Which means the dictionary is subject to compression of it's own.

That leads to some interesting recursive compressions many times. A length 3 string repeated 4 times ends up compressing from 12 to 10 bytes:

 round 1: abcabcabcabc
 round 2: ZabZcZcZcZc
 round 3: YZcZabYYYY

which does not seem very good. But the empirical evidence so far says that this simple compression scheme works very well. At least on YAML.

MICR madness

Have you ever looked at the bottom of a check? Ever noticed that string of characters in a weird blocky font? Well that's a MICR line. MICR stands for "Magnetic Ink Character Recognition" and is a technology hailing from the 50's. Its sort of interesting actually. At the time digital cameras were unheard of, CCD was probably at best glimmer in some researcher's eye. But banks wanted a way for computers to get information off check without human intervention. So MICR was developed.

MICR reads the signature of the magnetic ink and uses it to recognise characters of certain specially designed fonts. That part of the technology works beautifully. There numerals and a few special characters in the MICR fonts being deemed sufficient to encode the information on a check. However something smells in the world of MICR.

The standard format for a MICR line in the United States is too lax for my taste. There are two common formats for MICR lines personal checks (anything other then a number is a special MICR character translated to ASCII):

:111111111: 2222222< 3333 ;44444444444;

Field 1 would be the routing number which is the most tightly controlled of the fields. It is an ABA number, has a check-sum and is pretty reliably just like I typed. Field 2 is the account number, and three the check number. These two have all kinds of problems. Field four is an optional amount of the check. That is what most personal checks look like. Business checks generally take the form:

<3333< :11111111: 2222222< ;44444444;

With the field numbers being the same thing as in the personal check.

This is all well and good. If that was the whole story things would be easy. But things are rarely so easy. Many banks, especially community banks, printed their checks with just about any format of the above fields they could come up with. Now the routing number and amount are consistent (they were specified by the original spec) but the order of fields, what separators are used where, where there are spaces and everything else seemingly nearly random. So producing a parser that can understand even a small subset of the checks in circulation can be a pretty good task.

If you can't tell I've been fighting the things lately and am a little frustrated. There is still a good bit of time spent by tellers hand-keying check information because of this wonky bit of banking history. Too bad the ABA did not come up with a much more exact specification allowing easy interoperability between banks. Of course some of the checks I've seen do not even follow the layout that the MICR standard did create, so the problem would still exist. However that's life.

The power of plain text

I am going to echo something from one of my favorite books about programming. In the Pragmatic Programmer a recommendation is made: Pick an advanced text editor and use it! Really learning an advanced text editor pays dividends, not only coding speed but in reduction of hand strain. Personally I use VIM as my text editor of choice but what editor really does not matter.

Try:

• VIM
• Emacs
• Notepad++
• Slickedit
• etc.

But the impotent thing is to pick one and learn it. Really spend some time in the learning it. I cannot count how many key strokes that VIM has saved me with things like:

• :s/[ \t]+$//g
• A,j.j.

The first eats all white space at the end of all of the lines in a file, the second inserted a comma at the end of three lines. In fact the '.' command is my absolute favorite in VIM it means repeat the last edit command again.

Learn how to customize your environment also VIM has it's scripting language (there are versions that can use Lua, Python and other scripting languages too). Emacs has a full blown LISP interpreter that can do anything you want it to. But the most important thing is to stick with it. If your company requires you use this IDE or that editor then learn that one like you would your main editor. your editor is your tool as a hammer to a carpenter or a brush to an artist, treat it with the respect any good professional treats his tools of the trade.

Cowabunga!

A while back in my Turtle Power! post I mentioned some fractals that I thought suitable for use teaching beginning programmers. I thought that I would present the code written to generate one of them, specifically the Levy C Curve. The code specifies the fractal as a L-system. Basically you start with a string of symbols then use certain rules recursively expand the string. Each symbol in the string becomes an instruction and the string itself a program for drawing the fractal. The Dragon Curve is generated in the same way. It simply has a slightly different formula.

The structure of an an L-system lends itself to implementation with very basic structures. The code below uses only two non-nested loops and a mulitway branch to do all its work. So I feel that it (and any L-system fractal) make good teaching material for control structures.

The C Curve's formula is this:

Start: "F"
Rules: "F" becomes "+F--F+"
Symbol meanings:
F - draw forward
+ - turn clockwise 45 degrees
- - turn counter-clockwise 45 degrees

And the required python code is:

import turtle 

SEGMENT_LENGTH = 2 
WINDOW_WIDTH = 772 
WINDOW_HEIGHT = 501 

if __name__ == "__main__": 

    move_list = "F" 

    for i in range(15): 
        move_list = move_list.replace("F", "+F--F+") 

    turtle.setup(width=WINDOW_WIDTH, height=WINDOW_HEIGHT) 
    turtle.tracer(False) 
    turtle.up() 
    turtle.goto(-180, -135) 

    turtle.down() 

    for i in move_list: 
        if i == "F": 
            turtle.forward(SEGMENT_LENGTH) 

        elif i == "+": 
            turtle.left(45) 

        else: 
            turtle.right(45) 

    turtle.Tkinter.mainloop()

Which is amazingly short for the complex beauty of the drawing it produces. That code was produced before the last major version number update of python and has not been upgraded. I think it will run with a new python installation but it might not.

Any numbers not mentioned in the curve formula are "Magic" (i.e. I fiddled with them until they produced a good looking picture). The structure should be obvious the first thing I do is produce the "program" to draw the curve using nothing but iteration and sub-string replacement. The rest of the program is the mini interpreter that takes the program and draws the picture. Remember the more times you iterate the string replace the more complex the fractal becomes. So go ahead and play with that a little and see what you think.