# if to expr…wtf?

Can someone kindly tell me why the combined expression in the included patch is not a valid substitute for the split expression that utilizes [if]? Logically, how do they differ?

Specifically, why is the "else" element of [if $f1<0.5 then $f1 else out2 $f1] not equivalent to ($f1>=0.5) ?

I suspect the nan error is related to the sqrt but it doesn’t make sense why the same error doesn’t occur with the variation using [if].

**all**of the following text. Then, in Max, select

*New From Clipboard*.

```
----------begin_max5_patcher----------
711.3oc2V1saZCCEG+5vSgUzt.XgnXmDfLsMzdNZqpBIFvcINY1lV1p569rc
9fDJDXcP0X2D3Xe7w+8O6yw94dFlyy1f4lfOAtAXX7bOCCcSpFLJsMLSC2Dk
Dx0tYlh47vkXSqh9xCEQqHzk2yvQhh3D.scr.HWnsuEvSa.mZ6.tqbHjXcfx
l+vHe2p3rHiJngoXcWeiQBSp5IasHAKD+LGWDdSy5HQWmRnxN0JC0HRbxuzd
CQxYu12hHocFpZ7kd8TerNwUdTVZJlJpzk.uQufMmMaV8pfsbtpMm5ocO7AF
3ZijnA4GnXiaAtbN.gfGmPsv.7OACNuALPwOIE1qn.dSNCz+CKfe1w1evP4m
g8g1i3+fIT+5YOLO6IU+2dqEZvfAeT8+u9ksNq8bT+9H6gxdFLx0dvvsVPa4
Pje53bGzywdhjqvI9Jh5ilnN.dHv5M47czCdoO5ktNQP3IjXLqK.3FnA.BMU
mz4o+A42..brPpaYrKFgi1u8CH3zsSEShGAlcOlFNOQu7bNHhrZhoLFQlxDJ
HYzliJRBp3PQXS3sWh1FcUo3hUjnuSw7Vtlyv7p4pAT7mLt.Ji04YNke.2cw
1Fbgk42mksAWzUx1vk6XcYdcwF3eKNg++hytpLedJw5IuHWcztdSny6tjdcE
Ui8nzqqay553afWKl4LsalEb8yLxBP4CA.hUXpx.fS3Xfb5PJqSAWPOMm7b6
DW9NuEbYcdPFpAxzgyLgP284z50np81bjmslEUInpGj.1tHiwbAgVWi4lsOX
F.qcZEINF2pFTLgqJlEe3W2cp5QUo7n5YGQeI0yIwG0iVdmzit51QEj5562M
AE7OlfTImGeKaGYe4UD7nJ586TzIkksKHOcAUTUJLO+QLiWFTsVj0weHioLG
aoMIzBScAPSF9QRk+t5VBYxJ0BYY50rhRralN1rmZddo2uAIUjqj
-----------end_max5_patcher-----------
```

The result of ($f1>=0.5) is 0 or 1. $f1 can be any value.

The result of ($f1>=0.5) is 0 or 1. $f1 can be any value.

That’s the whole point of using a relational function in the expression.

If ($f1=0.5) is true, then ($f1>=0.5) is false and vice versa.. so the expression reduces to one of two possibilities: [0*x + 1*y] or [1*x + 0*y]. Hence, it should output either x or y for any input [0..1].

**all**of the following text. Then, in Max, select

*New From Clipboard*.

```
----------begin_max5_patcher----------
510.3oc2UtsaiBCDF9Z3o.Y0KfTpEP.RS0tqz9bztpxAlz3VhMx1zxtU8ce8
AnIsa1lnd5hdQHYN3w+9KyXt22Csf2CRTvYAmG34cuumm0kwg2fsGZMoupgH
sogV20nnxFZMHPwt3sDU0JJ6pKEPkxUqx43j3fxBbQbP5rbiQVJNI3WCKQBp
0TltvtzSLIrcbZscy3Kt9jhjM6ifrFTf3RfQVz.lTRFhw6TMfR86VvUQDJV+
4w5wETfoHJJms8pp3LUMQQL9RG7w5zJSWK4yb51Aq2rAupUzpaXfiLoFeO36
adD+A.yrDGkdazLe1WWZtrgqq7dAYpqsb1LGU+ObpbrNK0mJllT1P+TPIMuJ
BpEGQYv3BB6pMnbm7wrkR5erKMMCmrar8wQn4yO..U7UDPL3N8gaT+Jn2xED
z2JBBCOZY52RvEQSxwSZ42Yru3h3oQQGa94O9tMVn9oMZXXFdh1ezIY3HadG
mhi1e64zByWSOc9Kh+78i++cJ9cfpaOXZKGpgxd9qPrGNi+mhZIuSTMJlwor
fMmuZPpnrGuW47MWYsURqn00vSt2olJMcWV3jry+zOX8TbH5I+ySO4GhdJ+z
zi4cw6WOEuR83ZmHss2BB4PMsRQOidMWXLKislTlyz14hDvszw7mZ8PD5YKk
dvpS3lK5OsD4a1mG7+qA9TQ0
-----------end_max5_patcher-----------
```

