[
https://issues.apache.org/jira/browse/LANG-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757502#comment-13757502
]
Allon Mureinik commented on LANG-804:
-------------------------------------
There are two issues here:
The original issue - is there any point in explicitly checking (and
documenting) for zero?
Probably not, as you stated in the original case, and as my proposed patch
solves.
Should the ctor allow negative coefficients?
With the given algorithm, the proper way to ensure that there are a minimal
amount of clashes is to use two primes. Two relative primes could be also
probably be used pretty safely.
The question is how strict do you want to be?
IMHO, disallowing negative coefficients is an arbitrary limitation. (-17, -37)
would probably give better hash codes than (1, 1), or even any combination of
the form (a, na) for most classes.
Should those be disallowed too? (and if so - should/could this be done now? It
would break backwards compatibility)
> Redundant check for zero in HashCodeBuilder ctor
> ------------------------------------------------
>
> Key: LANG-804
> URL: https://issues.apache.org/jira/browse/LANG-804
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
> Reporter: Sebb
> Priority: Minor
>
> The HashCodeBuilder(int, int) ctor checks both parameters for zero, as well
> as checking for an odd number.
> Zero is never odd, so the zero check could be eliminated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
