Hi all
I'm a bit stumped… What is our canonical way to put a Float onto a (binary) stream? To be precise a IEEE754 double precision 64-bit float onto a stream, of which I only know that it is a binary one. I found ByteArray>>doubleAt:{put:}bigEndian:, but they have neither senders nor test _and_ it is not a stream. What do y'all use? Best regards -Tobias |
Hi all You write them as two words, like e.g. in DataStream>>writeFloat:. - Bert - |
> On 11.10.2017, at 19:59, Bert Freudenberg <[hidden email]> wrote: > > On Wed, Oct 11, 2017 at 5:24 PM, Tobias Pape <[hidden email]> wrote: > Hi all > > I'm a bit stumped… > > What is our canonical way to put a Float onto a (binary) stream? > To be precise a IEEE754 double precision 64-bit float onto a stream, of which I only know that it is a binary one. > > I found ByteArray>>doubleAt:{put:}bigEndian:, but they have neither senders nor test _and_ it is not a stream. > > What do y'all use? > > You write them as two words, like e.g. in DataStream>>writeFloat:. Quite. yes. But I find it strange that our read/write streams support various integer and string reading/writing helpers, but none for floats… Best regards -Tobias |
I guess file formats using integers and strings are way more common than ones storing binary floats. - Bert - |
2017-10-11 20:18 GMT+02:00 Bert Freudenberg <[hidden email]>:
Note that I consider word as a confusing term in Smalltalk, and particularly in Squeak... Sometimes it's a uint16 as in PositionableStream>>nextWord (consistent with visualworks WordArray) Sometimes it's a uint32 as in Squeak WordArray or Float>>basicAt: comment Not speaking of the VM where BytesPerWord is also the size of pointer in underlying machine (either 4 or 8 bytes). And note that Float may also be confusing for example thru ByteArray>>floatAt: and FloatArray... Looking at Stream hierarchy, the nextInt32 (or int32) and co are implemented at a strange level (PositionableStream). On one hand, they don't require the stream to be positionable and could be even higher... On the other hand, they consider the stream to be operating on a sequence of bytes what it is not at this level of generality (it operates on a sequence of Objects). In Xtream, support for such messages would probably require a specific wrapper... While at it, I also wonder if we should not support the hexadecimal format %a of modern C/C++ for the purpose of interchange. Nicolas |
In reply to this post by Bert Freudenberg
The same issue exists in ASN1 support, none for float type tag 9.
I would love to add this support but I am unsure how to breakdown
a float into mantissa, base and exponent. Here is a description of
how ASN1 formats a REAL into the stream of bytes: Type REAL takes values that are the machine representation of a real number, namely the triplet (m, b, e), where m is the mantissa (a signed number), b the base (2 or 10), and e the exponent (a signed number). For example, the representation of the value 3.14 for the variable Pi, declared as Pi ::= REAL, can be (314, 10, -2). Three special values, PLUS-INFINITY, 0, and MINUS-INFINITY, are also allowed.Here are some sample values: I have not parsed out these samples into these components so it's greek. Alan On 10/11/2017 02:18 PM, Bert
Freudenberg wrote:
-- Thank you for your consideration, Alan |
Here is the spec they are referencing in this thread: https://stackoverflow.com/questions/4975005/how-should-i-interpret-the-asn-1-ber-standard-for-reals
On 10/12/2017 05:36 AM, Alan Pinch
wrote:
-- Thank you for your consideration, Alan |
Free forum by Nabble | Edit this page |