hold

The "else" statement of [if $f1==0.5 then $f1 else out2 $f1] is ($f1!=0.5).

If $f1 = 15 then ($f1==0.5) = 0 and ($f1!=0.5) = 1.

Look at it this way

`"Specifically, why is the "else" element of [if $f1<0.5 then $f1 else out2 $f1] not equivalent to ($f1>=0.5) ?"`

`"Specifically, why is the "else" element of[ if 15.<0.5 then 15. else out2 15.] not equivalent to (15.>=0.5) = 1?"`

I think you are right, the issue is the ‘nan’ mixed with floats.

<code>

**all**of the following text. Then, in Max, select

*New From Clipboard*.

```
----------begin_max5_patcher----------
1237.3oc6ZssjZiCD8Y3qvkq7.CC3xstXIu09x9cjrUJOfXvYACqsIgcSk+8
UWr4RlXilYsEPp7xLkExtac3bNpUa95vA9OsYunv2627du2fAec3fA5gTCLn
55A9qS1OaURgdZ9KVsIa2Z+IlOZwlrxhz+Un9H.EDVMrbFoYqDk5aApFbatn
PjUlTltI6i4hYklvxQn.5DOBiq9Wn7Yn9i2eVcWa1UJePk+yVgY5pDHozehm
+SIYO6eXdxPZlpNln5XlTNaYZ1yMFOpNfnSiX5b8BcySeZJJ9zEZVxZcR3+G
4oIq7ODhb43kh7OJxRdZkdFgpO5aCGp9yDKA1LwWjgr9oVJ1qyWew9s4duaA
7H7Vv7WfdMAXPy.FiqALbLWAUQ7VALdK.1a.Td6rsNm2vnD64ML2wat8fHjg
ibAHhdaHsfwE+cd4HoB6gql.y.aXJSAXw3VgMb2JvVKJJRdV7BrQFdDCcvyY
UZlX1lcYkmx.rAmPsa9CwFyX.Ym4+a.cADDvzwfZBkJHXnA3EbC7BA9cGHhw
jpUXTE.18nHJx39cJHB7F.wvep3nHoVTAuXDs2fWfVGCs5ucRJD2s3aC1ioK
T0c76gAdkKEYxkrmXUgv60QcuPweHVb.Rst48H1xvZ6UtFZALpM+UHxUb2Nz
.fQ3ZTjPv8lMZTXULP7K6..j6OFZW.RTfYnywfMbM70Dkji0gBYfPMFXQ39a
OHy1bGDxwsBtHm.tlZHClRBFucyWTkQ9gOLAc0JkTV4sBhPwDMDgZsVR.tC8
5hjULp8gXrdyqiHIwLq85BuCUwcAJgipj70lcspGicCWaptnPJm12UEFI2qU
yCC6u8bogf8UExcme2noiFgBFqNy7TbvCiOdED7vCWa9Xs4Gi0FejcG58Qih
qpyq+79vDi2GECG4bM48QcGm6cKPiGEFPGO5P+Zd70x1P8.aiv0GLFns1WTh
KAJ3QIXcsvETXnt+nTcuHXs2sXWoAI.idryY+u2Rnapw3kxrlr1oX2pyzxLY
QsGTZWMUVU8r0hLRqV5jt1Se2pxzhUoyE49utMulb5hclLYlmTlb5sXcK0ij
EWor7iL5IfXDTzFpEk2Zqyq+BeY5r+JSTb9hHOsdGmSmagnTthkvhIcza4nY
o263ImaAdhQ+BOaGOAvnPAhMvIbKCms4JdrviVK8UUQxU6n+xyeo+lHDLeG.
sd1ehCOuvY6m7xlkb8Nxf50YbJlExaGybbi2oly5KuvbXe4hB0cm3eRyPF5x
PVjYqXR6cXhZYyQz2rtvru6GihNCTieNLVrYW9r5UR8O7.ui4vbQQYZ1A6h2
e7mywISZY574hyrSlmVnbil27KZ157AaS9vcW9PsIev2X3CyY4ipcwWNejJO
OvM4SjM4Sn6xGvh7Q8hIukvG0ABtovmHmwmILKxG04JcD9XU9ftsj6DGZ+Xi
cn5sp5J5rM4i6RGaHOf617hXi1xcRKKUVtIahsj3DdCYK6NeGrU4C3r7wFgk
6JZ1FtCDdS45vcV1XE0wc6XYyFn.+FSXoNNpqbdnmSTaZKctiynKWjg6z6ee
r9wYD1gkER38YBY5xQx1seVjWT8L04h+5jOsIWcYzD8koYlK0cuwOW74z54S
0ijjOaYZoXV4tbSGU1yi7Gphy2F9e3S7zC.
-----------end_max5_patcher-----------
```

