[Omake] Lm_hash: hash_length is different from the length of hash_data?

[Aleksey Nogin]

No, not quite.

The relevant code is:

       let code = (...) mod hash_length in
          for i = 0 to digest_length - 1 do
             digest.(i) <- ... lxor (Array.unsafe_get hash_data (code + i))
          done;

So unless I am missing something again, the hash_data needs to have the 
length of hash_length + digest_length - 1, which is 6232, and the last 
17 entries are unused.

---

Another question - in the two versions (Code, Digest) of the add_bits 
function we start with

... (code + i + 1) land 0x3fffffff ...   or
... (code + i + digest_length) land 0x3fffffff ...

Given that code is between 0 and hash_length - 1, and i is a byte, the 
sum will always be small - so is there any purpose to having the land 
operation here? Do you anticipate calling add_bits from somewhere else 
(outside of the Lm_hash) with larger inputs?

---

Also - is there any reason why in HashDigest we maintain a 16-ints-long 
hash_digest array and then only use the last byte off each int? As 
opposed to, say, using a 8-ints-long one and using the last 2 bytes? 
Wouldn't that be faster?

---

Finally, is the HashDigest actually used somewhere? As far as I can 
tell, it is not used on the current 0.9.8.x branch, perhaps it's used 
somewhere in the 0.9.9.x stuff?

Aleksey

On 20.03.2007 09:33, Jason Hickey wrote:

> This is intentional, because the index is taken mod hash_length, and 
> then used as a 32-byte value.
> 
> Jason
> 
> On Mar 20, 2007, at 9:20 AM, Aleksey Nogin wrote:
> 
>> Jason,
>>
>> I've noticed that in Lm_hash, hash_length is 6217, but hash_data has 
>> length 6249 (so the last 32 entries are unused?). Is this intentional?
>>
>> Aleksey
>>