Re: std::lround advice ...

On 16/05/18 11:25, Michael Meeks wrote:
>         Chris - I'm intrigued by the above cppreference link on the
> corner-cases here:
>
> [snip]
> If the implementation supports IEEE floating-point arithmetic (IEC 60559),
>
> For the std::round function:
> The current rounding mode has no effect.
> If arg is ±∞, it is returned, unmodified
> If arg is ±0, it is returned, unmodified
> If arg is NaN, NaN is returned
> ...
> [/snip]
>
>         And I guess what I'd want to know is - can we create a unit test for
> std::lround that copy/pastes the old FRound code into it (which of
> course will be dead in your world) and allows us to verify that all of
> the corner-cases work in the same way, and that the FPU state / error
> conditions are working nicely.
>
>         so eg. (pseudo-code)
>
>         CPPUNIT_ASSERT(FRound(NaN) == std::lround(NaN))
>         CPPUNIT_ASSERT(FRound(1.0+epsilon) == std::lround(1.0+epsilon))
>         ... etc. ...
>
>         and so on for both basic and complex cases =)

std::round returns floating-point types, while std::lround returns long. 
 For the latter, "[i]f the rounded value is outside the range of the 
return type, the numeric result is unspecified" (C11).  So the proposed 
tests would not work (and should not really be of interest for us, 
anyway, as the FRound versions cause UB to begin with).

For cases where the FRound version wouldn't have caused UB anyway 
because the value was outside the range of long, I /think/ using 
std::lround is a correct replacement.