</code>

G

PS the difference, I guess, is that in one case the if is within the expression and thus the ‘nan’ is messing up the computation as it is always calculated (the sum of the two and in one there is ‘nan’).

in the other case the if is outside the computation and the program checks for what is true and based on that compute a value.

`"Specifically, why is the "else" element of[ if 15.<0.5 then 15. else out2 15.] not equivalent to (15.>=0.5) = 1?"`

`(15<0.5)`

is false. `(15>=0.5)`

is true. So the value of 15 gets passed out the second outlet instead of the first. Perfectly logical.

By the same token, `[(15<0.5)*x + (15>=0.5)*y]`

is equivalent to [0*x + 1*y] = y

Again, no logical inconsistency.

The if outputs 15. The expr outputs 1.

OK… answering my own question – at least in terms of getting the expression to work. I’m still not sure why the same expression doesn’t fail when split by the if object. Somehow, a negative value is generated within expr as it is evaluating the two conditions.

**all**of the following text. Then, in Max, select

*New From Clipboard*.

```
----------begin_max5_patcher----------
807.3oc4X1saZCCE.95vSQTzt.XgnXmXHYZaU64nspJj3VbWvgYaZYqp2tWf
8FtmjY67CAJDxXTFrgDVbbN19b974Gfm5XXMNaAlaY9NyKMMLdpiggdJ0DFE
xFVSiVDmFw0pYEmMcJlJrryel.uPnm+me+GkycK6twp4bcbKlYVjHdBgd2ML
brH+zPCQNPjsILLTplIPOBkKw75hEQRzab136G3Ws0YTAMZJV+jOwHQokOgN
eJglhEZqDTScN4aZ0AvJyQpa1bQoxUFICykdVjfjQWwPAZC0yU4OlkClWqV0
yc5nFrOxvyyys8vC9pBu8fBSmmJH7TRBlYsceDLJvYjh6Hj1G8CzNIplSxwB
ocK267UnuZ.aFBfkmDSh.AlcClFMNEWOBH2uDecFNeCsrrkuq1tLFoL9n9ph
kbJIRDUmcaDnqRNXYPvDR7moX9JptkXQvnv5L4OJVjheTBlWDJhWLiY18M2B
duqCpWe4P+t.mA7uvDciFyUe12o+rrGU5b0U1vdxWuUI7wOrbEUpOnaWnSe4
S6MvyoW+kR.G05jisIDHO.GEBbPaON2a2w4u7BtZi1+T.v9jBHuuitC+B5Si
nMvCo+qRA7zXvWK.B1LLPGPZ.esow1JKdwEW7aUVDD5kWVDoiW7.MUVDAN0p
KtGYjaJabyIiMlHtq7PeWcdHXjtrCBNpo7P+QmSIhsqWjWdcWHL3PzKJ3LoY
zqFO8.EIpGDd5A+emmkInCAGBbB92EmMUh8vTqzW1QVEZWcIzXSHoVmQEK2I
8ZpsTSgug9qvL2flYV34OyH2ZVzQ2TLASUBl3TN1TdbPkTavEvWyIeuFwExc
evk8gAYvZHSucVoD55+iCZeTM+pbjmMmEWZPEeCeyk9XBlKHzpRLWV8C8poy
DRRBdkJPIDtpTVx1+RZs1Z.svb7NsLGcvvQxfxOKvtrHUEvipEsSFopubrrn
0NqsDDAOhFTvokAo90D69JK3zJMaMi9uNeT+a.0xDau8jWxNZ1rGvLdwdpME
YSt6yXJwg1ZQBMWT2cvhgefTpumdlHlrMlP1CaNKu+yhfgVcTmyyc9Ui0cBN
-----------end_max5_patcher-----------
```

