[Solved] Defining floating point constants

[MathMan]

Hello all,

In some cases it neccessary/preferred to define floating point constants in a way that is precise/unambiguous. In C one can define a floating point constant in hexadecimal notation like

Code: Pascal  [Select][+][-]

1.   const_single = 0x1.234567p1;
2.   const_double = 0x1.23456789abcdefp-1;
3.  

Is something similar possible in FPC? I seem to only find decimal notation referenced for floating point.

Cheers,
MathMan

[MathMan]

Nothing?

Not even a secured "No, can't be done."?

[marcov]

Not documented at least. See e.g. numlib where constants are defined an array of bytes, and then typecast into float.

[MathMan]

Not documented at least. See e.g. numlib where constants are defined an array of bytes, and then typecast into float.

Thanks marcov - was afraid it is like that and that I have to use the solution you mentioned.

[Warfley]

You could write down the mantissa as hexadecimal number and then divide by the exponent

Code: Pascal  [Select][+][-]

1. MyFloat = $AABBCC / (1 shl exp)

[MathMan]

You could write down the mantissa as hexadecimal number and then divide by the exponent

Code: Pascal  [Select][+][-]

1. MyFloat = $AABBCC / (1 shl exp)

Beg to differ - shl is only defined for ordinal types. So this breaks as soon as exp >63, doesn't it?

If I have to parse and modify existing constant tables anyway, I think I prefer the variant record approach.

[marcov]

While not constant the single/float helpers might make it possible runtime (e.g. once at startup)

[Paolo]

"Absolute" can help ?
Declare a integer const with the bit pattern you need, then declare a float const pointing to the previous integer constant.
Not checked.

Code: Pascal  [Select][+][-]

1. Const
2.     A = $××××××x
3.      B = float absolute A
4.  

Again not checked.

[marcov]

That's what numlib does with array of bytes.

80-bit integers are somewhat hard anyway :-)

[MathMan]

While not constant the single/float helpers might make it possible runtime (e.g. once at startup)

Hm - I'll have a look at least, but runtime is definitely not what I can use for all of it.

Background - I currently try to understand how much effort would be involved to port the CORE-Math library https://core-math.gitlabpages.inria.fr/ to Free Pascal. It provides a full set of correctly rounded elementary functions for Single & Double. A lot of mathematical grunt work has gone into that and a full port, including testing environment, would unfortunately require conversion of several millions of FP constants. Even if only the actual function implementation is addressed there are still some thousand involved.

Of course I would also like to know if this is in any way wanted for FPC RTL - and later on I'd need guidance how to do the RTL integration correct.

But at the moment I'm still investigating for an effort estimation.

[Warfley]

Beg to differ - shl is only defined for ordinal types. So this breaks as soon as exp >63, doesn't it?

If I have to parse and modify existing constant tables anyway, I think I prefer the variant record approach.

Split it up if you need more

Code: Pascal  [Select][+][-]

1. MyFloat = $AABBCC / (1 shl 63) / (1 shl 7)

The Compiler evaluates constants at compile time so it should not Introduce runtime overhead, and because you only divide by powers of two no float rounding errors can occur

[nanobit]

Of course I would also like to know if this is in any way wanted for FPC RTL

Probably wanted (or even needed in the long term),
but an urgent (?) wish seems also be additional support for 80/128 bit in RTL softfpu.

[marcov]

Code: Pascal  [Select][+][-]

1. MyFloat = $AABBCC / (1 shl 63) / (1 shl 7)

The Compiler evaluates constants at compile time so it should not Introduce runtime overhead

(but does it do everything binary ? Or does it calculate the fraction as an integer divided by some number?)

[MathMan]

Of course I would also like to know if this is in any way wanted for FPC RTL

Probably wanted (or even needed in the long term),
but an urgent (?) wish seems also be additional support for 80/128 bit in RTL softfpu.

I'm aware of that and even started on the 128 bit thing some time back. Issue is that there seems to be only a limited set of PD libs for the full set of required elementary functions that are also calculated with reasonable precision (1-2 ULP). Actually I only found one that does 1 ULP - but that is a high speed implementation completely based on AVX2 intrinsics. The required approx series constants and range reductions are very hard to extract from that as it is using a mangled internal number format <sigh>. And I simply can not also do the math grunt work to derive these by myself - it's simply decades of CPU effort in there.

If you happen to have a link to an acceptable (for FPC) PD lib on this topic I'll have a thorough look again.

[srvaldez]

just for testing, I compiled a dll of the afore mentioned core library with a very simple test
when trying to link to the static library there are a number of unresolved symbols but there's no problem with the dll