Real number binary format

No response to this on the NUG. Maybe some one from 4D could provide some insight?

REAL TO BLOB($real;$blob;Extended real format)

Produces a 10 byte blob representation. Same when you use VARIABLE TO BLOB. Does this correspond to C “long double” format or is it something that is specific to the old PPC Macintosh architecture? I’m trying to convert double floats in another system into blobs that 4D can read.

Hi John,
have you read https://en.wikipedia.org/wiki/IEEE_754#Extended_and_extendable_precision_formatsthis>? The “80-bit format” they describe = 10 bytes. Seems hard to convert…

Have you tried this ?

http://www.binaryconvert.com/convert_double.html?

Nice :smiley:

Unfortunately translating js in 4d is my nightmare :scream:

I have always understood 4D real to be 8 byte double.

if the commands returns 10 bytes, maybe 2 bytes are signatures,
so that the reverse command can restore the original variable.

see this archive pdf

http://www.pluggers.nl/downloads/4D%20Plugin%20SDK%20v11.pdf

“real values on 10 bytes is no longer supported.”

would this work?

https://github.com/miyako/4d-plugin-float

I think the proper way to do it would be to use
blob commands and bitwise operators to construct the blob procedurally.

real to blob is not designed for this purpose,
although, you might be able to hack the command by stripping off the type signature,
and maybe do some endian byte swapping.

Hi Arnaud,

Thanks for the link, that might be what I’m looking for. It links to a page with more detail here:

I’ll try to put together some samples and see if it matches up with what 4D generates.

Hi Bruno,

That gives an 8 byte double float representation. That corresponds to the “PC double real format” option with REAL TO BLOB. I have that one figured out. But maybe the code for that might help me to generate the 10 byte format.

Hi Miyako,

: Keisuke MIYAKO

if the commands returns 10 bytes, maybe 2 bytes are signatures,
so that the reverse command can restore the original variable.

That is interesting, I’ll check into it. I found some reference (can’t locate now) that the PPC used a 10 byte double representation. That is what I expected 4D used. If it is really just a standard IEEE 8 byte double precision value, that would make things simpler if I can figure out how to do the padding correctly.

Hi John,

The Extended format is really something from the past, way back to the days of 4D version 2 and 3 when 4D used this format to store real values. It is only there for backward compatibility. It has no practical use nowadays. If I remember correctly 4D witched to the 64-bit double format around the time 4D v6 was introduced.

I suggest you use the “PC double real format”. This is the equivalent of a double in “C” using little endian byte ordering. This will produce the same binary output as other programming languages.

HTH,

Rob

Hi Rob,

I would love to ignore the 80 bit format, but 4D uses it for VARIABLE TO BLOB, BLOB TO VARIABLE. The goal is to exchange binary data (e.g. large arrays) with another environment and avoid things like converting to and from JSON.

I have at least (mostly) convinced myself the 80 bit “Extended Format” is the x86 extended precision format described in https://en.wikipedia.org/wiki/Extended_precision and not some unknown format tied to the old PPC architecture. The “long double” type in C.

The Racket programming language has direct support for extended floating point numbers. The example below gives the same byte sequence as 4D except for minor variations in the last byte (assumedly because of the higher precision representation in Racket).

Code :
(bytes->list (extfl->floating-point-bytes 33.3333t0 #t))
'(64 4 133 85 76 152 95 6 246 148)

<code 4D>
C_BLOB($blob)
C_REAL($num)
$num:=33.3333

REAL TO BLOB($num;$blob;Extended real format)

</code 4D>

https://docs.racket-lang.org/reference/extflonums.html

: John DESOI

I would love to ignore the 80 bit format, but 4D uses it for VARIABLE
TO BLOB, BLOB TO VARIABLE. The goal is to exchange binary data (e.g.
large arrays) with another environment and avoid things like
converting to and from JSON.
Hi John,

If the goal is to exchange binary data with another environment, then you should not use VARIABLE TO BLOB and BLOB TO VARIABLE since they use a proprietary format. The format only makes sense within 4D. Instead use REAL TO BLOB, which gives you complete control over the binary representation of numbers.