As a human... what is the value of

`z`

, after you process this pseudocode with your wetware:```
x = 17.76
y = 100
z = x * y
```

Hopefully you'd say "1776". It was not a trick question.

And that's an integer, right? Correct.

#### CFML

Now... try this CFML code:```
x = 17.76;
y = 100;
z = x*y;
writeOutput(z);
```

`1776`

So far so good.But what about this:

```
writeOutput(isValid("integer", z));
```

You might think

`"YES"`

(or `true`

if yer on Lucee), however it's `"NO"`

.And this is where young players fall into the trap. They get all annoyed with

`isValid()`

getting it wrong, etc. Which, to be fair, is a reasonable assumption with isValid(), but it's not correct in this instance. It's the young player who is mistaken.If we now do this:

```
writeOutput(z.getClass().getName());
```

We get:

`java.lang.Double`

OK, but 1776 can be a Double, sure. But CFML should still consider a Double 1776 as a valid integer, as it should be able to be treated like one. So why doesn't it? What if we circumvent CFML, and go straight to Java:

```
writeOutput(z.toString());
```

`1776.0000000000002`

Boom. Floating point arithmetic inaccuracy.

Never ever

*ever*forget, everyone... when you multiply floating point numbers with decimals... you will get "unexpected" (but you should pretty much expect it!) floating point accuracy issues. This is for the perennial reason that what's easy for us to express in decimal is actually quite hard for a computer to translate into binary accurately.

Aside: we were chatting about all this on the CFML Slack channel this morning, and one person asked "OK, so how come 17.75 x 100 works and 17.76 x 100 does not?". This is because a computer can represent 0.75 in binary exactly (2

^{-1}+ 2

^{-2}), whereas 0.76 can only be approximated, hence causing the "issue".

The problem really is that CFML should simply output

`1776.0000000000002`

when we ask it, and it should not try to be clever and hide this stuff. Because *it's significant information*. Then when the young player output the value, they'd go "oh yeah, better round that" or whatever they need to do before proceeding. CFML is

*not*helping here.

This is pretty ubiquitous in programming. Let's have a trawl through the various languages I can write the simplest of code in:

#### JavaScript

```
x = 17.76;
y = 100;
z = x * y
console.log(z);
```

>node jsVersion.js

1776.0000000000002

>

1776.0000000000002

>

JS just does what it's told. Unsurprisingly.

#### Groovy

```
x = 17.76
y = 100
z = x * y
println "x * y: " + z
println "x: " + x.getClass().getName()
println "y: " + y.getClass().getName()
println "z: " + z.getClass().getName()
println "z: " + z.toString()
```

>groovy32 groovyVersion.groovy

x * y: 1776.00

x: java.math.BigDecimal

y: java.lang.Integer

z: java.math.BigDecimal

z: 1776.00

>

x * y: 1776.00

x: java.math.BigDecimal

y: java.lang.Integer

z: java.math.BigDecimal

z: 1776.00

>

This is interesting. Whilst Groovy keeps the result as a float (specifically a BigDecimal) - which is correct - it truncates it to the total number of decimal places expressed in its factors. That's how I was taught to do it in Physics at school, so I like this. This second example makes it more clear:

```
x = 3.30
y = 7.70
z = x * y
println "x * y: " + z
println "x: " + x.getClass().getName()
println "y: " + y.getClass().getName()
println "z: " + z.getClass().getName()
println "z: " + z.toString()
```

>groovy32 more.groovy

x * y: 25.4100

x: java.math.BigDecimal

y: java.math.BigDecimal

z: java.math.BigDecimal

z: 25.4100

>

x * y: 25.4100

x: java.math.BigDecimal

y: java.math.BigDecimal

z: java.math.BigDecimal

z: 25.4100

>

In

`3.30`

and `7.70`

there are four decimal places expressed (ie: two for each factor), so Groovy maintains that accuracy. Nice!#### Java

```
import java.math.BigDecimal;
class JavaVersion {
public static void main(String[] args){
double x = 17.76;
int y = 100;
System.out.println(x*y);
BigDecimal x2 = new BigDecimal(17.76);
BigDecimal y2 = new BigDecimal(100);
System.out.println(x2.multiply(y2));
}
}
```

Here I added a different variation because I was trying to see why the Groovy code behaved the way it did, but it didn't answer my question. I suspected that perhaps it was a BigDecimal thing how it decided on the accuracy of the result, but it wasn't:

>java JavaVersion

1776.0000000000002

1776.000000000000156319401867222040891647338867187500

>

1776.0000000000002

1776.000000000000156319401867222040891647338867187500

>

This is a good demonstration of how a simply base-10 decimal fraction is actually an irrational number in binary.