Future support of constexpr math functions

[David Brown]

On 15/02/2020 18:34, hugo brunie wrote:
> 
> 
>> On Feb 15, 2020, at 6:47 AM, David Brown <david@westcontrol.com> wrote:
>>
>> On 14/02/2020 17:05, Marc Glisse wrote:
>>> On Fri, 14 Feb 2020, Timothy Wrona wrote:
>>>
>>>> Just curious, but why couldn't you decide the rounding mode at compile
>>>> time
>>>> and pass the desired rounding mode as an argument to the compiler?
>>>
>>> Usually we need several different rounding modes in the same program.
>>>
>>
>> Certainly there are some cases where the programmer wants to be careful
>> about rounding modes and exact IEEE behaviour.  But I expect that if you
>> asked 100 C or C++ programmers what rounding modes they used, 95 would
>> answer "what's a rounding mode?".  And four of the other five would say
>> they have a vague idea that rounding modes can be controlled, but they
>> don't really care about them.
>>
>> Now, I believe it is important that we have standards for floating point
>> behaviour, and deterministic behaviour across platforms and tools.  But
>> realistically, it is only relevant for a tiny proportion of programs.
>> The huge majority would be fine - and faster - with "-ffast-math" and as
>> much done at compile time as possible.  The C++ standards and compilers
>> have to provide support for people who need deterministic floating point
>> results - but should not do so at the cost in usability or run-time
>> efficiency for other users and other programs.
>>
>> In my (unqualified) opinion, rounding modes could best be handled as
>> part of the type.  Then those that want some calculations to round
>> downwards and some to round to the nearest values, can use different
>> types to specify exactly what they want, when they want it.  And there
>> could be a "don't care rounding" type for those of us who want the most
>> efficient results.  Compiler flags could choose the default type for
>> "float" and "double".
>>
>> This way, the details are clear to the reader, easy to control by the
>> programmer, and obvious to the compiler so that it can optimise (or
>> calculate at compile time).
>>
>> (Ideally, it is the operations, not the types, which should have the
>> rounding mode.  But that would quickly get very ugly and inconvenient in
>> code, which a type-based solution would be easy to use.)
>>
> 
> Sounds like an interesting way to implement this to me.
> I have one question, as you highlight that the best way would be to choose the rounding mode
> at the operation level and not at the variable one.
> Which rounding mode would be picked with an operation involving 2 different rounding modes?
> 

This is something I have been thinking about, mainly in the context of 
integers rather than floating point.  (For some types of work, such as 
small embedded systems, control of how integer overflow works can be 
useful.)  In some cases, the answer is obvious - if you add a "round 
down" float to a "don't care" float, you get a "round down" addition. 
In other cases, you should get a compiler error - adding a "round down" 
float to a "round up float" should fail to compiler.

If you /do/ have a "round down" float "x" and a "round up" float "y", 
and you want to add them, you need to be explicit:

	round_up_float z = x + round_up + y;

(Don't take the identifier names here too seriously - they are just 
samples, not suggestions of good names!)

"round_up" would be an object of a type "Round_up", with a friend 
addition operator that takes any kind of float on the left side, and 
returns a "Round_up_adder" object initialised with the value of the left 
side float.  The "Round_up_adder" object has an addition operator that 
adds its stored float to the right hand side (regardless of the type of 
float) using round-up semantics.

You would also be easily able to cast or otherwise convert between the 
types (it's just a change of type, not of value), but it would need to 
be explicit.

I don't know much about floating point rounding control.  If it is 
possible to choose this per function in gcc, then the mechanics are in 
place - all that is needed is a set of classes and templates.  (With 
concepts, this should be nice enough.)

> 
>>
>>> The draft of the future C standard does have some pragma that might
>>> help, but seeing how hard it is to find implementations of pragma fenv,
>>> that may be optimistic.
>>>
>>
>