Re: [PD] an BUG on [expr] ???
- Original Message - > From: IOhannes m zmoelnig > To: pd-list@iem.at > Cc: > Sent: Wednesday, May 30, 2012 11:51 AM > Subject: Re: [PD] an BUG on [expr] ??? > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2012-05-30 17:17, Jonghyun Kim wrote: >> >> I think it is a bug... >> > it's a feature. > > [expr~] behaves the same on max/msp and Pd, [expr if($f1%3==0,1,0)] Can someone confirm that this works in Max/MSP? -Jonathan > and therefore inherits the > best of both worlds (e.g. using integers when a number looks like an > integer) > > the biggest problem is, that Pd's text<->atom conversion will save a > token that looks like a number and can be expressed without decimals > as something that looks like an integer. e.g. [f 60.000] will be > stored as [f 60]. > this can be problematic with [expr], e.g. [expr 1000.0 / 60.0] will be > stored as [expr 1000 / 60], which will result in integer evaluation > and produce 16. > a workaround is to make the parser think that the number is really > something else (a symbol), e.g. [expr (1000.0 / 60.0)], which will > produce 16.... > > gmasdr > IOhannes > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk/GQfcACgkQkX2Xpv6ydvQtYACgyzVf+hUG6TEcHysIIyK/mDzx > E8sAoLQsti4EW/0L3gP/YFhvHzr00Rrp > =aYVv > -END PGP SIGNATURE- > > > ___ > 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] an BUG on [expr] ???
This is 'correct' behavior: expr uses "c" expression semantics in which feeding two integers to a binary operation selects the integer version of the operation. In Pd the rules are different. (and in Max, which also has an expr object, they're more like the way expr works :) Miller On Wed, May 30, 2012 at 05:17:39PM +0200, Jonghyun Kim wrote: > dear list, > > Ver: > 0.42.5-extended > 0.43.1-extended-20120510 > on MacOS X 10.6.8 > > I think it is a bug... > > 60 > | > [expr (1000 / 60 ) * $f1] > | > 960 > > It must be "1000", but it isn't... > > Am I wrong? Why I get 960?? > > Best, > Jong > ___ > 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] an BUG on [expr] ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-05-30 17:17, Jonghyun Kim wrote: > > I think it is a bug... > it's a feature. [expr~] behaves the same on max/msp and Pd, and therefore inherits the best of both worlds (e.g. using integers when a number looks like an integer) the biggest problem is, that Pd's text<->atom conversion will save a token that looks like a number and can be expressed without decimals as something that looks like an integer. e.g. [f 60.000] will be stored as [f 60]. this can be problematic with [expr], e.g. [expr 1000.0 / 60.0] will be stored as [expr 1000 / 60], which will result in integer evaluation and produce 16. a workaround is to make the parser think that the number is really something else (a symbol), e.g. [expr (1000.0 / 60.0)], which will produce 16.... gmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/GQfcACgkQkX2Xpv6ydvQtYACgyzVf+hUG6TEcHysIIyK/mDzx E8sAoLQsti4EW/0L3gP/YFhvHzr00Rrp =aYVv -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] an BUG on [expr] ???
On Wed, May 30, 2012 at 10:17 AM, Jonghyun Kim wrote: > dear list, > > Ver: > 0.42.5-extended > 0.43.1-extended-20120510 > on MacOS X 10.6.8 > > I think it is a bug... Could be... since when does Pd use integer arithmetic by default? for anything? Workaround: [expr (1000.0 / 60 ) * $f1] Try making sure that one or both of your numbers are parsed as floating point numbers and see what happens. > > 60 > | > [expr (1000 / 60 ) * $f1] > | > 960 > > It must be "1000", but it isn't... > > Am I wrong? Why I get 960?? > > Best, > Jong > > > > ___ > 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