as I said above I think the issue is an expression with a non number as one of the element to be calculated.

By adding the ‘abs’ you are getting rid of the ‘nan’ from the negative value inside of ‘sqrt’

that’s all…

see my example above and the expression adding nan to real, the result is surprise surprise nan.

G

PS to be sure it is clear:

<code>

**all**of the following text. Then, in Max, select

*New From Clipboard*.

```
----------begin_max5_patcher----------
437.3ocyT0saBBCF8Z3ofzrK1OLi.h.6t8brrXJRUqAKr1hiMiu6q8qvltEb
DxhyaJoe8zdN8v4q6rsPoE0DAx4Ammbrr1YaYAkzErZlag1fqmmiE.Lzh7BV
0FjqYoEELof9NQujm+nwMkUHnrbhD1hWSwRNQPXRrjVvlwIykFZi88GE55LI
JV+Yr5LzCNO2rqhJo5fjuURLv0B.KQtNnTLaI5SbJJMPAN8a4DKmuhxV1Ieg
.g9GxHMCtnEoqu2O4vKJCuADA5QNEmi9jBtptjvmQX3zb.wX8R6ss0Ct8zXY
jWUT1dpRRMnWDotj6b0Bu67Fhm+C2qKCyqaCKJFLrfjXsUMM9jFV7ILrAXJC
Os8mmahBmz+bSz4K2b4YQ9lLxuXQgWFsVd2JdgKuV0gcy+VClw1BBizFVRvI
ssf90fA6EkSYe+0cfec8i8KQQEed6cnsS14KIjQDRJCd69PPIGAZEMKi.q25
YYTg9GWV2+45sdB5idhOe5IrO5I3ByehFndLwIbY4VBWzblfTTMZqK35oScg
oTlYJj2QbxVZK9PnBlqh+RU1uhaht0wSUAWEO6s+.bNa9WH
-----------end_max5_patcher-----------
```

</code>

The if outputs 15. The expr outputs 1.

No… using your example, the expr outputs 1 * 15.

Follow me here… `[if $f1<0.5 then $f1 else out2 $f1]`

( with out1 feeding to x and out2 to feeding to y) you can use `[expr ($f1<0.5)*$f1*x + ($f1>=0.5)*$f1*y]`

. iow, the if object outputs the input to one of two outputs, which is then processed by an expression. The expr object multiplies 1 or 0 by the input ** an expression*. It’s the same logic in a single object.

By adding the ‘abs’ you are getting rid of the ‘nan’ from the negative value inside of ‘sqrt’ that’s all…

Well, yeah.. that’s why I used it. I admit it came in a "duh" moment.

But my original confusion still hasn’t been addressed… Why does the same sqrt expression fail when the logic is evaluated internally by the expression object yet work when the logical is handled by the if object?

because inside the expr object there is no type check?

just had a quick look, can it be that you need to put another bracket around everything behind the boolean?

[expr ($f1>0.5)*((0.5)*...) + ... ]

Nope.. that was the first thing I checked. But I agree the 0.5 does look kinda naked.

There is something internal happening in [expr].. somehow signed values are being created in the process of evaluating the logic.. even if for only a flash moment.. and then whammo… NAN.

because inside the expr object there is no type check?

I thought that was defined by the operators… > is boolean… sqrt is not, etc.

as you can see i deleted my first response before you copied it.

now lets see if my second version is better. :)

"Why does the same sqrt expression fail when the logic is evaluated internally by the expression object yet work when the logical is handled by the if object?"

Because in the combined expr equation one side is always nan. The if removes the nan.

<code>

**all**of the following text. Then, in Max, select

*New From Clipboard*.

