This patch demonstrates loss of precision through [makefilename] and zexy's [atoi] when processing 32-bit numbers (signed long). Either atoi should really be atol (long int or long double), or all floats should be long double for maximum mantissa precision, or both. If I'm misunderstanding something, lemme know.
These 32-bit numbers are for use as control, where bitfields are important; such loss of precision can have dramatic undesirable effects.
At first glance, Microsoft C and GNU both provide quite adequate double and long double mantissa size, so the existence of this data degradation is odd.
#N canvas 195 73 366 348 10; #X obj 16 166 >> 8; #X obj 16 124 >> 8; #X obj 16 207 >> 8; #X obj 22 144 & 255; #X obj 23 186 & 255; #X obj 23 228 & 255; #X obj 24 101 & 255; #X obj 16 80 int; #X text 204 17 32-bit value; #X floatatom 57 121 3 0 0 0 - - -; #X floatatom 56 165 3 0 0 0 - - -; #X floatatom 56 210 3 0 0 0 - - -; #X floatatom 57 247 3 0 0 0 - - -; #X floatatom 250 81 15 0 0 0 - - -; #X symbolatom 132 127 15 0 0 0 - - -; #X msg 43 16 0x03030302; #X msg 132 17 0x03030303; #X obj 132 53 atoi; #X obj 132 101 makefilename 0x%x; #X obj 186 163 atof; #X obj 186 189 atol; #X obj 250 213 >> 8; #X obj 250 171 >> 8; #X obj 250 254 >> 8; #X obj 256 191 & 255; #X obj 257 233 & 255; #X obj 257 275 & 255; #X obj 258 148 & 255; #X obj 250 127 int; #X floatatom 291 168 3 0 0 0 - - -; #X floatatom 290 212 3 0 0 0 - - -; #X floatatom 290 257 3 0 0 0 - - -; #X floatatom 291 294 3 0 0 0 - - -; #X connect 0 0 2 0; #X connect 0 0 4 0; #X connect 1 0 0 0; #X connect 1 0 3 0; #X connect 2 0 5 0; #X connect 3 0 10 0; #X connect 4 0 11 0; #X connect 5 0 12 0; #X connect 6 0 9 0; #X connect 7 0 6 0; #X connect 7 0 1 0; #X connect 13 0 28 0; #X connect 15 0 17 0; #X connect 16 0 17 0; #X connect 17 0 7 0; #X connect 17 0 13 0; #X connect 17 0 18 0; #X connect 18 0 14 0; #X connect 21 0 23 0; #X connect 21 0 25 0; #X connect 22 0 21 0; #X connect 22 0 24 0; #X connect 23 0 26 0; #X connect 24 0 30 0; #X connect 25 0 31 0; #X connect 26 0 32 0; #X connect 27 0 29 0; #X connect 28 0 27 0; #X connect 28 0 22 0;
On Sun, 5 Dec 2004, Lex Ein wrote:
At first glance, Microsoft C and GNU both provide quite adequate double and long double mantissa size, so the existence of this data degradation is odd.
Pd Floats are 32-bit, or 1:8:23-bit to be exact. So you can't have more than 24 significant bits, and so (1<<24)+1 = 16777217 is the first integer not representable as a float (it gets rounded).
Pd is currently pretty much stuck to float32, Miller having refused the int/float separation and any kind of number type distinction; there is no provision for anything other than float32.
So if you want more precision you will have to cut down your data into smaller pieces, or use something else than Pd for handling those values that need more precision. Some of the scripting languages connectable to Pd support float64 and/or illimited-precision integers (both Ruby and Scheme have those two types; Python must have something similar too)
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Mathieu Bouchard wrote:
On Sun, 5 Dec 2004, Lex Ein wrote:
At first glance, Microsoft C and GNU both provide quite adequate double and long double mantissa size, so the existence of this data degradation is odd.
Pd Floats are 32-bit, or 1:8:23-bit to be exact. So you can't have more than 24 significant bits, and so (1<<24)+1 = 16777217 is the first integer not representable as a float (it gets rounded).
Pd is currently pretty much stuck to float32, Miller having refused the int/float separation and any kind of number type distinction; there is no provision for anything other than float32.
So if you want more precision you will have to cut down your data into smaller pieces, or use something else than Pd for handling those values that need more precision. Some of the scripting languages connectable to Pd support float64 and/or illimited-precision integers (both Ruby and Scheme have those two types; Python must have something similar too)
I agree with Lex that float64 aka double would be a better choice than float32, since all current hardware has 64-bit fpus anyway, it would hardly present a performance penalty, besides the obvious increase in memory usage.
Maybe you could just recompile Pd with a '#define float double' ?
Hi, list! is it possible to control pd patches using sms messages? Do anybody have tried something like this?
i want to use the sms messages that a group of people are sending to each other with their cellphones to control a pd patch.
any idea about this?
many thanks
punchik
hi,
I'm also thinking about that but still doesn't have time to get my hands dirty.
If your running mac, it'll quite easy to redirect the SMS from the address (place your phone beside your computer and transfer via bluetooth) book via applescript/ perl/ python into PD (using OSC).
Do you have any other idea?
Cheers, SFS
On 6 Dec 04, at 12:28 AM, siggmuss wrote:
Hi, list! is it possible to control pd patches using sms messages? Do anybody have tried something like this?
i want to use the sms messages that a group of people are sending to each other with their cellphones to control a pd patch.
any idea about this?
many thanks
punchik
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
slimboyfatboyslim http://www.slimboyfatboyslim.org
siggmuss wrote:
Hi, list! is it possible to control pd patches using sms messages? Do anybody have tried something like this?
i want to use the sms messages that a group of people are sending to each other with their cellphones to control a pd patch.
this seems to be tightly correlated with the thread about long integers and floats. why not put it in there ?
btw, pd itself doesn't have sms support (and i know of no external that provides it); but their should be plenty of sms-daemons (e.g. for linux) out their and it should be easy to bridge between the 2 of them.
mfg.asd.r IOhannes
Marc Boon wrote:
Maybe you could just recompile Pd with a '#define float double' ?
this should read #define t_float double
and then you would have to convince all external's-developpers to use "t_float" instead of "float" (which they should do anyhow) and then you would have to recompile all used externals.
this wouldn't be too much work, but unfortunately neither pd nor the externals use t_float consistently (at least when i last tried to do something like this which is some time apast)
mfg.asd.ads IOhannes
IOhannes m zmoelnig wrote:
Marc Boon wrote:
Maybe you could just recompile Pd with a '#define float double' ?
this should read #define t_float double
and then you would have to convince all external's-developpers to use "t_float" instead of "float" (which they should do anyhow) and then you would have to recompile all used externals.
this wouldn't be too much work, but unfortunately neither pd nor the externals use t_float consistently (at least when i last tried to do something like this which is some time apast)
to deal with this bad practice, you could define both:
#define t_float double #define float double
Hi list, do anybody have compiled creb 0.9 , or 0.8, or 0.7 for windows?
i have creb 0.3 but its very old, it doesnt has a lot of objects i want to try
thankx
pun
pun chik punchik@fastmail.fm
On Dec 6, 2004, at 2:34 AM, Marc Boon wrote:
to deal with this bad practice, you could define both:
#define t_float double #define float double
That second one probably won't work with any compiler. Redefining basic data types should not be allowed - they are reserved for a reason. If nothing else, #define float double is a million times worse bad practice compared to what you are trying to fix. Donald Knuth would murder you on the spot for doing that. ;)
cgc
chris clepper wrote:
On Dec 6, 2004, at 2:34 AM, Marc Boon wrote:
to deal with this bad practice, you could define both:
#define t_float double #define float double
That second one probably won't work with any compiler. Redefining basic data types should not be allowed - they are reserved for a reason. If nothing else, #define float double is a million times worse bad practice compared to what you are trying to fix. Donald Knuth would murder you on the spot for doing that. ;)
#define float double int main(int argc, char* argv[]) { printf("sizeof(float) = %d\n", sizeof(float)); printf("sizeof(double) = %d\n", sizeof(double)); return 0; }
prints: sizeof(float) = 8 sizeof(double) = 8
without the #define, it prints: sizeof(float) = 4 sizeof(double) = 8
Marc Boon wrote:
chris clepper wrote:
On Dec 6, 2004, at 2:34 AM, Marc Boon wrote:
to deal with this bad practice, you could define both:
#define t_float double #define float double
That second one probably won't work with any compiler. Redefining basic data types should not be allowed - they are reserved for a reason. If nothing else, #define float double is a million times worse bad practice compared to what you are trying to fix. Donald Knuth would murder you on the spot for doing that. ;)
#define float double int main(int argc, char* argv[]) { printf("sizeof(float) = %d\n", sizeof(float)); printf("sizeof(double) = %d\n", sizeof(double)); return 0; }
prints: sizeof(float) = 8 sizeof(double) = 8
without the #define, it prints: sizeof(float) = 4 sizeof(double) = 8
Yes this works fine because the preprocessor replaces every instance of 'float' with double just like a search and replace operation in a text editor. The real problems are going to show up where people have used an integer like 0x7FFFFFFF to fill a float variable, or in the case of the OSC parser, where a float is treated as an int for purposes of unloading the buffer -- both of these are sloppy programming practice exactly because they work at the time but cause trouble when either the representation or the container change.
Martin
#define float double int main(int argc, char* argv[]) { printf("sizeof(float) = %d\n", sizeof(float)); printf("sizeof(double) = %d\n", sizeof(double)); return 0; }
prints: sizeof(float) = 8 sizeof(double) = 8
without the #define, it prints: sizeof(float) = 4 sizeof(double) = 8
sure, it will probably work, if you recompile the WHOLE system including EVERY library, at least every library that is used by all the externals ... well, i hope, none of the libraries uses hand-coded assembler code that requires a float to be a float ... definitely the sse instructions in the devel_ branch will crash your system if you are trying to use them!!!
be warned ... tim
Tim Blechmann wrote:
be warned ... tim
so this has become a long thread where everybody (including me) seems to want to make sure, that the worst thing you can think about is to change the precision of pd's numbers. this is not true.
basically it would be very good, if we could change pd's "float" to whatever we need, at least to "double" by just changing a single line of code. this is why there is a "typedef float t_float"-line in m_pd.h in the first place! this would be perfect especially when thinking about newer architectures like 64bit.
anyhow, as this thread has shown it is a hard thing to do: however, people (coders) should be encouraged to
- use pd's data-types whenever possible rather than built-in's
throughout the code 2) mark code that depends on data-types as such; of course hand-tailored code like SSE-instructions will not work survive data-type changes, but at least proper mark-up would make it easy to spot this code. the problem of cahgning-datatypes also encourages (in my opinion) to write such code at least 2 times: once as a generic implementation that would compile on any architecture and with "any" data-size and once as an "optimized" one.
mfg.a.dr IOhannes
Donald Knuth would not commit murder. He might mention Mr. Boon as "deprecated" in his next book, or worse, not mention him at all.
On Mon, 6 Dec 2004 08:51:35 -0600, "chris clepper" cgc@humboldtblvd.com said:
On Dec 6, 2004, at 2:34 AM, Marc Boon wrote:
to deal with this bad practice, you could define both:
#define t_float double #define float double
That second one probably won't work with any compiler. Redefining basic data types should not be allowed - they are reserved for a reason. If nothing else, #define float double is a million times worse bad practice compared to what you are trying to fix. Donald Knuth would murder you on the spot for doing that. ;)
cgc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
-
chris clepper -
IOhannes m zmoelnig -
Lex Ein -
Marc Boon -
Martin Peach -
Mathieu Bouchard -
pun chik -
siggmuss -
slimboyfatboyslim -
Tim Blechmann