Hi,

I have the following setup:

#include <fpm/math.hpp>
using number = fpm::fixed<int64_t, __int128_t, 32>;
number x = number(50) * (number::pi() / number(100));
// x is 1.5708, really close to half pi but raw value is off by one (base type) from ::half_pi()
number cosX = cos(x);
// inside the cos->sin function we reduce x to a value of two but it is also off by one (base type) and hence returns the wrong result here.

Could this be caused by this: static constexpr fixed pi() { return from_fixed_point<61>(7244019458077122842ll); } I tried changing this to calculate fixed(355)/fixed(113) (approximation of pi) and use this instead and it seems to fix the issue but could the from_fixed_point function not be correctly converting between fixed point types?

Thanks, Luis

Hi,

Before all, thanks for sharing this amazing project. I just wanted to ask for some help regarding this very particular use case I have.

// My use case
inline bool parseNumberDoubleWrapper(const char*& ptr, const char* end, double& number)
{
    // Convert double to fpm fixed representation
    fpm::fixed_16_16 n { number };
    // Execute parsing algorithm built on top of fpm types.
    bool b = parseNumber(ptr, end, n);
    // Create a double from the fpm::fixed_16_16 value
    // This static cast triggers fpm's function pasted below.
    number = static_cast<double>(n);  // <----- my problem is here
    // Return parsing status
    return b;
}

The static cast above is triggering this function in fpm:

    // Explicit conversion to a floating-point type
    template <typename T, typename std::enable_if<std::is_floating_point<T>::value>::type* = nullptr>
    constexpr inline explicit operator T() const noexcept
    {
        return static_cast<T>(m_value) / FRACTION_MULT;
    }

operator T() computes the final double using double division. Would it be possible to construct the double without relying on the double data type operations (in this case division)? I was wondering if this function could be re-written to compute the same result using n.raw_value() somehow (and not using any double operation at all).

To contextualise, my requirement is not to emit any floating point instruction at all but still be able to cast to double. Even a hacky workaround for this is useful.

Best regards, Manuel.

fpm is very nice! Converting numeric_limits values to float is behaving unexpectedly when there are zero integral bits.

#include <cstdint>
#include <fpm/fixed.hpp>
#include <fpm/ios.hpp>
#include <iostream>
#include <iomanip>

using fixed_0_15 = fpm::fixed<std::int16_t, std::int32_t, 15>;

int main() {
    auto max = std::numeric_limits<fixed_0_15>::max();
    auto lowest = std::numeric_limits<fixed_0_15>::lowest();
    std::cout << "fixed_0_15"
            << " max " << max
            <<" lowest "<< lowest
            << std::endl;
    std::cout << "static_cast<float>(fixed_0_15)"
              << " max " << static_cast<float>(max)
              <<" lowest "<< static_cast<float>(lowest)
              << std::endl;
    std::cout << "float(fixed_0_15)"
              << " max " << float(max)
              <<" lowest "<< float(lowest)
              << std::endl;
}

$ c++ -std=c++17 -Ifpm/include fpm_limits.cpp && ./a.out
fixed_0_15 max 0.999969 lowest -1
static_cast<float>(fixed_0_15) max -0.999969 lowest 1
float(fixed_0_15) max -0.999969 lowest 1

The fixed_0_15 is an attempt to model the q15 data type used in the ARM CMSIS DSP library. The trouble may be because FRACTION_MULT cannot be represented in the base type int16_t. I think FRACTION_MULT should use the IntermediateType. The tests pass with this change:

-    static constexpr BaseType FRACTION_MULT = BaseType(1) << FractionBits;
+    static constexpr IntermediateType FRACTION_MULT = BaseType(1) << FractionBits;

Hi.

Thank you for this amazing class. I want to leave my feedback.

First. There are no shift operators.

template <typename I, typename std::enable_if<std::is_integral<I>::value>::type* = nullptr>
inline fixed& operator>>=(I y) noexcept
{
    m_value >>= y;
    return *this;
}

template <typename I, typename std::enable_if<std::is_integral<I>::value>::type* = nullptr>
inline fixed& operator<<=(I y) noexcept
{
    m_value <<= y;
    return *this;
}

template <typename B, typename I, unsigned int F, typename T, typename std::enable_if<std::is_integral<T>::value>::type* = nullptr>
constexpr inline fixed<B, I, F> operator>>(const fixed<B, I, F>& x, T y) noexcept
{
    return fixed<B, I, F>(x) >>= y;
}

template <typename B, typename I, unsigned int F, typename T, typename std::enable_if<std::is_integral<T>::value>::type* = nullptr>
constexpr inline fixed<B, I, F> operator<<(const fixed<B, I, F>& x, T y) noexcept
{
    return fixed<B, I, F>(x) <<= y;
}

