Re: [PATCHv2 06/14] Replace M_PI2l with pi_2_d in libm-test.inc

["Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>]

On 05/23/2016 03:16 PM, Joseph Myers wrote:
> On Mon, 23 May 2016, Paul E. Murphy wrote:
> 
>>> For the API for float128 to be feature-complete compared to long double, 
>>> it should include constants such as M_PI_2f128 for all the long double 
>>> constants in <math.h>.  Which means that there is always a constant from 
>>> <math.h> that can be used in these cases; you don't need yet another copy 
>>> of the digits of this constant.  You might, for example, have a macro MCST 
>>> defined for each type and use MCST (PI_2) here (which would expand to 
>>> M_PI_2 for float and double - there aren't float versions of these 
>>> <math.h> constants - M_PI_2l for long double, M_PI_2f128 for float128).
>>
>> Are you suggesting removing the new constants entirely, or just redefining
>> these macros in terms of existing macros?
> 
> My suggestion was removing them entirely (and using MCST (PI_2) etc. in 
> individual tests), but I suppose you could define them in terms of 
> existing macros.
> 
>> I'd prefer to keep the M prefixed constants out of the individual test cases,
>> and maintain consistency with the other lower case constants.  It's too easy
>> to overlook them otherwise.
> 
> Actually, I think there is a case for the following: the individual tests 
> all use names that are not M_*, for both the constants that are in 
> <math.h> and the local ones - but those names all have some common prefix 
> in place of M_, rather than being like the other lower-case constants 
> without any fixed prefix.
> 
> Rationale: these constants are logically different from those such as 
> min_value, in that, when used as expected results, the ideal result would 
> depend on the rounding mode.  So having a unique prefix would facilitate 
> hypothetical future gen-libm-test.pl enhancements to detect such constants 
> in expected results and replace them by references to per-rounding-mode 
> macros, where the values of those macros are automatically generated for 
> each format and rounding modes by gen-auto-libm-tests.c or similar.

That seems reasonable.  Though, wouldn't it be much simpler to punt
these tests to auto-libm-test-in/gen-auto-libm-tests.c and have it more
accurately compute correctly rounded constants for each format and
rounding mode?  That also seems to imply the inputs may also be
sensitive to rounding mode.

Anyhow, the next patchset will append the "lit_" prefix to new macro
constants to support such changes.