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
On Wed, May 30, 2012 at 10:17 AM, Jonghyun Kim agitato816@gmail.com 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
-----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.6666...
gmasdr IOhannes
----- 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
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
-
Charles Henry -
IOhannes m zmoelnig -
Jonathan Wilkes -
Jonghyun Kim -
Miller Puckette