This patch demonstrates loss of precision through [makefilename] and zexy's [atoi] when processing 32-bit hex numbers. So 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;
While I don't know the details of what is going on here, it sounds like
you should file a bug in the bug tracker.
http://puredata.org/dev/bugtracker
.hc
On Dec 4, 2004, at 4:15 AM, Lex Ein wrote:
This patch demonstrates loss of precision through [makefilename] and zexy's [atoi] when processing 32-bit hex numbers. So 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;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://iem.at/cgi-bin/mailman/listinfo/pd-list
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into the
possession of everyone, and the receiver cannot dispossess himself of
it."
- Thomas Jefferson
Lex Ein wrote:
This patch demonstrates loss of precision through [makefilename] and zexy's [atoi] when processing 32-bit hex numbers.
I think the confusion could be avoided if zexy's [atoi] was named [atof], since that's what is is: it converts a string to a float (not to an int).
Marc Boon wrote:
Lex Ein wrote:
I think the confusion could be avoided if zexy's [atoi] was named [atof], since that's what is is: it converts a string to a float (not to an int).
no it does not convert a string to a float. it converts a string to an integer, then converts the integer to a float and finally outputs that float.
[atof] would convert a symbol "3.14159" into a float 3.14159 [atoi] does nothing like that. it will output a float 3.0
mfg.a.sdr IOhannes