Peter L. Peres wrote: > On Thu, 22 Oct 1998, Tjaart van der Walt wrote: > > > 1) Four hash functions are implemented. > > 4) I keep the last three characters received, so I can copy these when I > > have a hit, or constantly check for a marker ( in my case). > > 2) All hash functions are cleared on a marker () > > 3) I only compare one hash function on every character received. If it > > matches, I also check for the other three. > > > > Here are my functions : > > > > RRF(RX_Hash_3); > > RRF(RX_Hash_4); > > RX_Hash_1 ^= RX_Character; > > RX_Hash_2 += RX_Character; > > RX_Hash_3 ^= RX_Character; > > RX_Hash_4 += RX_Character; > > imho you are over-doing it a little bit. Concentrate on one hash function > and make it better. Since you have a 4 bytes/entry table, use a 31 bit > hash number. If you throw dictionary English words at that you'll spend a > few centureis typing until you hit something duplicate. I've used 13 bit > wide tables for 100-word dictionaries using only xor and shift with no > collisions. The (worst) probability for a double hit is 100/(2^13-99) = > 100/8193 ~= 1.3%. Is there a non-brute-force method of estimating the chances of a double hit? I wouldn't like to spend too much time in 'hashing' or comparing. Currently I only have to compare RX_Hash_1 (which is quite fast). I only test the other functions after a hit on RX_Hash_1. > Note that hash-matching without comparing affects the > S/N ratio of the input (or the noise immunity and robustness of your > system). What do you mean by this? -- Friendly Regards Tjaart van der Walt mailto:tjaart@wasp.co.za |--------------------------------------------------| | WASP International | |R&D Engineer : GSM peripheral services development| |--------------------------------------------------| |SMS mailto: tjaart@sms.wasp.co.za (160 chars max)| | http://www.wasp.co.za/~tjaart/index.html | |Voice: +27-(0)11-622-8686 Fax: +27-(0)11-622-8973| | WGS-84 : 26¡10.52'S 28¡06.19'E | |--------------------------------------------------|