You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed the sign comparison is performed inconsistently; i.e. in some places as fa*fc < 0 and in some places you extract the sign explicitly like above.
The latter option is in agreement with what Kahaner, Moler, & Nash have to say about this:
The original SLATEC FZERO from Shampine & Watts does it like this:
IF (SIGN(1.0E0,FB) .NE.SIGN(1.0E0,FC)) ...
Leaving the underflow issues aside, the sign version seems to generate a few instructions less than your branching isign function. Moreover, gfortran and ifx produce branchless instructions when using the sign intrinsic: https://godbolt.org/z/E41P9c4Mz
As a matter of clarity, the sign comparison could also be abstracted as a function or operator, e.g.
if (sne(fb,fc)) ... ! sign not equal
or
if( fb .oppsign. fc) ... ! opposite sign
but I guess this is more a matter of taste (I'm not advocating for it, but the compilers seem able to inline such operators just fine).
The text was updated successfully, but these errors were encountered:
I noticed SciPy actually had the same issue (scipy/scipy#13737) and they introduced a sign-bit comparison to avoid the test failing due to underflow/overflow.
roots-fortran/src/root_module.F90
Line 1837 in 60524bc
I noticed the sign comparison is performed inconsistently; i.e. in some places as
fa*fc < 0
and in some places you extract the sign explicitly like above.The latter option is in agreement with what Kahaner, Moler, & Nash have to say about this:
The original SLATEC
FZERO
from Shampine & Watts does it like this:Leaving the underflow issues aside, the
sign
version seems to generate a few instructions less than your branchingisign
function. Moreover,gfortran
andifx
produce branchless instructions when using thesign
intrinsic: https://godbolt.org/z/E41P9c4MzAs a matter of clarity, the sign comparison could also be abstracted as a function or operator, e.g.
if (sne(fb,fc)) ... ! sign not equal
or
if( fb .oppsign. fc) ... ! opposite sign
but I guess this is more a matter of taste (I'm not advocating for it, but the compilers seem able to inline such operators just fine).
The text was updated successfully, but these errors were encountered: