# Community:BadMath

### From Splunk Wiki

Splunk does math interestingly. While most programs take the paradigm of "least surprise" to heart, Splunk has a very interesting exception when it comes to math.

If one were to run the below search:

| makeresults | eval a = 3, b = 2, c = 0.5 | eval div_a_b = a / b | eval times_a_c = a * c

What would you expect the answers to be?

div_a_b should be a/b, which is 3/2, and equals 1.5.

times_a_c should be a * c, which is 3*0.5, and equals 1.5 also.

In fact, ((a*c)*b) should be ((3*0.5)*2) which most people will recognize as being "3". As will calculators.

Unfortunately, as much as that makes sense to you and me, Splunk decided long ago that significant digits will matter during otherwise normal multiplication by decimals.

Answers:

div_a_b = 3 / 2 = 1.5

That's OK.

But

times_a_c = 3 * 0.5 = 2 ????

That's not ok.

The workaround is to wrap all constructs where there could be math by decimal fractions and where you want the exact calculation to happen in ```exact()```. This would force it to use the actual math you asked it to do, instead of taking the extra step of rounding things off to most significant digits. Every other language in the world would flip this: assume you want the math to be correct and if you want it rounded you must supply some rounding or Significant Digit modifier.

Splunk refuses to correct this, presumably because there is likely a lot of SPL that displays these incorrect numbers and changing it to not round would change values in reports all across the world. While on the surface this seems reasonable, is this really the case? What would the impact be to folks if this were corrected?

Very little. At worst, folks might find reports where the numbers are actually right now. If they need wrong numbers, they can always round them themselves, just like in all other languages.

But a very LARGE number of people will now have math that makes sense.