Closed ptiede closed 1 year ago
Base: 97.31% // Head: 97.31% // No change to project coverage :thumbsup:
Coverage data is based on head (
5767bca
) compared to base (489e294
). Patch coverage: 100.00% of modified lines in pull request are covered.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
To fix this I replaced any instance of :NaN with oftype($x, NaN).
:NaN
is the DiffRules way to say that some derivative does not exist or is not implemented. You never want to use these "derivatives" anyway, every time you do you are already screwed.
Generally, oftype($x, NaN)
seems like the wrong approach as x
might not even be a floating point number. Just using float($x)
instead seems also wrong in the two-argument functions since it might cause undesired promotions if x
is not a floating point number (imagine eg the other argument being of type Float32
).
Ok I reverted the :NaN
for the two argument functions.
However for the ldexp
I think the point remains. In that case you do need the oftype(float($x), exp2($y))
to prevent a spurious promotion for the derivative with respect to x
.
This pull request ensures that the input type is preserved for various rules. Previously there were potentially a few places where 64 bit NaN's would always be produced regardless of the input. To fix this I replaced any instance of
:NaN
withoftype($x, NaN)
.Additionally, this pull-request fixes the issue with the
ldexp
rule from #88 which is similar in nature.