> On Feb 15, 2020, at 6:47 AM, David Brown <david@xxxxxxxxxxxxxxx> 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? > >> 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. >> >
