rinzii/ccmath

A C++17 Compile Time <cmath> Library

I take breaks from contributing from time to time to learn new topics on my own. So if you see a gap in my contribution timeline thats probably why. ^^

Repositories

• ccmath ₂₀₂₄₊
  ^{A C++17 constexpr-Compatible cmath Library.}
• Mim ₂₀₂₃₊
  ^{A linear algebra math framework optimized for real time graphics programmed in modern C++.}
• Genesis Engine ₂₀₂₃₊
  ^{A vulkan game engine made with modern C++. Worked on in my spare time.}
• Dragon Archiver ₂₀₂₂₊
  ^{A virtual world creation, management, and note taking tool for tabletop role playing games made in .Net.}

_{You can check out more of my gists here.}

Game Jam Projects

• GMTK Game Jam 2022 - Casino _{2022
  Casino is a game about addiction and the strangle hold it can have on your life. This game was made in 48 hours for the GMTK Game Jam with a team of 6 people using Unreal Engine 4. I was one of two programmers on the team.}

My history on Github

• Issues:   Open   Closed
• Discussions:   All
• Pull Requests:   Open   Closed

ccmath's Issues

Implement Misc Functions With No Specified Module

These functions don't have a specified module, but do need to be implemented at some point.

TODO:

Implement:

• gamma
• lerp
• lgamma

Document:

• gamma
• lerp
• lgamma

NOTES:

None currently.

Add C++20 Modules Support for library

Add C++20 Modules support for the library.

Implement Power Module

The power module currently has the following functions that need implementation or work done.

TODO:

Implement:

• cbrt
• hypot
• pow
• sqrt

Document:

• cbrt
• hypot
• pow
• sqrt

NOTES:

None currently.

Implement Nearest Module

The nearest module currently has the following functions that need implementation or work done.

TODO:

Implement:

• ceil
• floor
• nearbyint
• rint
• round
• trunc

Document:

• ceil
• floor
• nearbyint
• rint
• round
• trunc

NOTES:

None currently.

Add first class support for Nvidia CUDA

I'd like to bring in first class support for Nvidia CUDA. To achieve this the following items need to be addressed:

• Add Nvidia CUDA (NVCC) to the CI.
• Validate all current implementations have zero conflicts.
• Validate there is not a significant decrease in performance across the entire library.

Even though some of the ground work has been done in detection I'm not sure it will be super simple as I'd like. There is likely a lot of cleanup work across the code base before NVCC will compile the library.

Add first class support for Nvidia HPC C++

I'd like to bring in first class support for Nvidia HPC C++. To achieve this the following items need to be addressed:

• Add Nvidia HPC C++ to the CI.
• Validate all current implementations have zero conflicts.
• Validate there is not a significant decrease in performance across the entire library.

I've already done some of the ground work required for this inside of our compiler detection header and the cmakelist. Overall, this should be pretty straightforward to implement, but I've not had time to handle the issue myself.

Build out comprehensive benchmark suite

Currently our bench marking setup with google benchmark is pretty basic and only does the bare minimum. This has been fine for a while, but implementing a hardened and robust testing suite would be best for long term work. I personally lack the knowledge at the moment with google benchmark to do this myself without much more time to learn how the library works.

Break up test suite to not be singular tests

Currently we perform all of our tests on a single test case and do not break up the tests into more precise test cases. Currently, all of the tests that have been implemented should be improved to have more explicit coverage of all of the test cases.

Benefits this change would provide are that the test cases would be more explicit and explain what the tests are testing for exactly.

Add first class support for mingw

I'd like to bring in first class support for mingw as its an extremely commonly used framework for development. To achieve this the following items need to be addressed:

• Add mingw to the CI.
• Validate all current implementations have zero conflicts.
• Validate there is not a significant decrease in performance across the entire library.

So far not much groundwork has been done to implement this issue and I am not sure how hard it would be to integrate into the library. For the time being this will be a "wontfix" for me, but if someone wants to take on the issue I'd gladly accept a PR!

Implement Exponential Module

The exponential module currently has the following functions that need implementation or work done.

TODO:

Implement:

• exp
• exp2
• expm1
• log
• log1p
• log2
• log10

Document:

• exp
• exp2
• expm1
• log
• log1p
• log2
• log10

NOTES:

None currently.

Optimizing Integer Pow Speed

I notice that you mentioned in pow_expo_by_sqr:

This is pretty fast with smaller numbers, but is slower than the standard when dealing with large numbers.
TODO: Find a way to optimize this for larger numbers.

I do find a lib using another kind of implementaion for integer pow operation. It uses a predefined pow_tree to find the optimal pow chain.

