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.DoubleOK, 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.
