From looking at the Java code (Key.java:126) it seems that it takes each byte of the key in turn and sees which key's byte is closer. So given 3 keys:
A e6993db3f66061a8d847fabb653e98f9 B e8464f46af5eaf52aa53a2099295667c C e8c45a48297de8029d2ed1afeca72e2e B is closer to A than C because A&B have the same first byte but at the second byte 0xc4 is closer to 0x99 than 0x46. Firstly am I right in saying this? If not please correct me and ignore the rest of this. I'm asking this because I linked in my old Store testing today and it failed. I've copyed the Java code for Key closeness, but wasn't really thinking about it when I wrote the Store. Oskar described this system as lexographic - which was what I was thinking when I wrote Store. But in a lexographic system as I understand it (which is likly to be worlds away from any real defination) B would be closer to A than C because of the first byte (think alphabetic ordering). If we had a lexographic system then Store::find_closest can be implemented with a B-tree giving O(log2) otherwise it needs to be linear giving O(n). It's possible that you can use a tree of the above for find_closest, but a B-tree doesn't work. Some very high dimentional BSP tree might work, but even if it does it'll be a bitch to code. Any chance we could switch to a dictionary ordering and all enjoy O(log2 n) closest lookups? AGL -- In an orderly world, there's always a place for the disorderly. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000815/3d52ca15/attachment.pgp>
