Drop CMath.

[iglesias]

The class contains a bunch of methods like floor, ceil, sine, and a large etc. that I think we should not be implementing in our own, and rather use the ones that are available in the standard libraries. In this way, we reduce the code to maintain, the amount of methods to export to the interfaces, etc.

Actually, the header of this class contains an includes the standard math.h. It might be interesting to analyse if preventing SWIG from going through this include (e.g. guarding it with a ifndef SWIG directive) save us some compile time.

At first sight, this task should be easy as it only involves substituting calls to CMath::method(...) for method(...). However, some of these calls are in header files and in principle we do not want to include in our headers those from the standard libraries. This might become delicate in template classes.

Somewhat related to #2577.

[karlnapf]

Just a quick thought, I think it is good to have things like CMath::sin because it makes us backend independent. However, it should only be accessible from c++, and therefore hidden from SWIG

[iglesias]

That is a point. However, I think that for rather common operations (like the sine) which are included in the C++ standard, we can just go along using the C++ ones. Is there any reason why we would like to use the sine implemented somewhere else instead of the standard one?

[karlnapf]

thats a good point. We for sure rely on c++. But there for sure is a reason why we have those things - might be deprecated by now @sonney2k @lisitsyn what are your thoughts?

[vigsterkr]

partly it's done... but i believe we should just drop sooner or later the whole CMath, as now everything that's there is available in std:: since c++11

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gf712]

@vigsterkr will we replace these calls with the graph stuff? might be overkill? Then again the overhead might not be massive, mostly if there is JIT happening in the background...