site name hits percentage
Chris 1 17%
Kelly 1 17%
Pat 1 17%
Rene 1 17%
Whitney 1 17%
Jamie 1 17%
________________________________________
totals 6 102%
What happened in these last two reports was exactly what occurred to me when I created the report I referred to earlier. Obviously the problem has to do with rounding and I explained that limitation to the person who requested this report. That was the first possible solution to the discrepancy but the user wouldn’t buy it. What would you do under these circumstances?
From the last two reports you can see that there doesn’t seem to be a lot that can be done. The user wanted that total percentage to always be 100%, which was obtained by adding down the column. In the last report, with rounding the number became 102%, but without rounding we get 96%. What I did was to simply change that number at the bottom right so that it was never anything but 100%. I’m not sure if that was accepted or when someone challenged that perfect number I answered that they probably added wrong. I just know that this problem has to occur from time to time – as clearly illustrated by my bogus web reports – and outside of my second solution, there is not very much that can be done about it.
This scenario results because of the math of a computer, which is a bit different from the math that we are used to, unless we were weaned on calculators. If you think that this is something, prepare yourself for some more shocks. Consider the following variables and statements:
define w decimal(3)
define x decimal(3.1)
define y decimal(3.1)
define z decimal(3.1)
x = 1/3
y = 1/3
z = 1/3
w = x + y + z
The result for the variable
w
will be 0 if no rounding occurs and .9 if we define the field
w
as
decimal(3.1).
We expect that the result should be 1 from adding 1/3 + 1/3 + 1/3 – that’s what our math teacher should have taught us. Just the fact that we have defined the first three variables as
decimal(3.1)
will result in truncation since each will have a value of .3 after the first three assign statements. What happens if we change each of the four variables to
decimal(3.2)?
In this case will each of the first three variables will be .33 after the first three assign lines and now w will be .99, so we’re getting closer to 1. We will get even closer to 1 by adding more decimal digits but we will never get there unless we somehow round the results. As we have seen earlier, even that won’t give us the 1 we desire.
Our expression of 1/3 is equal to the infinite repeating decimal .333333333333…,
which I can’t show here no matter how many pages of paper I have. The 3s just keep on going, just like the Energizer bunny. On the other hand the computer will give us .3, .33, .333 or something approaching 1/3 but never exactly that. Computer math is finite but we are talking about the infinite and so there will be differences and confusion at times. You may have written code in any language and expect certain results but get something a bit different. The reason could be because of the way a computer does calculations and its limits.
Consider the following statements:
define a decimal(3.1)
define b decimal(3.2)
define c decimal(3.3)
define u decimal(3.1)
define v decimal(3.1)
define w decimal(3.2)
define x decimal(3.2)
define y decimal(3.3)
define z decimal(3.3)
u = 1/3
v = 5/8
a = u * v
w = 1/3
x = 5/8
b = w * x
y = 1/3
z = 5/8
c = y * z
The symbol used for the first two variables above and a few others represents division. Recalling that the asterisk represents multiplication, what will be the values of
a,
b
and
c?
In the calculation of the first of those variables, note that
u
will be .3 and
v
will be .6, because of truncation. Thus
a
will be .1, and .2 if rounding takes place. The more precise answer is about .208 so we are a bit off. Now using 2 decimal digits,
w
will be .33 and
x
will be .62. The result for
b
will be .20 whether we use rounding or not. It doesn’t look like that extra decimal digit made too much of a difference. Using 3 decimal digits results in
y
being .333 and
z
being .625. Now this results in the variable
c
having the value of .208. This will come about with or without rounding. As you can see, that is about the result we wanted and it is a great deal more accurate than the .1 we arrived at initially.
Suppose we had the following:
define c decimal(3.3)
define y decimal(3.3)
define z decimal(3.3)
y = 1/3
z = 3/4
c = y * z
and if we didn’t skip the class on multiplying fractions, we expect a result of exactly .250
for the last calculation. To start with we will have .333
for
y
and .750 for
z.
The value of
c
results in the value of .249 if no rounding occurs and .250 if it does. You can see that using more decimal digits gets us closer to the result we expect from normal math.
As we have seen, we may have differences even if we round results and in some cases that may even be the reason for the unexpected. Not rounding may still create a problem as we have seen in our sample reports but the important thing to realize is why there is a difference. Your job is to explain that discrepancy as well as minimize the damage. That simply means that you may have to allow more decimal digits than you originally had. This is probably more of a warning than anything else. You will need to realize than sometimes no matter what you do, there is nothing further to be done.