[PD] standard encoding of pd files in each system?

[Mathieu Bouchard]

On Sat, 29 Jan 2011, Bryan Jurish wrote:
> Yup, all freely stipulated.  My issue was not so much with the use of
> floats qua floats to store size data, rather the necessity of storing
> size data *in addition to* the size reported by the array itself.
> In this scenario, we're blatantly re-casting the array's (t_float*) into 
> a (char*) and reading/writing raw bytes.

Ok, I thought you were going to write one codepoint per float and not do 
any reinterpret_cast.

I'd advise against relying on reinterpret_cast hacks like this, and 
instead, add support for other number types in the t_array struct and 
supporting functions. In that case it'd become significantly closer to 
struct Grid, but without the support for multiple dimensions of indices.

This change could also prevent wasting half of the t_array memory when 
storing floats on 64-bit computers, which is currently a good source of 
ridicule.

> Yes.  See above re:
> char *s;
> garray_getfloatarray(a,size,(float **)&s);

This is "deprecated" since 0.41, but really, this is a function 
call that never ever worked properly in 64-bit mode. You need to use 
garray_getfloatwords instead, which returns a t_word.

> No.  See above.  Messing about with typecasts is very 
> implementation-dependent, and afaik IEEE-754 doesn't define how its 
> components are to be implemented, only the formal criteria an 
> implementation must satisfy.

If you (or pd) never actually read the contents as float values in your 
use of reinterpret_cast to store, it doesn't matter, as you're doing 
nothing with float* that may depend on the difference between, say, float* 
and char*.

But you're not supposed to be using float* anymore, just t_word*, if you 
want to continue with the reinterpret_cast hack.

> deep hole very very quickly.  fwiw, the raw text of the whole corpus I
> work with these days runs about 1G.  A single file with all intermediate
> data can easily run over 400MB.  I really wouldn't want to go to N*4
> there...

4096 MB of DDR3 RAM is currently 37,99 $, going downhill. So, even with 
N*8, it doesn't look like the end of the word. (l)

But I'd still advocate adding multiple number type support to arrays.

>> GridFlow's grids support the byte format (unsigned char). This is one of
>> the six allowed grid formats, and perhaps the 2nd most used (after
>> signed int).
> But GridFlow isn't vanilla either.

How many solutions do you want to reject ?

> I think it probably can, but it's likely to amount to dependence on more
> than offered by just pd-vanilla (e.g. GridFlow, Martin's patch, etc.).

Duh. Now do you really think you're saving yourself so much work by not 
installing easy-to-install software ? On Ubuntu and OSX, you can install 
both Martin's blobs and GridFlow with not much more than two clicks.

But I was mentioning GridFlow just to tell you what's in there. From 
there, not only you can decide to use GridFlow, but if you decide to 
instead modify Pd, you can look at how GridFlow does it : isn't that 
interesting ?

> I suppose I could make an array-like external specifically for handling 
> string buffers, but that's essentially what Martin's patch does, so why 
> re-invent the wheel?

I think that how solutions can differ in the most notable way, is about 
where the string is actually stored, how you can keep one, how long you 
can keep it (when does it get deleted) and can you make a list of strings 
without having one [str] object per element. Do you agree ?

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC