Martin Gregorie said:
On that logic, if I buy a rivet off you for $0.0375 and offer you 1c,
you'll be happy to give me $0.0625 in bankable currency as change.
That logic in no wise implies that conclusion. There was absolutely
nothing in my argument that implied that all currency amounts are
suitable for every transaction. Your /reductio ad absurdum/ is itself
absurd. All I'm saying is that "USD 0.0375" is a currency amount,
suitable for such things as quoting stock prices or unit prices. You
have managed to duck and weave away from that point for post after
post without addressing it other than to misstate my argument.
More to the point, its meaningless to make or receive, e.g. [sic] a US dollar
payment with more than two decimal places.
That is at it may be, but that doesn't bear on what I said, even were
it true, which it isn't. Computerized transactions occur in sub-cent
resolutions all the time. And even did they not, the computer
programs must be able to deal with sub-cent currency amounts, for
example to correctly report unit cost. You've said nothing that
refutes that, either.
If your costing routines can produce any other answer you have to add
some form of post-processing and/or adjust the product packaging to avoid
generating payments that don't match the conventions of the required
currency. This is quite independent of how unit costs, stock prices or
whatever are represented.
That depends on the question. If you ask, "What is the unit price?"
and the answer "$ 0.0375" is rounded to "$ 0.04" you've got a wrong
answer. Not all currency amounts are payments.
"USD 0.0375" is a valid currency amount, representing for example the
unit cost of a widget in a purchase lot of 1000 widgets. Software had
better be competent to handle sub-cent currency amounts in most
monetary applications. The argument that individual transactions are
rarely denominated to that precision is specious and usually
irrelevant.