I wrote:
> + # XXX This one neither, but if I add it to @skip, PerfectHash will fail. (???)
> + #FIXME: AttributeRelationId
>
> I took a quick look at this, and attached is the least invasive way to get it working for now, which is to bump the table size slightly. The comment says doing this isn't reliable, but it happens to work in this case. Playing around with the functions is hit-or-miss, and when that fails, somehow the larger table saves the day.
To while away a rainy day, I poked at this a bit more and found the input is pathological with our current methods. Even with a large-ish exhaustive search, the two success are strange in that they only succeeded by accidentally bumping the table size up to where I got it to work before (77):
With multipliers (5, 19), it recognizes that the initial table size (75) is a multiple of 5, so increases the table size to 76, which is a multiple of 19, so it increases it again to 77 and succeeds.
Same with (3, 76): 75 is a multiple of 3, so up to 76, which of course divides 76, so bumps it to 77 likewise.
Turning the loop into
a = (a ^ c) * 257;
b = (b ^ c) * X;
...seems to work very well.
In fact, now trying some powers-of-two for X before the primes works most of the time with our inputs, even for some unicode normalization functions, on the first seed iteration. That likely won't make any difference in practice, but it's an interesting demo. I've attached these two draft ideas as text.
--
John Naylor
EDB:
http://www.enterprisedb.com