Bon voilà, hier en surfant sur freshmeat, je tombe sur ça : http://FreeDaemonConsulting.com/tech/hzip.php
Et donc je m'empresse d'envoyé le mail suivant au concepteur :
>For every 256 bytes of input, 30 bytes of output result, guaranteed. The big
>challenge that lies ahead is to 'verify' this works for all possibilities of
>bits (2^256 verifications).
Yes that 's what an hashing algorithm is supposed to do... I don't understand
well what you are doing..? It's 100% sure that for every 256 bytes string
you'll get a shrinked result... but that only means that there exists some
collisions... more than one 256 bytes length string shrink into the same 30
bytes length string... because a hashing function is injective unlike a
compression algorithm which is bijective... that also means that a given
compression algorithm can't compress all input... this is the countable
argument.. you associate elements from a bigger set to a smaller set... not
all elements from the bigger set can have a counterpart in the smaller set...
if all elements have a counterpart, that means either there exists
collisions, or the two set are equals (that also means not all input are
shrinked but some of them are bigger).
Dont voici la réponse :
Thanks for the input. You and others have given me an introduction to number
theory and the reasons why my algorithm doesn't work, in theory. While I
concede that it is a true statement, I'm wanting to determine where my
algorithm fails, so I can make it work for the general case, and perhaps
expand a data structure or two in the specific cases where it does break
Todd Fries .. /////
Free Daemon Consulting, LLC Land: 405-748-4596
http://FreeDaemonConsulting.com Mobile: 405-203-6124
"..in support of free software solutions."
Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
(last updated 2003/03/13 07:14:10)
J'en ris encore...