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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
