2020-04-07 23:01 UTC+02:00, Alex Herbert <alex.d.herb...@gmail.com>: > > >> On 7 Apr 2020, at 17:47, Gilles Sadowski <gillese...@gmail.com> wrote: >> >> Le mar. 7 avr. 2020 à 14:54, Alex Herbert <alex.d.herb...@gmail.com >> <mailto:alex.d.herb...@gmail.com>> a écrit : >>> >>> On 07/04/2020 13:43, Alex Herbert wrote: >>>> >>>> Fraction >>>> >>>> I also did a big arrangement of Fraction and BigFraction. >> >> Thanks. >> >>> >>> I noticed that hashCode is using some variant of the format used in >>> Arrays.hashCode(...) >>> >>> I wondered if we should standardise on returning a value as if computed >>> using e.g. Arrays.hashCode(new int[]{numerator, denominator}) as was >>> done for Complex with its two parts. >>> >>> This would change in Fraction: >>> >>> public int hashCode() { >>> return 37 * (37 * 17 + numerator) + denominator; >>> } >> >> Strange that the constant 37 * 17 was not pre-computed. ;-) > > Yes. Weird. It was like that in CM 3.6.1. > > Not knowing if one is better than the other
The "17" seems to come from "Effective Java" (where J. Bloch says that it is arbitrary apart from being nonzero, so "1" is fine too I guess). > (do you just pick a small prime > for the factor?) I’d just shift it to use the same method as Arrays.hashCode > for consistency with Complex. Fine. The factor is indeed "31" in Effective Java, saying that it must be odd, and that a prime is a traditional choice. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
