Re: [PD] Some more float weirdness/fun
Le 2012-03-10 à 16:31:00, Charles Henry a écrit : How about an abstraction that uses <= against 2xepsilon*|input|? That would be a reliable automatic way to ignore single-bit rounding errors. Don't you wish rounding errors would be at most single-bit. But as you compose more operations together, error can accumulate and/or amplify. This is why no-one uses a definition of == with a hardcoded epsilon in it, in any programming language that I ever heard of. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
On 3/10/12, Lorenzo Sutton wrote: > On 09/03/12 19:18, Quim Llimona wrote: >> It's well-known that floats can't be treated the same way as integers... >> but since PD is aimed at non-engineers and non-scientists I think it >> would be a good idea to implement the "good" comparison algorithms (i.e. >> checking against a threshold, etc) inside [==] and so, just to make >> patching easier. Maybe it's already supposed to behave this way... > > No, no...I don't agree (and hope initiating the thread didn't suggest > this idea). [==] should be what it says exact comparison. Actually in > the patch I was making it would have been simple to put in a [>=] > instead which basically *is* a threshold... I just thought it would be > nice to point out some float fun given all the discussions :) > > Lorenzo. How about an abstraction that uses <= against 2xepsilon*|input|? That would be a reliable automatic way to ignore single-bit rounding errors. I'm just using this page as a reference: http://en.wikipedia.org/wiki/Machine_epsilon There's two inputs, so I'd choose the largest of them and use that in calculating the threshold. The test patch below just takes a vertical slider from -1e-7 to 1e-7 and adds the value to 0.999 to be compared against. This patch needs a little improvement--it seems to be obeying a threshold which is a little closer to 8.9e-8 (which is greater than the 32-bit machine epsilon so it still does what is wanted with a little extra room) nearly_equal.pd #N canvas 86 491 682 612 10; #X obj 91 39 inlet; #X obj 137 39 inlet; #X obj 182 39 \$1; #X obj 216 39 loadbang; #X obj 94 140 abs; #X obj 98 345 <=; #X obj 139 110 abs; #X obj 185 110 abs; #X obj 93 74 t f f; #X obj 138 74 t f f; #X obj 140 212 >=; #X obj 189 209 <; #X obj 139 145 f; #X obj 186 144 t b f; #X obj 202 244 *; #X obj 140 172 t f f; #X obj 140 244 *; #X obj 94 108 -; #X obj 140 276 +; #X obj 140 308 * 1.192e-07; #X obj 97 391 outlet; #X connect 0 0 8 0; #X connect 1 0 9 0; #X connect 2 0 17 1; #X connect 3 0 2 0; #X connect 4 0 5 0; #X connect 5 0 20 0; #X connect 6 0 12 0; #X connect 7 0 13 0; #X connect 8 0 17 0; #X connect 8 1 6 0; #X connect 9 0 17 1; #X connect 9 1 7 0; #X connect 10 0 16 0; #X connect 11 0 14 0; #X connect 12 0 15 0; #X connect 13 0 12 0; #X connect 13 1 10 1; #X connect 13 1 11 1; #X connect 13 1 14 1; #X connect 14 0 18 1; #X connect 15 0 10 0; #X connect 15 1 11 0; #X connect 15 1 16 1; #X connect 16 0 18 0; #X connect 17 0 4 0; #X connect 18 0 19 0; #X connect 19 0 5 1; nearly_equal_test.pd #N canvas 0 25 264 184 10; #X obj 118 79 nearly_equal 0.999; #X obj 38 27 vsl 15 128 -1e-07 1e-07 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 0 1; #X floatatom 115 135 5 0 0 0 - - -; #X obj 116 18 + 0.999; #X connect 0 0 2 0; #X connect 1 0 3 0; #X connect 3 0 0 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
On 09/03/12 19:18, Quim Llimona wrote: It's well-known that floats can't be treated the same way as integers... but since PD is aimed at non-engineers and non-scientists I think it would be a good idea to implement the "good" comparison algorithms (i.e. checking against a threshold, etc) inside [==] and so, just to make patching easier. Maybe it's already supposed to behave this way... No, no...I don't agree (and hope initiating the thread didn't suggest this idea). [==] should be what it says exact comparison. Actually in the patch I was making it would have been simple to put in a [>=] instead which basically *is* a threshold... I just thought it would be nice to point out some float fun given all the discussions :) Lorenzo. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
Le 2012-03-09 à 19:18:00, Quim Llimona a écrit : It's well-known that floats can't be treated the same way as integers... but since PD is aimed at non-engineers and non-scientists I think it would be a good idea to implement the "good" comparison algorithms (i.e. checking against a threshold, etc) inside [==] and so, just to make patching easier. Do you think it makes any sense to change the definition of [==] given the extent to which Pd has been used already ? And then, [==] couldn't just try to be smart and pick a threshold for you. You need to explicitly tell which threshold you want it to use. Any kind of automatic threshold will end up being an annoyance, a nuisance or worse. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
> > From: Quim Llimona >To: pd-list >Sent: Friday, March 9, 2012 1:18 PM >Subject: Re: [PD] Some more float weirdness/fun > > >It's well-known that floats can't be treated the same way as integers... but >since PD is aimed at non-engineers and non-scientists I think it would be a >good idea to implement the "good" comparison algorithms (i.e. checking against >a threshold, etc) inside [==] and so, just to make patching easier. Maybe it's >already supposed to behave this way... How often do these problems happen for people? Or maybe there is a better example than [==], which let's face it isn't going to be used anyway when you're checking against a threshold value. -Jonathan > > As for the loss of integer precision issue, an object that detects "integer >overflow" (that is, when all integer digits of the number cannot be >represented) could be created, taking into account the floating point >precision (32-bit, 64-bit...) and so. > > >2012/3/9 Mathieu Bouchard > >Le 2012-03-09 à 09:39:00, Charles Henry a écrit : >> >>Martin a écrit : >>> >>> >>>For any floatX unless X is infinity the number of floats that are not >>>>exactly represented is always infinite. >>>> >>For a floatX format where X is the number of bits, every float is exact and >>there are at most pow(2,X) floats. >> >>You mean that there are an infinity of numbers that round to a finite number >>of floats. >> >> >> >>There is a countably infinite number of rational numbers and a uncountably >>infinite number of irrational numbers that cannot be represented. >>> >> >From a constructivist point of view, there's a countably infinite number of >irrationals that can be represented at all no matter how. For a certain >ontology useful to constructivism, it can be said that the uncountably many >irrationals that are inexpressible also don't exist. >> >>This leaves you with countably many rational numbers and countably many >>irrationals, that can't be represented in a finite format. >> >> >> >>We could also debate over whether infinity is exactly represented. >>>When some math operation overflows (exceeds the range of floats), the >>>result assigned is inf. >>> >> Every float represents a range of numbers. The difference with infinities is that they represent half-intervals, that is, a line bounded only on one side. >> >> >> >>That's not the definition of infinity either: Take the set of real numbers R >>and the ordering operation <, then add an additional point "infinity" such >>that for any x belonging to R, x < infinity. >>> >> You should know that there are several competing definitions of infinity for real numbers (not considering other number systems in which this definition doesn't work). >> >>There are three definitions of Real numbers (R) in common use : one without >>any infinite number, one with two infinite numbers as endpoints, and one with >>a single infinite number without a sign. There are different motivations for >>the use of each of those three sets. There's no definition that fits all >>purposes, though the one without infinite numbers at all is considered >>generally «cleaner» in the field of pure math. >> >> >> >>So, the inf in the float definition only represents "infinity" defined >>relative to the finitely countable set of numbers that can be represented as >>floats >>> >> Yes, except NaN. >> >>You'll also find out that certain definitions of infinity that applies to the >>whole set of Reals also are relative to just that set, and don't work as-is >>for all possible extensions of Reals ; for example, Complex numbers don't >>have a single coherent definition of less-than and greater-than anymore, >>because all you can do is extract features of Complex numbers and compare >>those features as Reals... thus you need more specific definitions (and there >>are more possibilities of them). >> >> >> >>not the actual infinity as represented in your head :) >>> >> How do you know what's in people's heads ? >> >> >> __ >>| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC >>___ >>Pd-list@iem.at mailing list >>UNSUBSCRIBE and account-management -> >>http://lists.puredata.info/listinfo/pd-list >> >> > >___ >Pd-list@iem.at mailing list >UNSUBSCRIBE and account-management -> >http://lists.puredata.info/listinfo/pd-list > > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
It's well-known that floats can't be treated the same way as integers... but since PD is aimed at non-engineers and non-scientists I think it would be a good idea to implement the "good" comparison algorithms (i.e. checking against a threshold, etc) inside [==] and so, just to make patching easier. Maybe it's already supposed to behave this way... As for the loss of integer precision issue, an object that detects "integer overflow" (that is, when all integer digits of the number cannot be represented) could be created, taking into account the floating point precision (32-bit, 64-bit...) and so. 2012/3/9 Mathieu Bouchard > Le 2012-03-09 à 09:39:00, Charles Henry a écrit : > >> Martin a écrit : >> >> For any floatX unless X is infinity the number of floats that are not >>> exactly represented is always infinite. >>> >> > For a floatX format where X is the number of bits, every float is exact > and there are at most pow(2,X) floats. > > You mean that there are an infinity of numbers that round to a finite > number of floats. > > > There is a countably infinite number of rational numbers and a >> uncountably infinite number of irrational numbers that cannot be >> represented. >> > > From a constructivist point of view, there's a countably infinite number > of irrationals that can be represented at all no matter how. For a certain > ontology useful to constructivism, it can be said that the uncountably many > irrationals that are inexpressible also don't exist. > > This leaves you with countably many rational numbers and countably many > irrationals, that can't be represented in a finite format. > > > We could also debate over whether infinity is exactly represented. >> When some math operation overflows (exceeds the range of floats), the >> result assigned is inf. >> > > Every float represents a range of numbers. The difference with infinities > is that they represent half-intervals, that is, a line bounded only on one > side. > > > That's not the definition of infinity either: Take the set of real >> numbers R and the ordering operation <, then add an additional point >> "infinity" such that for any x belonging to R, x < infinity. >> > > You should know that there are several competing definitions of infinity > for real numbers (not considering other number systems in which this > definition doesn't work). > > There are three definitions of Real numbers (R) in common use : one > without any infinite number, one with two infinite numbers as endpoints, > and one with a single infinite number without a sign. There are different > motivations for the use of each of those three sets. There's no definition > that fits all purposes, though the one without infinite numbers at all is > considered generally «cleaner» in the field of pure math. > > > So, the inf in the float definition only represents "infinity" defined >> relative to the finitely countable set of numbers that can be represented >> as floats >> > > Yes, except NaN. > > You'll also find out that certain definitions of infinity that applies to > the whole set of Reals also are relative to just that set, and don't work > as-is for all possible extensions of Reals ; for example, Complex numbers > don't have a single coherent definition of less-than and greater-than > anymore, because all you can do is extract features of Complex numbers and > compare those features as Reals... thus you need more specific definitions > (and there are more possibilities of them). > > > not the actual infinity as represented in your head :) >> > > How do you know what's in people's heads ? > > > __**__** > __ > | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
Le 2012-03-09 à 09:39:00, Charles Henry a écrit : Martin a écrit : For any floatX unless X is infinity the number of floats that are not exactly represented is always infinite. For a floatX format where X is the number of bits, every float is exact and there are at most pow(2,X) floats. You mean that there are an infinity of numbers that round to a finite number of floats. There is a countably infinite number of rational numbers and a uncountably infinite number of irrational numbers that cannot be represented. From a constructivist point of view, there's a countably infinite number of irrationals that can be represented at all no matter how. For a certain ontology useful to constructivism, it can be said that the uncountably many irrationals that are inexpressible also don't exist. This leaves you with countably many rational numbers and countably many irrationals, that can't be represented in a finite format. We could also debate over whether infinity is exactly represented. When some math operation overflows (exceeds the range of floats), the result assigned is inf. Every float represents a range of numbers. The difference with infinities is that they represent half-intervals, that is, a line bounded only on one side. That's not the definition of infinity either: Take the set of real numbers R and the ordering operation <, then add an additional point "infinity" such that for any x belonging to R, x < infinity. You should know that there are several competing definitions of infinity for real numbers (not considering other number systems in which this definition doesn't work). There are three definitions of Real numbers (R) in common use : one without any infinite number, one with two infinite numbers as endpoints, and one with a single infinite number without a sign. There are different motivations for the use of each of those three sets. There's no definition that fits all purposes, though the one without infinite numbers at all is considered generally «cleaner» in the field of pure math. So, the inf in the float definition only represents "infinity" defined relative to the finitely countable set of numbers that can be represented as floats Yes, except NaN. You'll also find out that certain definitions of infinity that applies to the whole set of Reals also are relative to just that set, and don't work as-is for all possible extensions of Reals ; for example, Complex numbers don't have a single coherent definition of less-than and greater-than anymore, because all you can do is extract features of Complex numbers and compare those features as Reals... thus you need more specific definitions (and there are more possibilities of them). not the actual infinity as represented in your head :) How do you know what's in people's heads ? __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
>> But 0.1 still cannot be represented exactly by float64, can it? > > > For any floatX unless X is infinity the number of floats that are not > exactly represented is always infinite. > > Martin There is a countably infinite number of rational numbers and a uncountably infinite number of irrational numbers that cannot be represented. We could also debate over whether infinity is exactly represented. When some math operation overflows (exceeds the range of floats), the result assigned is inf. That's not the definition of infinity either: Take the set of real numbers R and the ordering operation <, then add an additional point "infinity" such that for any x belonging to R, x < infinity. So, the inf in the float definition only represents "infinity" defined relative to the finitely countable set of numbers that can be represented as floats, not the actual infinity as represented in your head :) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
On 2012-03-09 02:32, Roman Haefeli wrote: On Thu, 2012-03-08 at 18:03 -0500, Mathieu Bouchard wrote: Le 2012-03-08 à 11:47:00, Jonathan Wilkes a écrit : From: Roman Haefeli That's a good example of the implications inherent in floats. What you call a work-around is actually the correct solution. When counting, make sure you count with something that can precisely represented by floats, otherwise the error will grow with each iteration. Integers up to 1.6*10^7 meet that criterion. Is this still an issue when float precision is 64-bit? in float32 you have 24 significant bits. in float64 you have 53 significant bits. This means that the limit is pushed back from 16777216 to 9007199254740992 instead. But 0.1 still cannot be represented exactly by float64, can it? For any floatX unless X is infinity the number of floats that are not exactly represented is always infinite. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
Le 2012-03-09 à 08:32:00, Roman Haefeli a écrit : But 0.1 still cannot be represented exactly by float64, can it? It can't. It also doesn't work for any other form of binary floating point. It's just that float64 is a lot closer to exact than float32 can be, and so on. 0.1 = 1/10 = 1/(2*5) in prime factors. This means both 2 and 5 need to be present as prime factors in the base of the format, to have an exact fraction for it. So, decimal floats obviously can, and the only other bases that allow it are multiples of 10. for 1/44100 = 1/(2*2*3*3*5*5*7*7), the smallest base to do it exactly is 2*3*5*7 = 210. for 1/48000 = 1/(2*2*2*2*2*2*2*3*5*5*5), the smallest base to do it exactly is 2*3*5 = 30. I'm just saying that as examples of the principle for exact fractions ; in practice, bases that aren't binary nor decimal are rarely ever used, and decimal floats are almost only used as textfile versions of binary floats (such as in the pd file format and most programming languages). __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
On Thu, 2012-03-08 at 18:03 -0500, Mathieu Bouchard wrote: > Le 2012-03-08 à 11:47:00, Jonathan Wilkes a écrit : > > >> From: Roman Haefeli > >> That's a good example of the implications inherent in floats. What you > >> call a work-around is actually the correct solution. When counting, make > >> sure you count with something that can precisely represented by floats, > >> otherwise the error will grow with each iteration. Integers up to > >> 1.6*10^7 meet that criterion. > > Is this still an issue when float precision is 64-bit? > > in float32 you have 24 significant bits. > in float64 you have 53 significant bits. > > This means that the limit is pushed back from 16777216 to 9007199254740992 > instead. But 0.1 still cannot be represented exactly by float64, can it? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
Le 2012-03-08 à 11:47:00, Jonathan Wilkes a écrit : From: Roman Haefeli That's a good example of the implications inherent in floats. What you call a work-around is actually the correct solution. When counting, make sure you count with something that can precisely represented by floats, otherwise the error will grow with each iteration. Integers up to 1.6*10^7 meet that criterion. Is this still an issue when float precision is 64-bit? in float32 you have 24 significant bits. in float64 you have 53 significant bits. This means that the limit is pushed back from 16777216 to 9007199254740992 instead. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
On 08.03.2012 20:47, Jonathan Wilkes wrote: > - Original Message - >> From: Roman Haefeli >> To: pd-list@iem.at >> Cc: >> Sent: Thursday, March 8, 2012 1:52 PM >> Subject: Re: [PD] Some more float weirdness/fun >> >> On Thu, 2012-03-08 at 16:23 +0100, Lorenzo Sutton wrote: >>> Or, beware of trying to compare floats with [==] ... >>> >>> Lorenzo. >> >> That's a good example of the implications inherent in floats. What you >> call a work-around is actually the correct solution. When counting, make >> sure you count with something that can precisely represented by floats, >> otherwise the error will grow with each iteration. Integers up to >> 1.6*10^7 meet that criterion. >> >> Roman > > Is this still an issue when float precision is 64-bit? The issue will arise later, because you have two a many bits for representing your value, but the problem still exists. As Pd is a programming language, this is good read on the issue: http://en.wikipedia.org/wiki/Floating_point#IEEE_754:_floating_point_in_modern_computers http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html or to make the wording quotable: https://twitter.com/#!/tomscott/status/174143430170120192 Best regards, Thomas -- "As long as people kept worrying that the machines were taking over, they wouldn't notice what was really happening. Which was that the programmers were taking over." (Robert Anton Wilson - The Homing Pidgeons) http://www.residuum.org/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
- Original Message - > From: Roman Haefeli > To: pd-list@iem.at > Cc: > Sent: Thursday, March 8, 2012 1:52 PM > Subject: Re: [PD] Some more float weirdness/fun > > On Thu, 2012-03-08 at 16:23 +0100, Lorenzo Sutton wrote: >> Or, beware of trying to compare floats with [==] ... >> >> Lorenzo. > > That's a good example of the implications inherent in floats. What you > call a work-around is actually the correct solution. When counting, make > sure you count with something that can precisely represented by floats, > otherwise the error will grow with each iteration. Integers up to > 1.6*10^7 meet that criterion. > > Roman Is this still an issue when float precision is 64-bit? -Jonathan > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
On Thu, 2012-03-08 at 16:23 +0100, Lorenzo Sutton wrote: > Or, beware of trying to compare floats with [==] ... > > Lorenzo. That's a good example of the implications inherent in floats. What you call a work-around is actually the correct solution. When counting, make sure you count with something that can precisely represented by floats, otherwise the error will grow with each iteration. Integers up to 1.6*10^7 meet that criterion. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Some more float weirdness/fun
never trust Pd. Am 08.03.2012 um 16:23 schrieb Lorenzo Sutton: > Or, beware of trying to compare floats with [==] ... > > Lorenzo. > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Some more float weirdness/fun
Or, beware of trying to compare floats with [==] ... Lorenzo. #N canvas 457 235 653 545 10; #X obj 47 134 + 0.1; #X obj 111 -15 bng 15 250 50 0 empty empty empty 17 7 0 10 -204786 -1 -1; #X floatatom 12 401 5 0 0 0 - - -; #X floatatom 70 374 10 0 0 0 - - -; #X text 49 402 <- this will never be 1; #X symbolatom 454 311 20 0 0 0 - - -; #X obj 312 286 makefilename %.16f; #X obj 373 100 + 1; #X obj 12 374 == 3.5; #X msg 14 51 3; #X msg 327 64 30; #X obj 14 134 f 3; #X obj 327 100 f 30; #X obj 373 136 == 35; #X floatatom 373 159 5 0 0 0 - - -; #X obj 327 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -258113 -1 -1; #X floatatom 425 137 5 0 0 0 - - -; #X obj 327 181 * 0.1; #X floatatom 327 208 5 0 0 0 - - -; #X text 346 19 reset; #X obj 312 310 print the_real_thing; #X obj 120 337 print what_you_may_think...; #X obj 12 423 sel 1; #X obj 12 448 print NEVER; #X obj 373 180 sel 1; #X text 369 -15 Also check the Pd Window; #X text 131 -14 next (click 5 times after reset); #X text 460 290 comment; #X text 427 281 the actual float beint output; #X obj 409 394 expr ($f1); #X obj 409 426 print what_expr_says; #X obj 288 426 makefilename %.16f; #X floatatom 542 425 5 0 0 0 - - -; #X symbolatom 421 453 20 0 0 0 - - -; #X obj 288 478 print but_actually_expr_is_also_seeing_this; #X obj 243 426 == 3.5; #X obj 242 452 sel 1; #X text 434 98 >> WORKAROUND <<; #X obj 242 501 print NEVER2; #X text 93 447 <- this is never \; printed...; #X text 160 499 nor this ->; #X obj 373 207 print OK_WORKAROUND---; #X connect 0 0 11 1; #X connect 1 0 11 0; #X connect 1 0 12 0; #X connect 2 0 22 0; #X connect 6 0 5 0; #X connect 6 0 20 0; #X connect 7 0 12 1; #X connect 8 0 2 0; #X connect 9 0 11 0; #X connect 10 0 12 0; #X connect 11 0 0 0; #X connect 11 0 3 0; #X connect 11 0 6 0; #X connect 11 0 8 0; #X connect 11 0 21 0; #X connect 11 0 29 0; #X connect 12 0 7 0; #X connect 12 0 13 0; #X connect 12 0 16 0; #X connect 12 0 17 0; #X connect 13 0 14 0; #X connect 14 0 24 0; #X connect 15 0 10 0; #X connect 15 0 9 0; #X connect 17 0 18 0; #X connect 22 0 23 0; #X connect 24 0 41 0; #X connect 29 0 30 0; #X connect 29 0 32 0; #X connect 29 0 31 0; #X connect 29 0 35 0; #X connect 31 0 33 0; #X connect 31 0 34 0; #X connect 35 0 36 0; #X connect 36 0 38 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