# This table represents the optimal "power tree"
# based on Knuth's "TAOCP vol 2: Seminumerical Algorithms",
# third edition, section 4.6.3, Fig. 15.  It was
# transcribed into this array form in the gcc source
# code (tree-ssa-math-opts.c), but since this is just
# a table of mathematical facts it should not be copyrightable.
#
# To compute x^q in a minimal number of multiplications
# for 1 ≤ q ≤ 255, you compute x^r * x^s for
# r = power_tree[q] and s = q-r, recursively
# (memoizing each power computation), and we implicitly
# define power_tree[0] = 0.
const power_tree = [
      1,   1,   2,   2,   3,   3,   4,       #   1 -   7
      4,   6,   5,   6,   6,  10,   7,   9,  #   8 -  15
      8,  16,   9,  16,  10,  12,  11,  13,  #  16 -  23
     12,  17,  13,  18,  14,  24,  15,  26,  #  24 -  31
     16,  17,  17,  19,  18,  33,  19,  26,  #  32 -  39
     20,  25,  21,  40,  22,  27,  23,  44,  #  40 -  47
     24,  32,  25,  34,  26,  29,  27,  44,  #  48 -  55
     28,  31,  29,  34,  30,  60,  31,  36,  #  56 -  63
     32,  64,  33,  34,  34,  46,  35,  37,  #  64 -  71
     36,  65,  37,  50,  38,  48,  39,  69,  #  72 -  79
     40,  49,  41,  43,  42,  51,  43,  58,  #  80 -  87
     44,  64,  45,  47,  46,  59,  47,  76,  #  88 -  95
     48,  65,  49,  66,  50,  67,  51,  66,  #  96 - 103
     52,  70,  53,  74,  54, 104,  55,  74,  # 104 - 111
     56,  64,  57,  69,  58,  78,  59,  68,  # 112 - 119
     60,  61,  61,  80,  62,  75,  63,  68,  # 120 - 127
     64,  65,  65, 128,  66, 129,  67,  90,  # 128 - 135
     68,  73,  69, 131,  70,  94,  71,  88,  # 136 - 143
     72, 128,  73,  98,  74, 132,  75, 121,  # 144 - 151
     76, 102,  77, 124,  78, 132,  79, 106,  # 152 - 159
     80,  97,  81, 160,  82,  99,  83, 134,  # 160 - 167
     84,  86,  85,  95,  86, 160,  87, 100,  # 168 - 175
     88, 113,  89,  98,  90, 107,  91, 122,  # 176 - 183
     92, 111,  93, 102,  94, 126,  95, 150,  # 184 - 191
     96, 128,  97, 130,  98, 133,  99, 195,  # 192 - 199
    100, 128, 101, 123, 102, 164, 103, 138,  # 200 - 207
    104, 145, 105, 146, 106, 109, 107, 149,  # 208 - 215
    108, 200, 109, 146, 110, 170, 111, 157,  # 216 - 223
    112, 128, 113, 130, 114, 182, 115, 132,  # 224 - 231
    116, 200, 117, 132, 118, 158, 119, 206,  # 232 - 239
    120, 240, 121, 162, 122, 147, 123, 152,  # 240 - 247
    124, 166, 125, 214, 126, 138, 127, 153,  # 248 - 255
]

This implementation reduces the number of multiplications, but requires some indexing operations. This may improve the speed of pow for large numbers ( 2 << 256 ), but I think there may be a trade-off for smaller values.

By the way, I don't see your Benchmark testing the pow function, so I'm not quite sure what your "large number" and "slower" mean exactly.

Implement Trigonometric Module

The trigonometric module currently has the following functions that need implementation or work done.

TODO:

Implement:

• acos
• asin
• atan
• atan2
• cos
• sin
• tan

Document:

• acos
• asin
• atan
• atan2
• cos
• sin
• tan

NOTES:

None currently.

Implement Float Manipulation Module

The float manipulation module currently has the following functions that need implementation or work done.

TODO:

Implement:

• copysign
• frexp
• ilogb
• ldexp
• logb
• modf
• nextafter
• scalbn

Document:

• copysign
• frexp
• ilogb
• ldexp
• logb
• modf
• nextafter
• scalbn

NOTES:

None currently.

Add first class support for Intel DPC++

I'd like to bring in first class support for Intel DPC++. To achieve this the following items need to be addressed:

• Add Intel DPC++ to the CI.
• Validate all current implementations have zero conflicts.
• Validate there is not a significant decrease in performance across the entire library.

I've already done some of the ground work required for this inside of our compiler detection header and the cmakelist. Overall, this should be pretty straightforward to implement, but I've not had time to handle the issue myself.

Implement Hyperbolic Module

The hyperbolic module currently has the following functions that need implementation or work done.

TODO:

Implement:

• acosh
• asinh
• atanh
• cosh
• sinh
• tanh

Document:

• acosh
• asinh
• atanh
• cosh
• sinh
• tanh

NOTES:

None currently.

Implement Special Module

The special module currently has the following functions that need implementation or work done.

TODO:

Implement:

• assoc_laguerre
• assoc_legendre
• beta
• comp_ellint_1
• comp_ellint_2
• comp_ellint_3
• cyl_bessel_i
• cyl_bessel_j
• cyl_bessel_ik
• cyl_neumann
• ellint_1
• ellint_2
• ellint_3
• expint
• hermite
• laguerre
• legendre
• riemann_zeta
• sph_bessel
• sph_legendre
• sph_neumann

Document:

• assoc_laguerre
• assoc_legendre
• beta
• comp_ellint_1
• comp_ellint_2
• comp_ellint_3
• cyl_bessel_i
• cyl_bessel_j
• cyl_bessel_ik
• cyl_neumann
• ellint_1
• ellint_2
• ellint_3
• expint
• hermite
• laguerre
• legendre
• riemann_zeta
• sph_bessel
• sph_legendre
• sph_neumann

NOTES:

Currently these functions are low on the priority list.

Implement int128 intrinsic

Having access to int128 intrinsic such as int128_t and uint128_t would be extremely helpful in much of the core implementation process for most functions that implement long double. The core benefit of this would be it would allow us a generic manner to handle long double without having to worry about if we've been given 80 bits or 128 bits.

The requirements would be quite stringent and it would have to be very efficient if possible. Ideally the implementation of this type would be identical in use to something like std::uint64_t.