Re: Serialization of binary floating point numbers
On Sat, 18 May 2019 22:14:24 -0500 "J. Lewis Muir" wrote: > On 05/17, Sad Clouds wrote: > > A bit of a random question/thought - what is a good and portable > > method of storing/transmitting binary floating point numbers? > > Maybe heavier than you'd like, but Protocol Buffers has a double type: > > https://developers.google.com/protocol-buffers/docs/proto3#scalar > > Another possibility is XDR which has IEEE float and IEEE double types: > > https://en.wikipedia.org/wiki/External_Data_Representation > > Lewis OK thanks for the pointers, so XDR is what RPC is using, and most OSes seem to include it in their base system, so should be quite accessible and portable. Anybody knows of any advantages of Protobuf vs XDR? From what I can see, with XDR it's quite simple, you call a function to convert to/from external representation. With Protobuf you need to build special protocol compiler, define message format in .proto file, then use special compiler to encode the message, this sounds like a pain in the ass. Why didn't they use XDR in the first place? Then there is this blog https://reasonablypolymorphic.com/blog/protos-are-wrong/
Re: Serialization of binary floating point numbers
On 05/17, Sad Clouds wrote: > A bit of a random question/thought - what is a good and portable method > of storing/transmitting binary floating point numbers? Maybe heavier than you'd like, but Protocol Buffers has a double type: https://developers.google.com/protocol-buffers/docs/proto3#scalar Another possibility is XDR which has IEEE float and IEEE double types: https://en.wikipedia.org/wiki/External_Data_Representation Lewis
Re: Serialization of binary floating point numbers
I recall reading of a hexadecimal serialization of floating point numbers. I'm not sure of all the details, but it sounds like it would be a fairly easy way to exactly represent a whole class of FP formats. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: Serialization of binary floating point numbers
On Sat, 18 May 2019 17:23:57 +0200 Martin Husemann wrote: > On Sat, May 18, 2019 at 08:58:35AM +0100, Sad Clouds wrote: > > what I can see most of the modern hardware use 2's complement > > integer arithmetic and IEEE 754 floating point, but not sure if > > there are any specific exceptions I'm not aware of. > > There are variations in the ieee 754 formats though, and all details > depend on your use case and the "portability" you are trying to > achive. > > Martin So when you say there are variations, are you referring to IEEE 754-2008 decimal floating point numbers, or something else? There are only a few platforms that support this in hardware. The use cases are around storing floating point numbers on disk, or transmitting them across a network. For example, if you have different platforms with different FPU hardware, provided that you stick to IEEE 754, they all should be able to load floating point number and perform calculations with it, without any compatibility issues. Another example is SQLite REAL data type, which is 8-byte IEEE floating point number. Their databases are portable, so I assume you can read/write the same database across different architectures.
Re: Serialization of binary floating point numbers
On Sat, May 18, 2019 at 08:58:35AM +0100, Sad Clouds wrote: > what I can see most of the modern hardware use 2's complement > integer arithmetic and IEEE 754 floating point, but not sure if there > are any specific exceptions I'm not aware of. There are variations in the ieee 754 formats though, and all details depend on your use case and the "portability" you are trying to achive. Martin
Re: Serialization of binary floating point numbers
On Fri, 17 May 2019 21:06:14 +0200 Rhialto wrote: > On Fri 17 May 2019 at 17:37:45 +0100, Sad Clouds wrote: > > 1. Make sure software always built to use IEEE 754 format. > > For VAX, you would need to do some work there, since it natively uses > a different floating point format. It is the canonical example for > that, these days :-) I'm not up to date on whether there are math > libraries available that do ise IEEE soft-float. OK thanks for the info, I found some useful links on VAX: https://www.cv.nrao.edu/fits/os-support/vms/ieee2vax.c http://home.fnal.gov/~yang/Notes/ieee_vs_dec_float.txt However I don't think I'm going to bother supporting it, architectures like VAX are probably confined to museums and hobbyist's sheds. From what I can see most of the modern hardware use 2's complement integer arithmetic and IEEE 754 floating point, but not sure if there are any specific exceptions I'm not aware of.
Re: Serialization of binary floating point numbers
On Fri 17 May 2019 at 17:37:45 +0100, Sad Clouds wrote: > 1. Make sure software always built to use IEEE 754 format. For VAX, you would need to do some work there, since it natively uses a different floating point format. It is the canonical example for that, these days :-) I'm not up to date on whether there are math libraries available that do ise IEEE soft-float. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Serialization of binary floating point numbers
A bit of a random question/thought - what is a good and portable method of storing/transmitting binary floating point numbers? Anyone aware of any conversion functions in NetBSD that I can look at? Searching the Internet, there are various opinions and references on how to do it, but there doesn't seem to be a definitive answer. I'd like to avoid converting binary to text and then back to binary. So I'm thinking the following procedure should work: 1. Make sure software always built to use IEEE 754 format. 2. Convert number to network byte order. 3. Transmit binary data. 4. On the other end, convert from network to host byte order. I assume this should work for IEEE 754 32-bit, 64-bit and 128-bit floating point types. Can anyone think of any reasons where this could fail? I think most modern hardware now can cope with IEEE 754. Some embedded systems may not have floating point hardware, but then system software libraries should handle it.
