[squeak-dev] Floats

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Oct 11 19:56:05 UTC 2017

2017-10-11 20:18 GMT+02:00 Bert Freudenberg <bert at freudenbergs.de>:

> On Wed, Oct 11, 2017 at 8:07 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> > On 11.10.2017, at 19:59, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> >
>> > On Wed, Oct 11, 2017 at 5:24 PM, Tobias Pape <Das.Linux at gmx.de> 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 -​
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

While at it, I also wonder if we should not support the hexadecimal format
%a of modern C/C++ for the purpose of interchange.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171011/d8bd4942/attachment.html>

More information about the Squeak-dev mailing list