Need a library to write/read floats and doubles in IEEE754

[Pavel]

Hello,

Does anyone know a (preferably open-source) multi-platform C or C++
library that would be able to write and read C/C++ doubles and floats
to/from streambuf, char array or similar device in IEEE 754 with
reasonably optimal precision and performance?

The purpose is to exchange serialized doubles and floats between C/C++
and Java programs where Java serialization rules are used.

I tried to search for it on the Internet but, surprisingly, could not
find any mature code for this seemingly common purpose.

Thanks in advance,
-Pavel

[Pete Becker]

On 2008-03-05 23:01:51 -0500, Pavel
<dot_com_yahoo@ paultolk_revers e.yourselfsaid:

>
Does anyone know a (preferably open-source) multi-platform C or C++
library that would be able to write and read C/C++ doubles and floats
to/from streambuf, char array or similar device in IEEE 754 with
reasonably optimal precision and performance?

http://netlib2.cs.utk.edu/fp/dtoa.c

The general idea is that you convert floating point values to a base 10
text representation with as many digits after the decimal point as are
needed to distinguish the value being written from the two neighboring
values. Sometimes you need very few ("2.0"), and occasioinally you need
quite a few. Caution: it's hackerhead C code, and requires a fair
amount of study to understand what it's doing. There's also a paper
somewhere (I've lost track of it) that gives the theoretical
underpinnings.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

On Mar 7, 6:17 am, Pavel <dot_com_yahoo@ paultolk_revers e.yourself>
wrote:

James Kanze wrote:

I did not want to write myself and was looking for a library
because I am lazy and some corner cases should be worked out
(native representation does not necessarily represent all same
set of numbers as IEEE 754 representations ).

If you have to deal with a native representation that is not
IEEE, then you have to define behavior for corner cases. An IBM
double, for example, has more precision (but less range) than an
IEEE double: I suppose when outputting you round (the code I
posted truncates!), but what happens when you input something
that it too large.

I've heard that there may be similar cases even between IEEE
representations , at least where NaN's are involved---a non
trapping NaN may trap elsewhere, or something like that.

It's quite a bit of coding and testing so I wanted to find if
someone else has already done that before getting into it. I
guess I will start with this code of yours and then try to
work my way using standard C++. Certainly #ifdef - guarded
multi-platform version would do faster for each supported
architecture but hopefully the performance of the standard C++
code will suffice for my purpose.

Well, I'd very definitely not invest the effort in supporting
machines without IEEE until I had to. (The three I know of
today are all mainframes: one uses base 16, one uses base 8, and
the one that uses base 2 has 72 bit doubles. On the latter two,
you'll need special handling for ints as well, because they
don't use 2's complement either: there's one with 48 bit signed
magnitude, with 8 bits required to be 0, and the other uses 36
bit 1's complement. Porting networked software to those should
be quite amusing---except that both have Intel based front-ends
to handle the networking.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Shobhit Gupta]

On Mar 5, 11:01 pm, Pavel <dot_com_yahoo@ paultolk_revers e.yourself>
wrote:

Hello,

Does anyone know a (preferably open-source) multi-platform C or C++
library that would be able to write and read C/C++ doubles and floats
to/from streambuf, char array or similar device in IEEE 754 with
reasonably optimal precision and performance?

The purpose is to exchange serialized doubles and floats between C/C++
and Java programs where Java serialization rules are used.

I tried to search for it on the Internet but, surprisingly, could not
find any mature code for this seemingly common purpose.

Would this help ?
http://tpl.sourceforge.net/

Its an open source serialization library written in C.

[Pavel]

James Kanze wrote:

On Mar 7, 6:17 am, Pavel <dot_com_yahoo@ paultolk_revers e.yourself>
wrote:

>James Kanze wrote:

>I did not want to write myself and was looking for a library
because I am lazy and some corner cases should be worked out
(native representation does not necessarily represent all same
set of numbers as IEEE 754 representations ).

If you have to deal with a native representation that is not
IEEE, then you have to define behavior for corner cases.

True, that's why I hoped someone did it before me in a reasonable way :-).

An IBM
double, for example, has more precision (but less range) than an
IEEE double: I suppose when outputting you round (the code I
posted truncates!), but what happens when you input something
that it too large.

On input will have to check whether IEEE representation exceeds
implementation-specific limits from <climitand <cfloat>; if it does,
throw domain_error or do something similar; also, for output need to
check whether the number to be written is within the respective (single-
or double-) IEEE limit. Long story short, lots of work to do..

I've heard that there may be similar cases even between IEEE
representations , at least where NaN's are involved---a non
trapping NaN may trap elsewhere, or something like that.

True

Well, I'd very definitely not invest the effort in supporting
machines without IEEE until I had to. (The three I know of
today are all mainframes: one uses base 16, one uses base 8, and
the one that uses base 2 has 72 bit doubles. On the latter two,
you'll need special handling for ints as well, because they
don't use 2's complement either: there's one with 48 bit signed
magnitude, with 8 bits required to be 0, and the other uses 36
bit 1's complement. Porting networked software to those should
be quite amusing---except that both have Intel based front-ends
to handle the networking.)

You are right about those -- I do not need them (not right now, anyway);
the main problem even with mostly IEEE-ish architecture that you still
have to detect it (even if only to make sure the preprocessor balks on
unsupported architectures) and for that you need to detect the compiler
first -- both make and version -- because the macros that define the
architectures are implementation-specific and sometimes change between
versions -- and for that you have to first make a decision what versions
of compilers to support. I will need to support 4 compiler makes at
least; as I said, lots of work, at least 90% of which was already done
by others multiple times, better than I ever will.

Anyway, time to stop whining and start coding. Wish me luck.

-Pavel

[James Kanze]

On 8 mar, 05:53, Pavel <dot_com_yahoo@ paultolk_revers e.yourself>
wrote:

James Kanze wrote:

On Mar 7, 6:17 am, Pavel <dot_com_yahoo@ paultolk_revers e.yourself>
wrote:

James Kanze wrote:

I did not want to write myself and was looking for a library
because I am lazy and some corner cases should be worked out
(native representation does not necessarily represent all same
set of numbers as IEEE 754 representations ).

If you have to deal with a native representation that is not
IEEE, then you have to define behavior for corner cases.

True, that's why I hoped someone did it before me in a
reasonable way :-).

