Hello 👋, thank you for your support.

I noticed that this libraries version is 0.3, does that mean that is not fully developed yet? Is this library ready for business production code, without it having to be altered by us?

Also there is another library that is accessible through the nuget package manager: https://www.nuget.org/packages/FixedMath.NET/. Its github link: https://github.com/asik/FixedMath.Net. Do you guys know this library, if so, what can you tell me about it, should it be used for production code instead? Is there a problem with this library, and that is why you are creation yours?

Would it be a bad idea to define C++ methods as constexpr?

This would facilitate defining non trivial constexpr values in applications.

I'd appreciate any thoughts.

Thank you!

I calcd a value of F64Vec3, i use c#。
i known result is (0.0, 0.0, 1.4)
but F64Vec3 result is (-1.93249434232712E-08, 0, 1.39999999897555)
i write a function convert F64Vec3 result to Unity's Vector3
public Vector3 ToUnityVector3()
{
return new Vector3(X.Float, Y.Float, Z.Float);
}
that is return (0.0, 0.0, 1.4). X is F64Vec3.X, Y is F64Vec3.Y, Z is F64Vec3.Z
i want to use (0.0, 0.0, 1.4), but do not want use ToUnityVector3.
what shall i do ?

The function

public static long FromFloat(float v)
{
    return (int)(v * 4294967296.0f);
}

in Fixed64 ought to cast with (long) instead. Otherwise the result often exceeds int value bounds, causing unexpected results.

Currently, providing an invalid input to functions like Sqrt(<0) simply returns 0, which hides the problem and leads to debugging hell.

Returning a corrent result (NaN, #6 ) instead of zero would be slightly better - NaN usually breaks everything it touches and then you can trace back to when the result first became NaN.
While zero is incredibly common value, and is often a technically valid result, except not being logically valid in the context. Usually zero doesn't produce any noticeable bugs until after release.

So, in Debug mode (when DEBUG is defined) and arguably in Release mode as well (maybe provide an optional define like STRICT_VALIDATIONS) there should be exceptions thrown everywhere necessary, in order to catch bugs early. Any invalid input should be highlighted, not concealed.

Thank you for the awesome library!

Having a representation of infinity would be really nice, as some algorithms (converted from floating-point math) sometimes turn a bit ugly, requiring hacks like boolean flags or additional checks.

E.g. for Fixed64 it could be:

public const long NaN = -9223372036854775808L;
public const long PositiveInfinity = 9223372036854775807L;
public const long NegativeInfinity = -9223372036854775807L;
public const long MinValue = -9223372036854775806L;
public const long MaxValue = 9223372036854775806L;

The main use for infinity is to guarantee there's never an overflow when dealing with unknown input, e.g. A + B <= PositiveInfinity; A + PositiveInfinity = PositiveInfinity.

Plus, infinity often serves as a perfect initial value for a FindMin algorithm. Of course you could use MaxValue instead, but sometimes you need to factor currentMin as input while searching, and the input needs to behave like infinity if nothing has been found yet.

Finally, together with NaN those constants should correctly cover most edge cases like Sqrt(<0), Log(0), Div(X, 0), Asin(>1), Tan(PiHalf), etc.

Hi. I'm studying fixed point arithmetic and this FixPointCS is excellent material.

My question is, what is RcpPolyXX approximate? 1/x or 1/(x + 1)?

In Div() method, it used with one subtracted value from original value, like int res = FixedUtil.RcpPoly6(n - ONE);, not FixedUtil.RcpPoly(n) so it is quite confusing.

I'm a bit puzzled, what's the reason for implementing the modulo function this way?

        public static long Mod(long a, long b)
        {
            long di = a / b;
            long ret = a - (di * b);
            return ret;
        }

Isn't it more performant to just use existing % operator?

        public static long Mod(long a, long b)
        {
            long ret = a % b;
            return ret;
        }

As far as I understand, there should not be any difference in result of calculation.

Also, the function needs input check:

            if (b == 0)
            {
                FixedUtil.InvalidArgument("Fixed64.Mod", "b", b);
                return 0;
            }

(b == MinValue case works well with Mod)

This is great work!
CppTest.cpp causes error on linux because of its character code. It has BOM so it may be treated correctly on Windows.
iconv -f UTF16 -t UTF8 < CppTest.cpp

Hello, I have a small question about this library.

I read the following in this libraries description:

Deterministic: Operations produce bit-identical results across languages and compilers

I assume this also means that this library is deterministic across all platforms and architectures? For example across the different consoles (XBOX, PS4, etc) and different processors within the PC (AMD, Intel, etc). Is this true?