inverse document frequency failed due to failing _count approach and due to weird urllib timeouts in naive approach...
added stddev and shifted both to lemmas level
DO NOT EVER USE DEFAULT ARGS. O MY GOD PLEASE NOT.
Also I dont know whether this is a bug. But
its dfinitely confusing.

Interestingly, the hashes were all the same!
(one of their characteristic values)
The first list is while inserting them into a list.
The second one is while reading them again lateron.
The number behind that is its index.

> 0 0.412698412698
> 1 0.474019088017
> 2 0.452905811623
> 3 0.431672025723
> 4 0.628099173554
> 5 0.724358974359
> 6 0.44
> 7 0.743243243243
? 0 0.743243243243
? 1 0.743243243243
? 2 0.743243243243
? 3 0.743243243243
? 4 0.743243243243
? 5 0.743243243243
? 6 0.743243243243
? 7 0.743243243243 <- all equal?!

But change this:
def statistic_hash(text, h={}):
    ...
to
def statistic_hash(text):
    h = {}
    ...

et voilá

> 0 0.412698412698
> 1 0.474019088017
> 2 0.452905811623
> 3 0.431672025723
> 4 0.628099173554
> 5 0.724358974359
> 6 0.44
> 7 0.743243243243
? 0 0.412698412698
? 1 0.474019088017
? 2 0.452905811623
? 3 0.431672025723
? 4 0.628099173554
? 5 0.724358974359
? 6 0.44

It works. I am soooo happy to have solved this problem.
Now please, remember this the next time use or see someone using
default pyhton arguments.
added check for update in hash updates. overrideOld::Bool
added simple euclidic distance based on avg/stddev over complexity and word size. the bug really took the time....