Cosas curiosas...

Estas dos cadenas, de una prueba de 400,000 datos tienen una cosa en común.

0,0,0,0,0,0,2,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

Aplicandoles una funcion de HASH, dan el mismo resultado, aplicandoles un re-HASH vuelven a dar el mismo resultado, con una suma de sus caracteres multiplicados por la posición dan el mismo resultado, ¿interesante no?, obviamente matemáticamente hay altas probabilidades de que pase, pero en la vida real y con los datos con los que trabajamos eso no debe de pasar. Por el momento se quedará como un triste BUG, porque si recalculo el re-HASH con otro valor nadie me quita la incertidumbre de que vuelva a pasar, y solo recordar que esa cadena genera el mismo valor con tres funciones que "deben de dar" valores distintos. Además en una aplicación probabilistica siempre se debe tener un margen de error. 1 de 400000 es muy bajo, si se sigue por ese camino tendria alrededor 5 o 7 errores en 5,000,000 de datos (espero).


Hablando sobre apegarse a estandares, errores curiosos y experiencia, si usan postgresql lean esto NOT IN, NULLs and JOINS
Y como bien termina el artículo: "The above behavior is correct per spec. Feel free to argue its consistency with the SQL committee ;-) "

Nota: La aparición del bug coincidio con otra cosa igual de nefasta, ba... sigo sin creer en las coincidencias.