I spent a whole day to understand why fixed doesn't work in my case. :thinking: The problem was in this string.

const int count = static_cast<int>(sweep >> (16 - k));

When you use just std::int32_t for type, this will work. But in case of fixed this doesn't return internal value. Because I save inside fixed a floating-point value, this approach is incorrect. It confuses. I am not familiar with fixed-point types. But I do not undersatnd purpose of conversion to integrals.

Correct code in my case.

const int count = (sweep >> (16 - k)).raw_value();

Is it possible to cast from e.g. fixed_8_24 to fixed_16_16 without an intermediate step via a float value?

With simple assignments "fixed2 = fixed1" the compiler reports an >no known conversion for argument 1 from 'fpm::fixed_8_24' ... to 'const fpm::fixed<int, long long int, 16>&'

There is a function from_fixed_point(T value), but i dont understand it. I would have expected that the value is corrected by the difference of the FractionBits between new and old datatype.

This file is needed to get this library to work seamlessly with PlatformIO. Docs for the file can be found at https://docs.platformio.org/en/latest/librarymanager/config.html

This has been tested with a platformio project by setting

lib_deps =
    https://github.com/flaviut/fpm.git#aa0a3aa265ea0733f3c6410785f31b53b0a0db03

and works fine.

Hi! Thank you for your library. I want to see this library in Conan (dependency manager for C++). That's not so hard to prepare a recipe for your library, but the only one limitation for now is a lack of any release. Can you please release your library with any version? It will be very helpful. Thanks a lot!

Window's header minwindef.h define the macro min() and max().

When this file is included before fixed.hpp, this fail to compile because min/max method of numeric_limit<fixed> are refering to the windows macro as showed in the screenshot below.

I did not look that much into the subject but it seems to be a reccurent problem for libraries that are using min/max methods and are co-existing with the windows header in an application.

The solution I use for now is the include fixed.hpp before the header that include minwindef.h.

I think, this information might be worth to be included as a note in the documentation or somewhere else.

The following code generates an error message under different clang versions, because std::round() is not a constexpr function in C++11/14.

static constexpr fpm::fixed_16_16 delta {1.234};
//error: constexpr variable 'delta' must be initialized by a constant expression
//static constexpr fpm::fixed_16_16 delta {1.234};
//                                  ^~~~~~~~~~~~~
//.\include\fpm/fixed.hpp: note: non-constexpr function 'round' cannot be used in a constant expression
//        : m_value(static_cast<BaseType>(std::round(val * FRACTION_MULT)))

I suggest the following workaround: replace std::round()

    // Converts an floating-point number to the fixed-point type.
    // Like static_cast, this truncates bits that don't fit.
    template <typename T, typename std::enable_if<std::is_floating_point<T>::value>::type* = nullptr>
    constexpr inline explicit fixed(T val) noexcept
        //: m_value(static_cast<BaseType>(std::round(val * FRACTION_MULT)))
        : m_value(static_cast<BaseType>((val >= 0.0) ? (val * FRACTION_MULT + 0.5) : (val * FRACTION_MULT - 0.5)))
    {}

On Godbolt you can see the behavior (without fpm header)

https://godbolt.org/z/34cns5fnK

Advantage: This allows constants to be defined at compile time without the detour via from_fixed_point<..>....

Question for your expertise for what seems to be an uncommon-but-not-rare situation:

What are the risks and limitations exactly of using the same int type for BaseType and IntermediateType? Eg, fpm::fixed<std::int64_t, std::int64_t, 16>

I've looked into the fpm code, ran some unit tests, and otherwise messed around with the above for a while, and it seems like the above 64bit with 16 fractional bits type works pretty well. However, I'm not familiar with how the fractional portion works exactly and overall not sure what the limitations and risks of this would be (other than needing to restrict myself to some sub-range of numbers at the risk of very easy underflows and overflows).

