On Mar 23, 7:26 am, Albert van der Horst <alb...@[EMAIL PROTECTED]
>
wrote:
> Binary floating point representation are never "implementation neutral".
> You may be lucky, e.g. if both sides use IEEE f.p.
If DF! and SF! exist, and its a Forth-94 system, then that uses IEEE
f.p. ... if it does not have IEEE f.p., it does not present DF! SF!
and friends.
For a flat matrix, byte order, IEEE 32 or 64, row size, column size,
and rows of columns or columns of rows would be the information that
would have to be in the accompanying .DSC file, and IMHO, none of that
would ever be worthwhile encoding, even for a micro-controller.
If it was me, I'd write a CSV file with a description in the first
line, as a single-item line, followed by a header consisting of a
series of descriptive labels and their value for things like #rows and
#columns, a first row consisting of labels, then a blank line, then
the data. That loads quickly into a spreadsheet where the information
to work with it is available up top and all the descriptive meta data
is up top and clearly distinct from the data.
That'd be using the REPRESENT from the FLOATS wordset, targeted to a
buffer with ," at its head, and then the pictured numeric output for
the power, and the concluding " punctuation. A quote-delimited label
to start the line, and you have a good floating point array to CSV
routine.
Restrict the labels to Latin-1, and its even automatically UTF-8
Unicode.
|
