0
$\begingroup$

These are actual reported costs (60) for a series of projects for two years, say USD (though actually not) totalling $57,975,403.24:

(274,680.90)    3,900.13    103,999.61  512,918.71  1,079,734.06 
(97,570.45)     4,218.45    110,499.74  516,501.94  1,249,999.48 
(43,261.81)     9,951.36    116,287.74  531,650.58  1,398,872.64 
(41,314.45)     14,191.48   124,999.48  551,420.65  1,999,996.52 
(34,843.48)     34,999.09   145,808.39  574,996.39  2,249,270.19 
(1,305.16)      35,218.84   215,999.87  605,869.55  3,255,268.13 
(634.19)        42,007.48   227,045.03  715,369.04  3,758,841.42 
0.00            47,045.03   262,369.29  749,881.94  3,897,417.42 
60,000.00       54,999.09   347,790.19  794,996.65  3,925,001.81 
960,000.00      74,175.23   359,948.78  800,321.94  4,266,898.32 
39,999.74   *   77,998.97   359,998.06  824,731.87  7,494,344.91 
59,999.48   *               404,998.07  849,997.80  10,646,324.13 
                                        919,938.97 

Some negatives, the occasional zero and a high incidence of round thousands is to be expected. The two values asterisked are probably a single project. The values are all plausibly accurate but I would like to know whether I have grounds for suspecting the values have been manipulated as they seem to end just short of a round thousand far more often than I would expect:

Distribution chart!

In particular, 15 of the 60 are less than USD 4 short of the next round thousand. Excluding 7 negatives, 1 zero and 2 round thousands, 50 values spread across ten centuries averages out at about 5 per band. A very slight propensity to fall just short of a round number is to be expected – either as a result of something like a currency conversion approximation or the rare purchase of a low value consumer item (such as a book or shoes that mostly seem to be priced $x.99) but there may also be a slight propensity to just exceed a band.

  1. In this context, is the fact that the top band contains 20 examples at all significant?
  2. And if not is there a sample size at which such an anomaly would be statistically significant (say 95%)?
  3. Is there something like Benford’s Law that applies to trailing rather than leading digits?

Update:

I now have most of the values that aggregated as above. Of the 20 values that seemed odd to me, I do not have details for 4 but the sums of the components for 9 of the 20 are round thousands. In effect, based on actual underlying values, 9 of the 20 in the range 900>999.99 should be moved to the range Roundk and hence change the chart appearance to something I would deem plausible.

I have also investigated the distribution of the last integer in the details that were represented by the remaining 7 in the range 900>999.99 which excluding zero (as likely to be favoured), is:

CV51022 example

There were 973 data points of which 157 were ‘0’ and, though not quite horizontal, a linear trend line shows only relatively minor departure from a simple average of just under 91 instances per final integer.

So, my conclusion is that the reporting of aggregate values (which takes place at intervals) may for one or more reporting periods have been rounded*. This I think confirms that the results were not as should have been expected but, in this case, provides a wholly innocuous explanation.

Therefore I’d suggest A1: Yes, A2: n/a, A3: No – other than random might be expected (uniform distribution).

*Current Total reported as Previous total + Current Period change, rather than as Current Cumulative Total.

$\endgroup$
2
  • 5
    $\begingroup$ Projects usually have budgets that are rounded, so it is no surprise to see many coming in just at or right under round numbers. There's much more to identifying unusual values than mere inspection of the numbers--you need to understand what you're looking at. Without knowing more about these projects, how they were budgeted, managed, paid for, and selected for this analysis, I doubt anyone could credibly answer your main questions. $\endgroup$
    – whuber
    Feb 28 '13 at 6:55
  • 1
    $\begingroup$ Re Benford's Law: You cannot expect it to hold, even approximately, for such a small dataset. It does generalize to the second, third, ..., digits, provided the dataset is appropriately large. By the time you get to the final digit it says the distribution should be essentially uniform. Even then you have to be careful; if you're studying prices at drug stores, for instance, expect 9 to be extremely frequent! If each of your reported costs is the sum of a large number of separate costs which could have arbitrary final digits, the final digit should still be uniformly distributed. $\endgroup$
    – whuber
    Feb 28 '13 at 16:02
0
$\begingroup$

I tried simulating something slightly different:

  1. Assume sellers price items uniformly in the right below hundred mark; i.e. 91-99
  2. Assume integer prices
  3. Every project has 100 items and project value is a sum of all those 100 items.

The distribution of the last two digits seems non-uniform with a peak right below the 100 mark.

Distribution of 10's

arr<-c();for(i in 1:1000) {arr<-cbind(arr, (sum(sample(seq(91,99),100,replace=TRUE)))%%1000)%%100}; hist(arr)

Maybe I'm doing something silly.....

$\endgroup$
6
  • $\begingroup$ It does seem like you're making some mistake, because you definitely should not get this distribution given your stated assumptions. Unfortunately R does not even recognize your posted code as being syntactically correct: you initialize arr as an empty array and then try to use it as a function arr(..) within the loop. $\endgroup$
    – whuber
    Mar 1 '13 at 17:11
  • $\begingroup$ @whuber Sorry about that. It is only a typo. Missed a comma inside the cbind. Though that's syntax. I can still be doing a semantic / methodological error and I probably am! But I'd love to see where...Anyone care to do a replication? $\endgroup$ Mar 1 '13 at 17:21
  • 1
    $\begingroup$ Thanks, I see now what you're doing. It's more efficiently and clearly expressed as hist(arr <- replicate(10^4, sum(sample(91:99, 100, replace=TRUE)))%%100). If you omit the %%100 and change 91:99 to 1:9 (which is the negative of 91:99 modulo 100), you will immediately find an explanation in the Central Limit Theorem. This is probably not a good model of anything realistic, though, because the slightest contamination by one value around, say, 40-60, would destroy this pattern. $\endgroup$
    – whuber
    Mar 1 '13 at 17:48
  • $\begingroup$ @whuber Thanks for the tip. I didn't know about "replicate". One more thing I'm puzzled about is if you increase the number you are summing over the effect goes away. Why? e.g. try changing the 100 to 500. $\endgroup$ Mar 1 '13 at 18:57
  • 1
    $\begingroup$ Look at the distribution before computing the results modulo $100$. The more data in the sum there are, the more the distribution spreads out. Computing its value mod $100$ effectively slices this distribution vertically into intervals $100$ wide and stacks them all together. When the distribution is much wider than $100$, imbalances in the stacking tend to average out, leading to uniformity. (A similar argument lies behind all attempts to justify Benford's Law: the values being summed are logarithms of numbers and the conclusion is that they have a near-uniform distribution.) $\endgroup$
    – whuber
    Mar 1 '13 at 19:22
1
$\begingroup$

Could you look at other corpuses of project values as a benchmark? I bet the US-gov, Worldbank, UN etc. must have some public project values information.

$\endgroup$
2
  • $\begingroup$ Why do you consider trying to use up all your approved budget as manipulations? I thought this was accepted practice? $\endgroup$ Feb 28 '13 at 14:15
  • $\begingroup$ @pnuts That's one view. :) My more charitable view is that most projects end up needing more than we thought they would. Or the approvers originally did not approve the full budget that we asked for. Hence we prioritize items and try to fit the best we can under the given budgetary constraints. $\endgroup$ Feb 28 '13 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.