the Sweet Smell of Burning Fur (plonq) wrote,
the Sweet Smell of Burning Fur

  • Location:
  • Mood:

We will just misrepresent the data in a plausible way

I have run into a puzzling issue with a report that I recently migrated to one of our newer systems. While most of the problems in migrations of this kind tend to be with the source data (somebody accidentally drops a table during the move), the problem this time is slightly more rounded.

Rather, the problem is with rounding.

In my mind, the main cause of the problem is that our executives don't like to see decimal places. Too messy. Ain't nobody got time for that. Don't sweat the small stuff. Give us nice, woody, whole numbers to deal with. Of course, in the world of data and applications, the fractions are an important part of the equation.

The result is that our old system reported that 20 - 44 = -24. Our new system reports it as -25. The thing is, the new system is actually correct, but hey - that's what you get for ignoring the decimal places. It's just that when one of our pointy-hairs higher up in the company see something like 20 - 44 = -25, they scratch their pointy-haired heads, scrunch up their little faces in confusion, then start heating up the cauldrons of tar.

I inherited the equations in this job, and I have tried a number of approaches, but no matter how much I play with CEILING(), FLOOR(), TRUNCATE(), ROUND(), FUDGE() or the like, it seems to insist on doing the maths before it does the rounding.

I will give you some more specific numbers from the report itself.

This year's bullshit metric is 19.73%, which the report rounds to 20%
Last year's bullshiit metric is 44.44%, which the report rounds to 44%

In the old system, it seems to do the rounding first, so when we show the difference between this year's bullshit and last year's bullshit, we see that we are 20% - 44% = -24% off from last year's bullshit.


In the new system, it does the calculation before it does the rounding, so even though it properly displays 20% and 44% respectively, regardless of my petitions for it to do otherwise, it calculates 19.73% - 44.44% = -24.71%. Guess what it rounds that to.

If I could just apply a blanket CEILING to negative values, and FLOOR to positive values then I could resolves this issue in an afternoon, but there are very specific failings that need to pile up properly for this to arise. Ultimately I need to employ some kind of Jedi mind trick to convince this software that it needs to forget that the decimal places exist after it rounds the numbers in its terms. I wonder if it has a program setting for "make it logical, not right".
Tags: maths
  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.