Modify

Ticket #5823 (closed Bugs: fixed)

Opened 3 years ago

Last modified 3 years ago

nextafter doesn't work correctly with non-finite values -- even in C99/TR1 mode

Reported by: mgaunard Owned by: johnmaddock
Milestone: To Be Determined Component: math
Version: Boost 1.47.0 Severity: Problem
Keywords: Cc:

Description

boost::math::tr1::nextafter(inf, 0) should yield the maximum value, yet it yields nan instead.

I think it would be a good idea to make it work like this directly boost::math::nextafter.

Attached is a testcase that demonstrates the problem (requires a C99 standard library for comparison).

Attachments

nextafter_test.cpp Download (652 bytes) - added by mgaunard 3 years ago.

Change History

Changed 3 years ago by mgaunard

comment:1 Changed 3 years ago by mgaunard

  • Summary changed from nextafter doesn't work with denormals -- even in C99/TR1 mode to nextafter doesn't work correctly with non-finite values -- even in C99/TR1 mode

comment:2 Changed 3 years ago by johnmaddock

  • Status changed from new to closed
  • Resolution set to wontfix

The current implementation deliberately treats an infinite argument as a domain error and raises an exception in C++ mode, or returns NaN in TR1 mode.

It would be easy enough to change this, but IMO it's questionable what the return value should be in this case - I'm not convinced that converting an infinite value to a finite one is the "right" answer - arguably the result could/should still be infinite.

So unless we can get a definitive answer from the C99 folks as to what the correct answer should be, I'm inclined to leave it as it is for now.

comment:3 Changed 3 years ago by mgaunard

While the C99 standard seems allows this, this is not what existing C99 implementations do (which the attached testcase does demonstrate), nor what other standard libraries in other languages do.

With the current situation, for us Boost.Math is unfortunately not usable directly as an alternative to a standard C99 library.

Why not just add the check in boost_nextafter for feature parity?

comment:4 Changed 3 years ago by johnmaddock

  • Status changed from closed to reopened
  • Resolution wontfix deleted

OK I've checked and both GLIBC and MSVC have the behaviour you describe, will fix later.

comment:5 Changed 3 years ago by johnmaddock

  • Status changed from reopened to closed
  • Resolution set to fixed

(In [74918]) Change nextafter and related functions to handle infinities as arguments the same way as GLIBC and MSVC. Fixes #5823.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.