----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at 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.6666...
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