On Fri, 28 Jan 2011, Bryan Jurish wrote:
iirc, Miller has indicated in the past that he feels this sort of thing
should be done using arrays.
But a feeling is but a feeling. Now, how about a justification ?
But that's not the sort of thing one gets from Miller often.
(B) you must scale all size attributes (e.g. for re-allocation) by
1.0/sizeof(t_float), so to get an accurate byte length that is not a
multiple of sizeof(t_float), you need to actually store that length
additionally somewhere else
sizeof(t_float) is always a power of two, isn't it ? I haven't heard of
anyone using 80-bit or 96-bit floats as t_float or t_sample.
thus a size stored as float will be accurate up to 16777216.
This is regardless of whether you store size*4, size, or size/4 : floats
are quite scale-independent, but are perfectly so when the scalings are
powers of two (provided you don't overflow by scaling by pow(2,128) or so)
I think you could read a bit about the IEEE-754 standard :
http://en.wikipedia.org/wiki/IEEE_754
But especially some kind of short, direct tutorial that will make it
obvious what won't be rounded and what will be :
http://kipirvine.com/asm/workbook/floating_tut.htm
(C) saving array data with a patch and re-loading can cause data loss
(float truncation may mess up raw byte values)
for integers, all values from -1000000 to 1000000 will be correctly saved
(those two bounds will be encoded as -1e+6 and 1e+6, and all the rest will
look like plain integers).
(D) it's not really portable (byte order problems with load/save)
byte order problems won't happen with floats saved as text. they will
happen with floats saved as binary. they will also happen with UCS-2 text
saved as two floats per code point (no matter how you save the floats),
but if you use UTF-8 instead, or if you use one-float-per-codepoint, that
aspect will be safe.
2) If otoh you let the array remain a t_float* and just assign the
floats byte ((unsigned) char) or even wide character (wchar) values, then:
(A) you potentially waste a lot of memory
(strlen(str)*(sizeof(float)-1) bytes)
In 2011, wasting a lot of RAM is not a problem. Wasting too much RAM can
be a problem, and that's very relative, as quite often, the solution is to
wait until RAM is less expensive. I like the idea of not wasting any RAM,
but I recognise that this is because I got used to think about ways to
reduce waste, not because it's always good to worry about it.
Text is usually a lot smaller than video. It's not uncommon for me to
store a buffer of 64 frames of video in colour. In 640x480, that's over 55
megs, and that's tiny compared to the total amount of RAM the computer
has. How often do you need that much text at once in RAM ?
(C) if you really want to store your string data in an array, you can
use [str] or [pdstring] together with e.g. [tabdump] and [tabset] from
zexy, which just makes the conversion overhead explicit.
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).
I think there are workarounds for both techniques, but not without
patching the pd core code, and if we're going to patch the core code, we
might as well take a patch that does the job "right" (i.e. Martin's)...
If all of this can work as externals without hairy workarounds, then you
don't need to be obsessing about patching pd's core code, and that's a
good thing, especially if you aim to be patching vanilla's.
_______________________________________________________________________
| 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
