On Sun, 24 Dec 2017, Robert Ramey via Boost wrote:
On Sun, 24 Dec 2017, Robert Ramey via Boost wrote:
On 12/23/17 11:59 PM, Marc Glisse wrote:
(what about making this constexpr?). That's going to be hard, unless you are happy with making only trivial things (construct, copy) constexpr How come? How do you control the rounding mode at compile time? Hmmm - I don't see anything special about rounding mode that would
On 12/24/17 10:30 AM, Marc Glisse wrote: prevent it from being constexpr.
The way this currently works is you call fesetround or some asm to set the rounding mode of the FPU, then do your floating point operations as usual, with various tricks to prevent broken compilers (at least gcc and clang) from reordering arithmetic with rounding mode changes. OK - good explanation The only way I can think of to make operations constexpr (without making them incredibly slow) is to detect if they are called in a constexpr context, and in that case provide a software emulation. ] I tried but so far haven't found a way to detect whether a function is being invoked at compile time or run time. I have reason to believe
On 12/24/17 11:20 AM, Marc Glisse wrote: that it's possible, but as I said, I haven't found it yet. It's also possible that the user invoke the functions with a different policy if he's using it in a context which he expects it to be invoked at compile time. Actually, that would likely work in my case.
Don't forget to use gcc's -frounding-math flag to see how much you need to emulate... And efficiency isn't really an issue at compile time.
The same sort of question could be raised about lots of aspects of this or any other library. One can't really answer any of these questions until undertaking the task. All or most of the functions depend solely upon their parameters and have not side effects. But, in my recent experience, functions of this sort can generally be made to support constexpr.
I'm sure there are functions for which supporting constexpr wouldn't be worth it. Transdental functions come to mind. But I don't think that everything would have to be constexpr in order to be useful.
I think even addition or multiplication will not be so easy. In my home brew version - which doesn't consider rounding error - these operations haven't caused any problems. Unfortunately, the only way to really know is to try to do it. Or maybe you are interested in interval<int>? I was only ever interested in interval<double>, but interval<int> should indeed be easy to make constexpr. That's what I've been working with right now. Well, not quite, I'm using interval
which is sort an extended integer type. But the interval code generic in that it's decoupled from the type. The current versions are remarkably easy, hence my interest in seeing the official package support constexpr.
The considerations you mention above suggest that there would be a fair amount of extra information required to use the library effectively. That is, I think that the question of improved documentation would get promoted from desirable, to necessary. -- Robert Ramey www.rrsd.com (805)569-3793