Bill writes: > WHICH MEANS, the spec needs a precise, detailed, and > humanly-intelligible description of the closeness metric/algorithm. > I'm not sure I really understand it, even after reading the source, > so I'll go willy-nilly here and propose one: simply order the keys by > alphabetical order, with "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"'s > (or "zzzz....") wrapping around to 0. It's an easy order to explain, > and is moderately close to what the code seems to use now -- assuming > an evenly distributed keyspace, a series of "close" guesses by the two > algorithms will have about half of their keys in common.
The code appears to use closeness of Unicode character values, starting with the first character, then if that is a tie going on to the second character, and so on. This is similar to an alphabetical comparison except it is case sensitive and of course deals with non-alphabetic characters. The handling of different-length strings is non-intuitive. The same rule is applied except that characters beyond the end of the string get treated as 0. So comparing "a" to "ab" or "ac", it is closer to "ab" because 0 is closer to 0x61 than to 0x62. Comparing "a0" to "a" or "ab" it is closer to "a" because 0x30 is closer to 0 than to 0x61. However comparing "a1" to "a" or "ab" it is closer to "ab" because 0x31 is closer to 0x61 than to 0. Hal _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
