I need to resolve the following in computer language. I have situations that I have to split totals in smaller various disaggregations.
A client gets data from clinics around a district. However they only get totals instead of dis-aggregates of those totals. They are asking to calculate the dis aggregates based off of fixed fractions or based of historical fractions they will provide. However when I do use fractions, very often I find they don't equal the total provided. I need to total to match the sum of dis aggregations.
I must calculate an estimate for the number of new patients per gender and age group that visited a clinic every day for every day of the year but I may only use whole numbers. This works OK for large amount but for small amount I get a problem For example 3 new patients visited the clinic that day. I need to split it into 10 age groups and genders and the total must match the day total I was given
I get given fixed/historical fractions for the disaggregates e.g.
- 1:0.1
- 2:0.1
- 3:0.15
- 4:0.15
- 5:0.2
- 6:0.1
- 7:0.1
- 8:0.0.05
- 9:0.025
- 10:0.025
Total fractions equal 100%
If 5 new patients visited the clinic I get the following disaggregations
- 1:0.1 * 5 rounded = 1
- 2:0.1 * 5 rounded = 1
- 3:0.1 * 5 rounded = 1
- 4:0.2 * 5 rounded = 1
- 5:0.2 * 5 rounded = 1
- 6:0.1 * 5 rounded = 1
- 7:0.1 * 5 rounded = 1
- 8:0.0.05* 5 rounded = 0
- 9:0.025 * 5 rounded = 0
- 10:0.025 * 5 rounded = 0
So my total is 7 instead of 5. 2 more than I want.
If 2 new patients visit the clinic my total is 0, 2 less than I want.
Is there something in Mathematics that can assist me in making the sum of the disaggregations match the original total or is this not a Maths problem?
What mathematics can do with the requirements you have described is to show that they have absurd results. In fact, you have already used mathematics to show this.
We can list some circumstances under which such absurd requirements can be placed on a software program:
You did not correctly understand what the requirements were, and you are trying to implement the software to incorrect requirements.
The person(s) who set the requirements did not correctly understand what they were asking for, and set requirements whose results will be an unpleasant surprise to them.
The person(s) who set the requirements knew exactly what they were doing, and set the requirements in such a way that even though some of the results look absurd in isolation, some overall goal is achieved.
In any of those three circumstances, what I do is to go back to the person(s) who set the requirements and try to get further explanation of what they really want. One technique to discover what people really want is to give them some simple examples, such as the ones you have presented, and ask what a suitable result would be.
It is possible that nobody really wanted an estimate of exactly how many patients in group 1 attended the clinic on May 1, but they do want to know how many patients in group 1 attended the clinic in May, how many attended on Monday (adding together the attendance for all Mondays that year), and some other statistics like that. Perhaps they thought (mistakenly) that the best way to get such statistics was to have an estimated list of how many patients in each group attended on each individual day.
Or perhaps you are supposed to take a list of patients for the entire year, belonging to each of the ten groups in the proportions given, and randomly assign them to different days of the year according to the number of patients who actually arrived on each day, to support some sort of Monte Carlo analysis.
Or perhaps you are just supposed to round exactly the way you said, with a disclaimer such as "numbers in this column may not sum to the actual total due to rounding."
We should not have to guess why you were given a set of requirements in a particular form, and you should not have to guess either, at least not in cases like this where the reasons for the requirements might cause a larger project to fail.