> Dear Aziz,
>
> OK. Thanks. Sure I guess I can roll my own hash function. But you
> might want to reconsider your policy nonetheless. To avoid questions
> like mine and possible complaints about not fully complying with the
> R6RS, why not implement equal-hash with the good but slow algorithm
> and provide a caveat or recommendation in your user manual? In this
> case I think you can have your cake and eat it too.
I have considered this many times already. 1. Nobody reads the manual.
2. People would rightfully assume that I've written the best function
possible (i.e., good *and* fast) while in fact I would have to choose
one or the other. 3. The performance of your application will suffer
(and you'd think ikarus sucks) due to using a slow hash functions. 4.
I think a poor-but-fast (lambda (x) 0) hash function will perform
better overall in most situations than a good-but-slow hash function
(try it! you'd be surprised.).
Anyways, maybe a better compromise is to provide a collection of hash
functions (poor-but-fast, good-but-slow, etc.) that people can choose
from instead of providing the-one-equal-hash function that's never
good for all situations.
On May 25, 2009, at 11:06 PM, Tom Gordon wrote:
> Dear Aziz,
>
> OK. Thanks. Sure I guess I can roll my own hash function. But you
> might want to reconsider your policy nonetheless. To avoid questions
> like mine and possible complaints about not fully complying with the
> R6RS, why not implement equal-hash with the good but slow algorithm
> and provide a caveat or recommendation in your user manual? In this
> case I think you can have your cake and eat it too.
I have considered this many times already. 1. Nobody reads the manual.
2. People would rightfully assume that I've written the best function
possible (i.e., good *and* fast) while in fact I would have to choose
one or the other. 3. The performance of your application will suffer
(and you'd think ikarus sucks) due to using a slow hash functions. 4.
I think a poor-but-fast (lambda (x) 0) hash function will perform
better overall in most situations than a good-but-slow hash function
(try it! you'd be surprised.).
Anyways, maybe a better compromise is to provide a collection of hash
functions (poor-but-fast, good-but-slow, etc.) that people can choose
from instead of providing the-one-equal-hash function that's never
good for all situations.
Aziz,,,