```
----------begin_max5_patcher----------
720.3oc6W10aaCBEF9ZmeEVncQbVhkA+Yl1M62Q6TEIlzPmCNCSZyVU+uO9v
NeTkZSqxrV6xMXA9.7xiO7djebfCXV4VREv8KtW45373.GG8PpAbp66.Vg2N
u.WoCCrnnjsYEXr4Uqwh4KoraugSlKLKCJJ0GEO1MNJyOP9HP0hjsteudRzb
8JUN6tIvv8qDGuhHH7aHL7rBhJjf52snjIXx2pm123TbQyrjRgxJHBs1f0CV
tQHGR7q0DihTZFK.icAyvraA6zgbxlP0yFcvlUQ+sdtPjefZzmFLP0L1RFwH
OHObMZTP1pQCXjKz2FvE.UHKD4G2B3ffWGbPsCmW.JvyGT5LwAFC0m+HTb2I
NweDya5DQgoo0HJpaDk7QDQq1THnUEzbBuQnUDgToxnLRRyD3AHQrjN+GLR0
QGjSk+EknwYJRuBF6KUt3ofapMvct77liE3iHHmRXBrfVxNLT6nsBzuHjOeF
Ujsq4RNFOZX0O4hgSFND4O5SKfdSB88FsuGz2y6yxlVyX0eOByBMzD1VFaF3
LkU1C1YchNn+DM8jOi7Gst7ggRlc80iQddsAr5rvFfEj0Fvl9NBXc6+We+CZ
g2Vz+o1+HCgB6lPnKt+uR2+.+TYo0DnEt+gvK1+1Y+mDooJrNysc+eI0uTAX
WlXCyZuD.LZ56elQW3JQyWkTyUrjvTcbIEUDWoJPpd1fqPCmhBaEWwAmMb01
swtQldlfBJ64++s9LpF+XNVUtgOuYuaLgb2eHyIUBJamyxUGbdOHpkz7bxQV
O4zJkwkFQm9SpsBxrWvtTj5RdupnNYj5JTeonmsWmVQQ8ndxrPOndSO1nljd
SM17sJt2TSpEpY5+Tpo+tomXy8b3Q1S+MkSrsxomtkaUohv2ndLUxvqWeOgW
UulZoHq8eWIW0MYrtKkY5pqoB3j6oMwaB.ykU2ExR6a3lxxayR.CT6ySC9SG
dhCg
-----------end_max5_patcher-----------
```

</code>

Rick, you’re right! I don’t know how I missed that. For some reason I was thinking that a false evaluation would equal 0… while somehow overlooking 0 * x. In most cases, multiplying by zero generates a zero.. which is enough to get the job done. But this time, I was one who was goosed. Thanks for the exchange.

0*NaN => NaN. Always.

The other thing that trips people up is evaluating (x == x) when x=NaN.

0*NaN => NaN. Always.

It’s as though 0 and 1 are the Trumps in the deck of numbers… but NaN is the Joker.

Don’t forget to watch out for infinity.

What do you expect to get from `0*Inf`

?

What do you expect to get from 0*Inf?

Well it looks like NaN reigns supreme.. but maybe there is a way to cheat? :)

**all**of the following text. Then, in Max, select

*New From Clipboard*.

```
----------begin_max5_patcher----------
716.3ocyWssaZCCF95jmBKqcwZEEEGmDH8t8brVMY.C0cA6HGSKsU8ce9PxV
ZGDBUVgf.r7gX+8+ku+C9sv.3BwdZEDbK3mfff2BCBrCYFHnte.bKY+xBRkc
YPN8YwhGgSbSon6U1gKkLtBH1oZlguaqtWAUYern5QWK3pJ1qTyXn3oMCWRT
Kefw27KIcoxgl34Y5oAInYllTam3noQf6qeF1J6AqAyMHLr09yIas6O7GRFo
nEdX7F3fLi8dXn4uI9vvuNxW1MJOpscm1ocGe4r6WK.ajhck.7gs73y1xmal
EfmkXZlg6zvQmog2fFG.UuTRcmIDNQ+Cbuu0C2dkuzCNVoQNf5hUxubpg0Rw
1pW1tPTbX6Fc99ANoOFO+zxgry0vOpZvmJAEHZp2XCz7oo+kMvcJCR8EartP
PTiVJoNbQeXjjwKivTToeYj3jYt3ncwH3QoGSEs.v3qAbB+vbB9qpRhrpj73
t3jyMYJ9XbxBBeiIuRSqecgD9MNasnYVOByhFkhlmn6KkfusFcsGC25JBCka
yAMOpSWo3QIs3y.K0zgqhbW.2ixFW3HKaoUUjMz+iNtAMMUm7Ana7Lqjla8b
rtQ5rzGlUR7V8p9TiX8bJEO+cs2yc2ogej9yzq7sWDxpXP3NCtfSGktQkjea
jM1u9lWRw8H5xLekU5izh8rfEL9mu8uEulw+HWUI1IW1rUM.C7OHuhVoXbhh
I3sVj4h4sVzCrUqn712CZEqhrnfZs2nC9Vq23ItO3Idvvi4JpmDO4CFbLFd7
IPS1fhFzIPS5fglz9nbPCJ4bJ3jLXnIYbQNYiK3zGm7gKlCtOjy3Jh7.lfnO
IrvC3Kq9D1wBZzHCOCD+zmHO3AT+zGuKb5HT+D+Eviq9PRY4STYU8dZghtp4
GERS2rI1tLtqqsNXnj9DqY81RQgDot9Wkt32cRWsq6mmACMmy6g+ADYRBXF
-----------end_max5_patcher-----------
```

