"John D. Hardin" <jhardin(_at_)wolfenet(_dot_)com> writes:
I'm trying to write a weighted recipe that adds a small negative
amount to the score for each line in the message, and I've been
getting inconsistent results.
Basically what I'm doing is something like:
:0
* -.1^1 ^.
The results vary unpredictably for small changes in w. Here's a test
ruleset and its results on a message of about 1400 lines (per wc -l):
Since you didn't put the 'B' flag on the recipe, only the number of
header lines (not counting continuations) matters.
:0
* -.30^1 ^.
...
* -.01^1 ^.
{ }
procmail: Score: -3 -3 "^."
procmail: Score: 0 -4 "^."
procmail: Score: -3 -7 "^."
...
procmail: Score: 0 -31 "^."
Why the seemingly random jumps to zero (or a fraction that is being
rounded down to zero for display purposes)? Is this some artifact of
the representation of double-precision floating point values in C?
Changing the minus signs to plus signs yields the same results with
positive numbers.
What am I not seeing?
I've stared at the code and after trying some stuff, I can say that
it's either a bug in gcc, gas, or the iX86 FPU itself. The assembly
language looks good to me, so I don't _think_ it's a bug in gcc, but I
could be wrong -- it's been too long since I handcoded for an i387 and
I don't know what tricks gas is playing (it's _got_ be sticking in
fwait instructions, so I know _some_ magic is being invoked...). I've
sent in a bug report to the GAS people so they can look at it.
Anyway, the workaround is to change lines 914 and 915 of src/misc.c from:
;{ double nweight;
if((nweight=weight*weight)<oweight&&oweight<1)
to:
;{ double nweight=weight*weight;
if(nweight<oweight&&oweight<1)
then recompile. I've checked this change in so it'll appear in the
next snapshot.
Philip Guenther