Added support for the f{maximum,minimum}_{mag,num} families, the newest standard for maximums in magnitude and number-preferring. This includes modifying fmax.3, on top of D56230, to recommend the use of fmaximum_num and fminimum_num.
Details
- Reviewers
fuz - Group Reviewers
numerics - Commits
- rG4e30c12973c7: lib/msun: Added fmaximum_mag and fmaximum_num families
Added tests for the new functions on top of fmaximum_fminimum_test.c. Also added a couple new test cases
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 71937 Build 68820: arc lint + arc unit
Event Timeline
Nice submission! I'll find some time in the next days to work on this one. Please note that kargl thinks fmaximum and fminimum should never raise FE_INVALID, so some slight rework is needed (we do return (a+b) which triggers FE_INVALID if a or b are signalling nans). He has also asked that the build scripts be in alphabetic order. I have prepared patches for both which I will land in the next days, you can then rebase your feature based on that.
Great! When I rebase I will also have to fix fmaximum_mag and fminimum_mag to not raise FE_INVALID (I imagine what he said applies to those too). And probably the man pages too. Happy Easter!
Rebased on top of the current main (fmaximum and fminimum). Updated _mag to not throw the invalid exception, adapted tests and man pages to the new changes.
Looks reasonable. I'll be waiting for kargl to say something, too.
One thing I wonder is if we really need to do this stupid dance with u[0].bits.exp == 255 && u[0].bits.man != 0 to check for NaN. I know the other functions do it too, but that is really old code. isnan() should do the trick just fine and is likely much faster. Will ask kargl what he thinks about this.
Ok, I think these are good and I'll do some tests and then merge them.
Apparently kargl has trouble signing up to this site.
Would you mind posting additional patches on Bugzilla instead (where he has an account)?
I'm sorry for the inconvenience.
As for the NaN checks, we are both fairly sure that we can just use isnan() instead.
If you like, you could post an additional patch to replace all manual nan checks in msun with calls to the isnan() macro, though that should be a separate thing.