Problem Context: Earlier I attempted to a BaseType of int64_t and IntermediateType of boost's int128_t, but unfortunately that's far too slow for my needs (10x slower than fixed_16_16 and far higher than my performance budget as mentioned in #21). Thus, I'm looking for workarounds for my size constraints

Notably, I don't really need a very large working number range- I'm creating a game where typically one unit == 1cm (Unreal units), and as long as I get at least 2km (so 20000) for range of world units then I can easily fit all my needs.

However, that 20,000 max is before any underlying calculations. For example, one of my more problematic operations is getting a length of a vector, which involves squaring and adding 3x. Thus, at the very least my range needs to support 20000^2, and given that's above the range of fixed_16_16 and fixed_24_8, I need to go into the realm of 64bit BaseType numbers.

And now we're unfortunately back to the beginning where a BaseType of int64_t needs a size above it, and boost's int128_t is unfortunately extremely slow.

However... my numeric range isn't that large. Thus, if I drop the need for lossless operations and heavily restrict myself to a very limited range (which will definitely be error-prone but doable), then I can use the same IntermediateType as BaseType. In other words, it should be viable to use fpm::fixed<std::int64_t, std::int64_t, 16> (or something akin to it).

I've tested this (after commenting out the sizeof static assert), and after some tweaking with number of fractional bits, it's surprisingly working well. On the other hand, I'm not sure exactly what the risks and limitations are.

For example, I'd expect that I'd need a working range that fits the following: [sqrt of range<TOTALBITS - FRACTIONALBITS>]/3

Thus, with fixed<int64_t, int64_t, 20>, I'd expect the safe numeric working range to be about... sqrt(2^(64-20)-1)/3 = ~1,398,101.3

However, even 45000 * 45000 overflows with that fixed point type, while fixed<int64_t, int64_t, 16> does not overflow here.

All in all, I'm largely guess and checking with the limitations of this approach at the moment, and thus would greatly appreciate any insight you can provide here.

In addition, I hope this write up will also help someone in the future who faces similar issues as well. Cuz dang, this was a surprising amount of work to even get this far. Makes me hella glad this solid library exists again- yay for well-written and flexible yet easy to understand library!

Currently, doing fixed_16_16 f {}; does not initialize f.m_value. The expected behaviour is to do zero-initialization, like int i{} initializes i to 0. The simple fix is to mark the constructor as default, which is good anyway.

Moreover, it can't be used in constexpr expressions:

constexpr void test()
{
    // fpm::fixed_16_16 f {}; // Error because can contain anything
    fpm::fixed_16_16 f{0}; // Ok
}

Also some of the operators like += are not marked constexpr but that's another issue.

CPM or FetchContent are frequently used to add dependencies to projects. In that case, it doesn't make sense to add all these extra targets unless they are asked for.

This is needed, for example, in the case of use in an embedded project. When GoogleBench is included, it depends on threads, which are not available.

Is the value returned by raw_value() the same across all platforms for a given fixed point value? That's for serialization and sending into network and ensure portability. I assume yes but just to be sure.

For example, in the atan function, if x is signed and x is the lowest value, -x will be equal to x. So the function will keep calling itself and cause a stack overflow.

Hi Mike,

Thanks for the great library!

I faced an issue when trying to convert a fixed_16_16 number to a fixed<std::int64_t, __int128, 32>. In essence, it seems that the from_fixed_point function in fixed.hpp could not handle an increase number of bits for both the BaseType and the FractionBits jointly. I handled this by modifying the code as follows:

template <unsigned int NumFractionBits, typename T, typename std::enable_if<(NumFractionBits <= FractionBits)>::type* = nullptr>
    static constexpr inline fixed from_fixed_point(T value) noexcept
    {
    	T tmpT = T(1) << (FractionBits - NumFractionBits);
        BaseType tmpBT = static_cast<BaseType>(value)*static_cast<BaseType>(tmpT);
    	return fixed(tmpBT, raw_construct_tag{});
    }

This seems to do the trick, but I thought I'll mention it in case it may be of interest to others.

Cheers,

Mathieu

When calling the function sqrt() I stumbled across a message from my compiler: Error: Unsupported intrinsic: llvm.ctlz.i64

Reason: the function find_highest_bit() uses intrinsic functions (for performance reasons). I use a modified gcc here which does not support intrinsic calls.

I have adapted my code as follows, possibly this would be also an option for the main branch:

By using a preprocessor switch FPM_NO_INTRINSIC you can prevent the use of intrinsic calls and at the same time the code works on many compilers which are not supported so far.

inline long find_highest_bit(unsigned long long value) noexcept
{
    assert(value != 0);
#if defined(FPM_NO_INTRINSIC) // Note: Non-optimised Version
    int count = 0;
    while (value >>= 1) {count ++;}  
    return count;
#elif defined(_MSC_VER)
    unsigned long index;
#if defined(_WIN64)
    _BitScanReverse64(&index, value);
#else
    if (_BitScanReverse(&index, static_cast<unsigned long>(value >> 32)) != 0) {
        index += 32;
    } else {
        _BitScanReverse(&index, static_cast<unsigned long>(value & 0xfffffffflu));
    }
#endif
    return index;
#elif defined(__GNUC__) || defined(__clang__)
    return sizeof(value) * 8 - 1 - __builtin_clzll(value);
#else
#   error "your platform does not support find_highest_bit()"
#endif
}

(Admittedly, the code is slow, if necessary I can include an optimized version with bitmasks).

One question: Is there a reason why find_highest_bit() returns a datatype long instead of int?