I have a created a unit FloatView to help you inspect in detail 32-bit (Single) and 64-bit (Double) IEEE 754 floating-point values (in case "every bit counts; note that when floating-point numbers are output in decimal, some information is inevitably lost).

I would like to contribute this unit, and offer it for further integration into FreePascal.

What would I need to do to release it under the same license as other FreePascal libraries?

Would there be any interest in incorporating it?

Here are the supported operations (for Single; a similar set exists for Double):

function SingleToStrBits ( const x: Single ): String; { returns string with bits for sign, biased exponent, and fraction } function SingleToStrBinary ( const x: Single ): String; { returns string with binary scientific representation of x: NaN, +/-Infinity, +/-B.B___Bd+/-E, where
'B' is a bit, 'd' stands for '*2^' and 'E' is the exponent in decimal } function PowerOf2Single ( const x: Single; n: Integer ): Single; { returns x * 2 ^ n }
procedure FlipBitSingle ( var x: Single; i: BitIndexSingle ); { flips bit i of x }
function SuccSingle ( const x: Single): Single;
{ returns successor of x }
function PredSingle ( const x: Single): Single;
{ returns predecessor of x }

Best regards,

Tom

Looks interesting.

Regards,

Adriaan van Os

Post the sources somewhere using the license header we use?

Would there be any interest in incorporating it?

If it's endian safe and if there are tests, I propose to incoperate it in math.

In our previous episode, Florian Klaempfl said:

> Would there be any interest in incorporating it? If it's endian safe and if there are tests, I propose to incoperate it in math.

The "Tostring" stuff should go into sysutils or strutils.

I intend to do just that. I was considering the use of plain GPL, rather than LGPL. However, I wonder if that would interfere with the incorporation into FreePascal.

Is it the case that all FPC libraries use (a variant of) LGPL? I am willing to use that license, but if GPL is an option, I would prefer that.

> Would there be any interest in incorporating it? If it's endian safe and if there are tests, I propose to incoperate it in math.

The old version initially was not, and the next version resolved that through conditional compilation. It used a set-of construct to access the bits of floating-point numbers.

The current version is safe on most "reasonable" processors.

Let me explain. I use 32-bit (Cardinal) and 64-bit (QWord) integers to access the bits of Single/Double values. The IEEE 754 standard format for floating-point numbers was specifically designed to allow the use of some integer operations on the representation to implement some floating-point operations, because this gives an opportunity to save on hardware. In particular, succ and pred on the floating-point number bit pattern _interpreted_as_integer_ will yield the next larger/smaller floating-point number.

Therefore, I believe that my current implemenation is endian-safe on processors that exploit the IEEE 754 standard wisely.

In particular, I tested it on Intel and PowerPC (which have opposite endianness; though PowerPC can switch endianness).

The unit comes with a separate test driver. There are also some examples.

Tom

There are also some constants and (conversion) types shared by the mathematical operations and ToString operations. Where would they go?

Tom

In our previous episode, Tom Verhoeff said:

Neither are good. GPL is mostly definitely not allowed for library routines (it is fine for the compiler, IDE or utils)

Is it the case that all FPC libraries use (a variant of) LGPL?

LGPL-with-linking-exception to be precise. (see rtl/copying.fpc for the differences with ordinary LGPL)

This is a bit more liberal than LGPL either, otherwise everybody would have to linking dynamically to FPC libs, which is technically hard to impossible. (and not desirable to make that mandatory anyway).

I am willing to use that license, but if GPL is an option, I would prefer that.

Not for library routines. GPLed library routines are useless. Even GNU doesn't do that.

In our previous episode, Tom Verhoeff said:

Sysutils is imported by both math and strutils. It depends a bit on the nature and number of them. This would speak for adding them to sysutils rather than strutils.

I would suggest to put this routines in a new unit, to keep the existing base units small and clean.

In our previous episode, Felipe Monteiro de Carvalho said:

I would suggest to put this routines in a new unit, to keep the existing base units small and clean.

Fragmenting the same kind of functionality over several units is IMHO not clean.

Or they would have to make the object files of their programs available to their users so that the latter can relink these with newer versions of the rtl.

Jonas

Felipe Monteiro de Carvalho wrote

I would suggest to put this routines in a new unit, to keep the existing base units small and clean.

How about naming them FloatUtils?

Tom

Marco van de Voort wrote

> > > > Post the sources somewhere using the license header we use?

I made the source available as a Contributed Unit using a modified LGPL. You can find a zip archive here:

<http://www.win.tue.nl/~wstomv/software/float-view/>

as well as individual files (float-view.zip and float-view-1_0.zip are links to the same file).

For some reason, when I go there, it does not show the README.txt, but is is there:

<http://www.win.tue.nl/~wstomv/software/float-view/README.txt>

Feel free to incorporate it in the RTL.

Best regards,

Tom