What happens if you use .toDouble() instead of .toFloat, a= nd an explicitly double 100.0 literal?=C2=A0 Right now, your computation is= taking an integer, dividing by a float, then multiplying by another float.= =C2=A0 I suspect that going double precision won't fix this in all case= s (floating point math is, after all, just an approximation), but at least = you're processing the values as precisely as you can.

On Sun, Mar 19, 2017 at 8:2= 8 AM, Derek Visch wrote:
Looks like floating point to m= e, what are you expecting?

On Mar 19, 2017 10:0= 4 AM, "Tx. T" <txt8888@yahoo.com> wrote:
```Any=
idea why the follow code "calc" returns the "70%" of t=
he 330000 incorrectly?```
```testing on: Groovy Version: 2.=
4.9 JVM: 1.8.0_112 Vendor: Oracle Corporation OS: Mac OS X```
`Mac OS X 10.12.3`

```groovy:000>     def calc =3D { amount, ttl ->
groovy:001>         double rtn
groovy:002>         if (amount[-1] !=3D '%') rtn =3D amount.toDo=
uble()
groovy:003>         else rtn =3D ttl / 100.0 * amount.replaceAll(/%\Z/, =
'').toFloat()
groovy:004>=20
groovy:004>         rtn
groovy:005>     }
=3D=3D=3D> groovysh_evaluate\$_run_closure1@39fcbef6
groovy:000> calc(&qu=
ot;70%", 330000)
=3D=3D=3D> 230999.99999999997
groovy:000> calc("10%", 330000)
=3D=3D=3D> 33000.0
groovy:000> calc("20%", 330000)
=3D=3D=3D> 66000.0
groovy:000> calc("30%", 330000)
=3D=3D=3D> 99000.0
groovy:000> calc("40%", 330000)
=3D=3D=3D> 132000.0
groovy:000> calc("50%", 330000)
=3D=3D=3D> 165000.0
groovy:000> calc("60%", 330000)
=3D=3D=3D> 198000.0
groovy:000> calc(&q=
uot;70%", 330000)
=3D=3D=3D> 230999.99999999997
groovy:000> calc("80%", 330000)
=3D=3D=3D> 264000.0
groovy:000> calc("90%", 330000)
=3D=3D=3D> 297000.0
groovy:000> calc("100%", 330000)
=3D=3D=3D> 330000.0```

--001a113eeb18703468054b175277--