Anyway, I think at this level of abstraction those 3 scenarios cover everything that could possibly happen. This is only meant to deal with certainty/uncertainty at the level of performing calculations. There’s scope for more subtle distinctions at other levels, such as in the XML or in the functions that pull data out of XML and put it into objects.

For example, an amount might be damaged but it might still be possible to supply the correct figure from another part of the document or by comparing with other documents. In that case the XML could indicate that the figure is supplied by an editor but believed to be correct. Then maybe you could set a parameter when importing the XML to say whether those editorial interventions should be treated as exact or unknown (depending on how pedantic you want to be).

I don’t feel like I know enough about the textual issues you’re dealing with to comment on your specific design, I’m afraid. What is the circumstance under which min would be useful (scenario 3 above)?

As you said, keep the OldMoney class purely for doing calculations on money, so it only has pounds, shillings, and pence member variables and the overloaded operators to do things with them.

Then another class which can have one of the following three members:

exact – a single OldMoney object showing the exact amount

range – a pair of OldMoney objects showing the minimum and maximum amount

min – a single OldMoney object showing the minimum amount (maximum is completely unknown in this case)

When adding two instances of this class I can check to see which member exists in each instance.

If left and right both have exact: the result is assigned to exact

If both have range, or one has range and one has exact: a minimum and maximum are calculated and assigned to range

If either has min: only a minimum is calculated and assigned to min

Whatever happens the same kind of object gets returned so we can do the same operations on it and check its accuracy. The actual calculations are handled by the OldMoney class, and this new class just decides what to do with the results.

I haven’t tried implementing this yet, but it looks good on paper.

Think about how simple your OldMoney class would be without any uncertainty logic (especially if you add a fromPence constructor).

Now think about an UncertainOldMoney class that contains (composition is the pattern here, rather than inheritance) an OldMoney figure, plus some kind of descriptor for how, precisely it’s uncertain. You can then concentrate on what that descriptor should be on its own, separate from the pounds/pence logic. Perhaps you represent the range with a pair of min/max OldMoney objects, perhaps a flag, perhaps my offBy OldMoney logic, or perhaps something that’s more representative of the text and explains which digits are illegible or missing. The point is, you can play with that separately once you encapsulate that logic.

Basically there are three possible cases, depending on what’s missing from the documents:

1. We can calculate an exact total.
2. We can calculate a minimum and a maximum.
3. We can only calculate a minimum.

All three scenarios are likely to occur and need to be dealt with. 3 seems to be the trickiest one. My original idea of setting an exact flag was really about dealing with 3 but isn’t good enough for 2. Your imprecise money object looks like the best solution to 2 but I’m not sure how it would deal with 3.

Say you’re adding 5/4/3? to 2/1/3. (I’ll use parens for grouping here.) Rather than get (7/5/6)? and assume the whole figure is inexact, you should be able to get 7/5/(6?)

When you’re summing, in this system you may get an estimate of how much your total is off by.

Though I suppose that if you really were serious about finding that out, you’d replace your boolean exact parameter with an OldMoney off_by parameter that defaults to zero. So 5/4/3? could be represented as OldMoney(5, 4, 3, OldMoney(0,0,7)) (7 pence since you know that your reading of 3 was correct insofar as 3 was between 0 and 9, as there was only one digit written).

Assume furthermore that that off_by parameter has an off_by accessor that returns an OldMoney object.

With that setup, you’d change your add method to
return OldMoney(self.toPence()+r.toPence, self.off_by+r.off_by)

That could probably stand a bit of refactoring to separate the concept of exactness from Old Money. Remove the exact parameter from OldMoney and into its own ImpreciseMoney class, composed of two OldMoney variables. Add a bunch of ImpreciseMoney totals and you’ll get a figure and the amount it’s off by pretty easily.

return OldMoney(self.toPence()+r.toPence())

If you want to make sure your certainty parameter gets set, pass that down too:

return OldMoney(self.toPence()+r.toPence(), self.exact && r.exact)

Caveats: this is certainly not valid Python, so you may find yourself using what Java calls a static constructor method OldMoney.fromPence(p, e=True) instead. I’m also presuming you want one inexact figure to make the total inexact as well, hence the boolean AND.