74

So noticed from this page that none of the math functions in c++11 seems to make use of constexpr, whereas I believe all of them could be. So that leaves me with two questions, one is why did they choose not to make the functions constexpr. And two for a function like sqrt I could probably write my own constexpr, but something like sin or cos would be trickier so is there a way around it.

Improve this question
8
  • 3
    They didn't choose not to make the functions constexpr. They just didn't make any choice (I believe there are proposals to make them so in the future). Commented Jun 27, 2013 at 16:01
  • @R.MartinhoFernandes - there's some discussion, but the problem with making complicated functions constexpr is that the compiler then has to do what would otherwise be a runtime computation, and that means having a C++ interpreter built in to the compiler. It's a big job... Commented Jun 27, 2013 at 16:07
  • @PeteBecker not all of them are complex, but I guess by saying that I'm also saying why not just do them on my own Commented Jun 27, 2013 at 16:09
  • 3
    Note, gcc has implemented most of the math function as constexpr although the extension is non-conforming this should change. So definitely doable. Commented Jan 12, 2015 at 20:23
  • 1
    I think one has to distinguish here: It seems almost impossible to implement the math functions efficiently as constexpr functions in pure C++. At least given the restrictions on constexpr functions in C++11. On the other hand, the math functions are a very well-known finite set of functions that a compiler could easily provide as builtins and evaluate at compile-time. This mixing of core language features and library functions might be considered ugly, but also worth the thing. Also see Alisdair Meredith's talk on CppCon 2014. Commented Jan 13, 2015 at 3:08

3 Answers 3

Reset to default
76

Actually, because of old and annoying legacy, almost none of the math functions can be constexpr, since they all have the side-effect of setting errno on various error conditions, usually domain errors.

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

No. That is, I don't think there's a library of constexpr math functions already available, so not even that would work. (Of course, C++14 will make implementing them much more convenient and efficient.)
A function can be constexpr and still sometimes throw, etc. The value of a sum of double may depend on a rounding mode, but accommodations are made for the constexpr case. errno is really not a good reason.
@MarcGlisse Throwing and errno are two very different beasts. The C standard math functions are specified to modify errno, not throw an exception. So I don't understand your point.
@SebastianRedl Addition is specified to set FE_INEXACT if the result is not exact. However, an addition is still allowed to be constexpr. Does this look closer to the errno situation to you?
It comes close, except that nowhere in C99 can I find such a specification, much less in C++11. The closest is there reference to the ISO 60559 operations in Annex F of C99. However, C++ only references the library clauses of C, so this annex has no normative role in C++. I don't think C++ has any requirement that addition has side effects. Note in particular the lack of any "contracted" floating point operations in C++11 section 5 intro, which are there in the equivalent section of C99.
|
7

From "The C++ Programming Language (4th Edition)", by B. Stroustrup, describing C++11:

"To be evaluated at compile time, a function must be suitably simple: a constexpr function must consist of a single return-statement; no loops, and no local variables are allowed. Also, a constexpr function may not have side effects."

Which means that it must be inline, without for, while and if statements and local variables. Side effects are also forbidden (ex: changing of errno). Another problem is that most of math functions are FPU instructions which are not represented in pure c/c++ (they are written in assembler code). That's why non of cmath function is declared as constexpr.

Improve this answer

6 Comments

This is not true anymore in C++14.
Yeah, good point. I gave the answer why those functions can't be constexpr in c++11, because question was about c++11.
@aaronman, as Marc Glisse said, errno is not a good reason because c++ standard could provide a parallel implementation of those functions which would not modify errno. But even then constexpr implementation would'n be possible without some intrinsic compiler feature. I don't want to argue, but I think, I pointed several good reasons for that. I may be wrong of course. I'm currently writing a library which would gain a lot from constexpr math functions - that's why I'm here - but I think that there are much more problems than just 'errno'.
@AdamSzaj constexpr functions (even c++11 ones) are turing complete, so I don't see the issue you are bringing up, here is an example of contexpr sqrt I wrote a while back
Quite nice, but try awsome::sqrt(3e13) . Have you tried to implement sin, cos, tanh, or similar functions? I know that there are algorithms for such functions, but do you think that constexpr_sin(x) == sin(x)?
|
6

So noticed from this page that none of the math functions in c++11 seems to make use of constexpr, whereas I believe all of them could be. So that leaves me with two questions, one is why did they choose not to make the functions constexpr.

This part is very well answered by Sebastian Redl and Adam Szaj so won't be adding anything to it.

And two for a function like sqrt I could probably write my own constexpr, but something like sin or cos would be trickier so is there away around it.

Yes, you can write your own version of constexpr sin, cos by using the taylor series expansions of these functions. Have a look at this super cool github repo which implements several mathematical functions as constexpr functions Morwenn/static_math

Improve this answer

6 Comments

Not so super cool: try calculating smath::cos(20.). Cosine greater than 3... It's hard enough to implement a decent non-constexpr trig function, let alone constexpr one.
@Ruslan Thanks for pointing that out. I had never tried that myself. I, however, made my own library for doing some compile-time stuff github.com/lakshayg/compile_time and I am quite sure that it can handle this case well. Do give it a try and let me know (or open an issue) if you have suggestions (This is still a work in progress).
Didn't look at the code, but your version 1) fails to include <stdexcept>, thus not compiling without tweaks; 2) seems to do only trivial range reduction, so that e.g. compile_time::cos(200.) differs considerably from std::cos(200.) on x86_64 gcc, while for argument of 2. the results are more or less the same. Even worse for long double. But yes, it does appear to at least attempt to do range reduction, unlike static_math.
@Ruslan Thanks for the feedback, could you please provide me some details about your platform. On my machine (linux, x86_64, g++5.4) the code compiles without any warnings/errors and the error is less than 0.00001%. Also, we should probably continue this discussion on github.
Yeah, made an issue report. Anyway, the problem with precision isn't what fraction of percent it is — it's how many ULPs it is. In my test I got the error of 2**17 ULP, which is no good for IEEE754 64-bit double.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.