I am trying to write some data to a textile and am looking at the 

 object. If I run the following code I get some behaviour I can not explain:

here is what the resulting textile looks like:

dataName.54
size 74
ÕÃå?ÕÃ@33S@ÕÃå@∞@

 function is supposed to be used or is this a bug?

I am trying to encode a mix of int and float data in the end. Would it be better to stringify it all?

I am trying to write some data to a textile and am looking at the new File() object. If I run the following code I get some behaviour I can not explain:

Am I misunderstanding how the writefloat32() function is supposed to be used or is this a bug? 

I am trying to encode a mix of int and float data in the end. Would it be better to stringify it all? 

bug-file-object-writefloat32

I would be really interested in knowing if that's the best approach though.

For now I am testing using the f.writeline(myArray.toString()); and when I need to read it I use newA = a.split(',').map(parseFloat);

I would be really interested in knowing if that's the best approach though.


 does not write the string/char representation of the float array but the values itself. Therefore they are not in a human readable form in your text file. If you want to read the values back use 

writefloat32() does not write the string/char representation of the float array but the values itself. Therefore they are not in a human readable form in your text file. If you want to read the values back use readfloat32()

Thanks for the information. Did I miss something in the documentation about this?? Since I want my .txt to be human readable, I will stick with my "workaround" for now.

It's just what the ref page says. I admit it doesn't give more explanations to clarify further. Within a plain text file (with no programming or scripting language defined) there is no human readable representation of an array of data. It takes char values and writes them down as bytes in the text file. When correctly interpreted i.e. by a text editor (or the File object - meaning the right byte order and character encoding style is assumed) these bytes are translated back to human readable characters. That is assumed to be known by a reader. The second sentence gives a hint though:

The byteorder property is taken into account when writing these values.

 property refers to the so-called endianness usually written as BOM (Byte Order Mark) in a text file. The BOM defines how the characters/char values are translated into numeric values for storing: 

http://en.wikipedia.org/wiki/Byte_order_mark.

But agreed, this can be confusing when new to this subject ...

It's just what the ref page says. I admit it doesn't give more explanations to clarify further. Within a plain text file (with no programming or scripting language defined) there is no  human readable representation of an array of data. It takes char values and writes them down as bytes in the text file. When correctly interpreted i.e. by a text editor (or the File object - meaning the right byte order and character encoding style is assumed) these bytes are translated back to human readable characters. That is assumed to be known by a reader. The second sentence gives a hint though:

The byteorder property is taken into account when writing these values. 

The byteorder property refers to the so-called endianness usually written as BOM (Byte Order Mark) in a text file. The BOM defines how the characters/char values are translated into numeric values for storing: http://en.wikipedia.org/wiki/Byte_order_mark.

[bug?] File() object writefloat32()