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