The problem isn't just the doing. The problem is specifying
what you mean by "a reasonable way".

An IBM
double, for example, has more precision (but less range) than an
IEEE double: I suppose when outputting you round (the code I
posted truncates!), but what happens when you input something
that it too large.

On input will have to check whether IEEE representation
exceeds implementation-specific limits from <climitand
<cfloat>; if it does, throw domain_error or do something
similar; also, for output need to check whether the number to
be written is within the respective (single- or double-) IEEE
limit. Long story short, lots of work to do..

If the absolute value you read is too big for your internal
representation, it's obviously an error (setting failbit would
be the usual behavior). If the absolute value is smaller that
min(), but not zero, however: is it an error, or do you use 0.0?
What if the value you read has more precision than you can
represent? Is it an error, or do you round.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pavel]

James Kanze wrote:

>>If you have to deal with a native representation that is not
IEEE, then you have to define behavior for corner cases.

>True, that's why I hoped someone did it before me in a
reasonable way :-).

The problem isn't just the doing. The problem is specifying
what you mean by "a reasonable way".

I meant defining, not implementing. I was answering to your statement above.

If the absolute value you read is too big for your internal
representation, it's obviously an error (setting failbit would
be the usual behavior).

I have already decided on a non-stream-related API, so there will be
nothing to set the failbit on. For signaling errors, I am leaning to
simple return codes but did not completely rejected the idea of throwing
std::domain_err or yet.

If the absolute value is smaller that

min(), but not zero, however: is it an error, or do you use 0.0?
What if the value you read has more precision than you can
represent? Is it an error, or do you round.

Will round. It is not my purpose to reject as many inputs as possible;
it is the other way around.

Regards
-Pavel