[PD] an BUG on [expr] ???

[IOhannes m zmoelnig]

-----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
-----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-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2307 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120530/75cd7006/attachment.bin>