Hi all.

What is the best/preferred way to write floatingpoint to a steam?

Since TStream doesn't have any native WriteFloat/Double and the likes, some conversion is needed - but what is a good strategy for this?

A simple conversion like Stream.WriteDWord( DWord(<some float variable>)) is not possible due to illegal type conversion.

Any help appriciated.

Regards,
Torsten.

Torsten Bonde Christiansen wrote

Since TStream doesn't have any native WriteFloat/Double and the likes, some conversion is needed - but what is a good strategy for this?

I use FloatStr() to do the conversion, then Write() to actually write it to a stream.

Regards,
- Graeme -

In my case I am trying to write a datetime value, and in order not to worry about the format, separators, etc. i would much rather just write the actual floating point value...

Regards,
Torsten.

Format the date/time as RFC3339 or ISO 8601 (they differe in details only) and you should not have a problem. ScanDateTime from strutils will happily perform the opposite operation.

Michael.

I will give it a try.

But out of curiosity is there a reason why there are not floating point Read/Write methods for TStream (and decendants)?

Regards,
Torsten.

Torsten Bonde Christiansen wrote

But out of curiosity is there a reason why there are not floating point Read/Write methods for TStream (and decendants)?

As

   procedure TStream.WriteQWord(q: QWord);
     begin
       WriteBuffer(q,8);
     end;

it's rather easy to do your own TStream.WriteDateTime procedure and friends.

-Michael

On 2016-01-12 10:45, Torsten Bonde Christiansen wrote: > Since TStream doesn't have any native WriteFloat/Double and the likes, > some conversion is needed - but what is a good strategy for this?

Depends on size constraints.
In the simple case you should convert float to locale-independent string value (no spaces, no commas separators) then write it. If the size does matter, you may convert float to corresponding byte array then write it.

Regards,
Serguei

Can I ask a naive question here please: does a binary stream store endianness anywhere? In other words, is there any indication that something running on ARM is about to get into trouble by reading something written by (big-endian) MIPS?

Should writing binary floating point to a stream note that it's IEEE format, just in case anybody ever tries to process it on a platform that supports alternatives?

Not that I'm aware of - i would think of it as a stream of bytes. Endianess is defined by the CPU not by the file.

It would be great if storing floating point could be in IEEE, to have a standard as reference.

Regards,
Torsten.

Mark Morgan Lloyd wrote

Can I ask a naive question here please: does a binary stream store endianness anywhere?

AFAIK, generally, such binary (file-, Network transfer, ....) formats are not supposed to be "natively" portable. To be portable they should be either propriety (defined by the *single* application that uses them) or Text-based (such as XML or "INITFILE").

-Michael

Thanks, I assumed that was the case but thought it worth checking.

I suppose that one could stream variants, i.e. the enumeration saying what one was followed by a value.

I'm not at all sure about this, but I think I've seen something that suggested that byte ordering in external representations was covered by the standard.

In our previous episode, Torsten Bonde Christiansen said:

What is the best/preferred way to write floatingpoint to a steam?

var d : double; // or single, avoid extended
d:=<some expression>;
stream.write(d,sizeof(d));
stream.read(d,sizeof(d));

All the stream helpers are just that.

One could add writedouble/single to the stream typehelpers in streamex.

I'm not even sure how (or even if) TStream decendants handles endianness for integers.... I'm guessing they are not.

Regards,
Torsten.

Am 13.01.2016 10:40 schrieb "Mark Morgan Lloyd" <

likes,

>>>>> some conversion is needed - but what is a good strategy for this? >>> >>> Depends on size constraints. >>> In the simple case you should convert float to locale-independent

string value (no spaces, no commas separators) then write it.

>>> If the size does matter, you may convert float to corresponding byte

array then write it.

>> >> >> Can I ask a naive question here please: does a binary stream store

endianness anywhere? In other words, is there any indication that something running on ARM is about to get into trouble by reading something written by (big-endian) MIPS?

> Not that I'm aware of - i would think of it as a stream of bytes.

Endianess is defined by the CPU not by the file.

what one was followed by a value.

That's not the task of TStream however. For that you should use a custom class that uses TStream under the hood.

>> Should writing binary floating point to a stream note that it's IEEE

format, just in case anybody ever tries to process it on a platform that supports alternatives?

>> > It would be great if storing floating point could be in IEEE, to have a

standard as reference.

I'm not at all sure about this, but I think I've seen something that

suggested that byte ordering in external representations was covered by the standard.

I've checked recently due to big endian problems in the Castle game engine and found out that endianess isn't really covered for floating points...

Regards,
Sven

likes,

>>>>>> some conversion is needed - but what is a good strategy for this? >>>> >>>> Depends on size constraints. >>>> In the simple case you should convert float to locale-independent

string value (no spaces, no commas separators) then write it.

>>>> If the size does matter, you may convert float to corresponding byte

array then write it.

>>> >>> >>> Can I ask a naive question here please: does a binary stream store

endianness anywhere? In other words, is there any indication that something running on ARM is about to get into trouble by reading something written by (big-endian) MIPS?

> > >> Not that I'm aware of - i would think of it as a stream of bytes.

Endianess is defined by the CPU not by the file.

what one was followed by a value.

> >>> Should writing binary floating point to a stream note that it's IEEE

format, just in case anybody ever tries to process it on a platform that supports alternatives?

>>> >> It would be great if storing floating point could be in IEEE, to have a

standard as reference.

> > > I'm not at all sure about this, but I think I've seen something that

suggested that byte ordering in external representations was covered by the standard.

I'm not even sure how (or even if) TStream decendants handles endianness

for integers.... I'm guessing they are not.

TStream always read in its native order. If you know that the data is of the opposite endianess you need to convert this yourself as TStream can't know that.

Regards,
Sven

In our previous episode, Torsten Bonde Christiansen said:

I'm not even sure how (or even if) TStream decendants handles endianness for integers.... I'm guessing they are not.

TStream is basically an abstraction for stream of bytes. The read<type> methods are just convenience, not some protocol.

As far as endianess go, see the streamex unit's class helper for TStream, and its use (here and there) in package chm.

Do you imply that, unlike floating point, endianess for integers are handled automatically by TStream?

Dennis

format, just in case anybody ever tries to process it on a platform that supports alternatives?

> > >>> > >> It would be great if storing floating point could be in IEEE, to have

a standard as reference.

> > > > > > I'm not at all sure about this, but I think I've seen something that

suggested that byte ordering in external representations was covered by the standard.

> > I've checked recently due to big endian problems in the Castle game

engine and found out that endianess isn't really covered for floating points...

handled automatically by TStream?

Not at all, but it could have been that IEEE floating points are defined to be always little endian for example.

Regards,
Sven