equal-hash

[Tom Gordon]

I'd like to request that equal-hash, of the (rnrs hashtables) be implemented soon. (We now need it for our Carneades system.)

[Abdulaziz Ghuloum (aghuloum)]

I'm afraid equal-hash won't be implemented as per the explanation in
  https://answers.launchpad.net/ikarus/+faq/276

In short, you can write a better hash function for your data than I can (since mine would have to be generic and would very likely suck for all data). I would be doing everybody a disservice if I provide a sucky implementation.

Aziz,,,

[Tom Gordon (tom-gordon)]

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.

-Tom

On May 24, 2009, at 11:24 AM, Abdulaziz Ghuloum wrote:

> I'm afraid equal-hash won't be implemented as per the explanation in
> https://answers.launchpad.net/ikarus/+faq/276
>
> In short, you can write a better hash function for your data than I
> can
> (since mine would have to be generic and would very likely suck for
> all
> data). I would be doing everybody a disservice if I provide a sucky
> implementation.
>
> Aziz,,,
>
> --
> equal-hash
> https://bugs.launchpad.net/bugs/378625
> You received this bug notification because you are a direct subscriber
> of the bug.

[Abdulaziz Ghuloum (aghuloum)]

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,,,