Yes, in fact you really *need* to do something like this if your calculations can produce an Inf or NaN and you don’t want your patch to trip up because of it.

There is a convenience object for this in the MSP domain: [bitsafe~] ("Replace NaN and infinite signal values with 0").

My favorite way to filter out NaN in Max (not MSP) is [if $f1==$f1 then $f1 else 0.]. The IEEE spec for floating point explicitly states that the expression (NaN == NaN) must evaluate to false (which makes sense, if you think about it).

Ahh, that’s very helpful. Thank you.

Of course, now I’m confused by all this inf business.. and `[if $f1==$f1 then $f1 else 0.]`

doesn’t address the problem of inf.

Even if something like `if ($f1==$f1&&$f1<=2147483647) then $f1 else 0]`

was adequate to filter inf output, I still don’t understand why the max window will handle up to 2^1023 and flonum will handle up to 2^127.. and I would’t want to filter those larger values unnecessarily. Yet Max is only 32-bit and I always seem limited to 6 decimal places of precision. Seems inconsistent.

Anyway, I don’t mean to take advantage of your time. It’s too bad I can’t buy a round of beers to motivate you to stick around. :)

No, my little code example only addresses NaN. In C one could write an ISINF macro as follows:

`#define ISNAN(x) ((x) != (x))`

#define ISINF(x) (!ISNAN(x) && ISNAN(x-x))

Except nowadays I’d write them as inline functions (to avoid the standard unwanted macro side effects). And except if I were writing in a compiled code environment it would arguably be better to use compiler-supplied test functions. But hopefully you get the idea.

Yet Max is only 32-bit and I always seem limited to 6 decimal places of precision.

Max 6.1 is only 32-bit if you tell it to be so. It is 64-bit if you allow it to be so.

The "six decimal places of precision" is, largely, a display issue only. When posting to the Max window, [print] seems to call the standard C function sprintf() with a default "%f" parameter, which rounds the output to six decimal digits. Some other objects display other degrees of precision (capture~, for instance, normally displays three digits after the decimal point, and so on). But floats are always passed between objects with full 32-bit precision (and most objects use 64-bit precision internally).

The 2,147,483,647 you cite is the highest value for a 32-bit signed *integer*. Floats and integers are different animals and have different min/max values (comparing a float to the maximum integer value is of somewhat limited value, btw). 2^127 is the largest exponent a 32-bit float can have (the largest possible value is greater than that, since the mantissa can be as large as just-less-than-two). 2^1023 is the highest exponent for 64-bit floats.

You might want to spend some quality time with http://en.wikipedia.org/wiki/IEEE_floating_point if you want this to all really make sense.

Finally, one reason the sprintf() function has a default precision of six significant decimal places for floats is because the most common size for floats when the C Standard Libraries were first being developed was 32 bits, and 32-bit floats have 24-bit mantissas, which gives approximately six decimal places of precision. Not much point in the default display precision being higher than that.

Enlightening. It’s still a bit ambiguous to me if the "full 32-bit precision" that is passed between objects entails 24-bit mantissas/6 decimal places – which would mean that 6 decimal places is more than just a display issue. I’ll check out the IEEE info and see if I can’t clear that up myself… :) Thanks for all the insight.