Generating FFP values at compile time

[deimos]

Originally Posted by alkis

There shouldn't be different if your values are within FFP range. If they are not then you have other problems. If they are, then the conversion should work.

I don't want to.

[deimos]

So, something like this:

    // to do, this afternoon
    constexpr FFP composeffp(const LONG mantissa, const LONG exponent) {
        return exponent;
    }

    constexpr FFP r(const char * s) {
        FFP n = 0;

        LONG mantissa = 0L;
        LONG exponent = 0L;

        bool negativeMantissa = false;
        bool negativeExponent = false;

        bool parsingExponent = false;

        for (const char * p = s; *p; *p++) {
            const char c = *p;

            if (!parsingExponent) {
                if (c >= '0' && c <= '9')
                    mantissa = mantissa * 10 + (c - '0');
                else if (c == '-')
                    negativeMantissa = true;
                else if (c == 'e' || c == 'E')
                    parsingExponent = TRUE;
            } else {
                if (c >= '0' && c <= '9')
                    exponent = exponent * 10 + (c - '0');
                else if (c == '-')
                    negativeExponent = TRUE;
            }
        }

        if (negativeMantissa)
            mantissa = -mantissa;
        
        if (negativeExponent)
            exponent = -exponent;

        return composeffp(mantissa, exponent);
    }

[deimos]

I have also just found this:

https://github.com/xroche/ieee754toy

Which looks like it does a more advanced version of what I'm trying to do. I'm still trying to understand it properly, it uses more things that are new to me, like function templates.

[Jobbo]

For what it's worth I updated my code so it can generate instances of my ffp class from native floats at compile time and vice versa.

I didn't port the 68000 assembler versions, which seems to be what alkis has done. Those versions are pretty hard to follow. Instead I wrote simple to follow C versions.

That doesn't help you with your string parser but my versions are maybe useful to others.

https://github.com/rjobling/ffloat

[deimos]

Originally Posted by Jobbo

For what it's worth I updated my code so it can generate instances of my ffp class from native floats at compile time and vice versa.

I didn't port the 68000 assembler versions, which seems to be what alkis has done. Those versions are pretty hard to follow. Instead I wrote simple to follow C versions.

That doesn't help you with your string parser but my versions are maybe useful to others.

https://github.com/rjobling/ffloat

And, of course, that's a perfectly valid and useful thing to do, it's just not the thing I want to do. I want to create a perfect 1:1 compatibility with the Motorola format. I don't think the C++ code for that will be big, but, yes, it's not easy to follow the assembly code. I'm making very slow progress.

[Jobbo]

As far as I'm aware all the versions we've posted do the best job possible to translate from IEEE to FFP, and a perfect job translating from FFP to IEEE.

[deimos]

Originally Posted by Jobbo

As far as I'm aware all the versions we've posted do the best job possible to translate from IEEE to FFP, and a perfect job translating from FFP to IEEE.

I have no interest in translating from IEEE to FFP. I just want to construct FFP numbers.

In any case, there can be no such thing as a perfect job of translating between the formats, as they have different ranges and precisions. Not every number that can be exactly represented by IEEE be exactly represented in FFP, and visa versa.

Now, of course, loads of adenoids will come along to explain that floating point numbers should always be treated as approximations and never compared directly, etc. etc., but I don't care about that, I don't want one part of my code base converting a string to one number and another part converting the exact same string to a slightly different number.

[Jobbo]

Originally Posted by deimos

In any case, there can be no such thing as a perfect job of translating between the formats, as they have different ranges and precisions. Not every number that can be exactly represented by IEEE be exactly represented in FFP, and visa versa.

That's incorrect. All valid FFP numbers have an IEEE equivalent.


Here is the original code I had copied which has some comments.



https://github.com/ggnkua/Atari_ST_S...FFP/FFPIEEE.SA



You can also read the FFP format description in the Amiga libs documentation.


http://amigadev.elowar.com/read/ADCD.../node047D.html

[deimos]

You've just made up my mind. I have better, more interesting things to do than develop for the Amiga.