Thanks for looking into this more, Peter.
The latter of the two issues you mention sounds pretty easy to correct: could we
detect numbers above what the hardcoded normalization scaling numbers
support and compute those directly?
The first issue you describe doesn't sound intractable either. Perhaps swish-e could report an warning (if in some verbose mode) if the result of the *2 won't fit in the int? Fixing it outright would seem to require more code changes such as you describe, but I'm guessing that this 'interger overflow' doesn't happen as much as the issue above.
----- Original Message ----
From: Peter Karman <firstname.lastname@example.org>
To: Swish-e Users Discussion List <email@example.com>
I can see what the issues are, but not sure yet the best way to fix
them, other than to overhaul the way rank scoring is done. The main
issue is that OR'd results are added together and then multiplied by 2
(and there is no check to see if the result will fit in an int), and
then the rank display normalization has some hardcoded scaling numbers
that simply fail when scores get big (likely because ints are usually
now 32 or 64 bits rather than 16, as they were back when the code was
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
Users mailing list
Received on Wed Aug 29 17:08:30 2007