Problem reading/writing U.K. pound sign

[Martin Gregorie]

"Monetary" is not synonymous with "currency"?

It is when you're talking about financial transactions handled by a multi-
currency system, which is where this branch of the thread started.

Two columns in the table Roedy posted are highly relevant here: if the
amount isn't denominated in a valid ISO currency code and doesn't have
the correct number of digits after the decimal point for that currency it
is an invalid amount and would cause the transaction to be rejected.

 

[Lew]

I should have said, "Cost factor is not a currency amount?" Because,
of course, it is, unless as I pointed out you're using some irregular
understanding of "cost factor" or "currency amount".

It is when you're talking about financial transactions handled by a multi-
currency system, which is where this branch of the thread started.

Exactly! And currency exchange rates are not generally expressed to
only two places after the decimal point.

That "costing factor" you'd like to claim is not a "currency amount"
actually is one. It is a quantity representing a monetary amount
expressed in currency units . QED.

Two columns in the table Roedy posted are highly relevant here: if the
amount isn't denominated in a valid ISO currency code and doesn't have
the correct number of digits after the decimal point for that currency it
is an invalid amount and would cause the transaction to be rejected.

So then it would choke on the unit price example or any of the other
scenarios where you have to maintain currency amounts past two decimal
places. Thus its usefulness must be limited to those scenarios that
do not require currency amounts accurate past two places after the
decimal point.

 

[Martin Gregorie]

Exactly! And currency exchange rates are not generally expressed to
only two places after the decimal point.

Exchange rates are not monetary values. They have their own set of rules
which are quite different.

That "costing factor" you'd like to claim is not a "currency amount"
actually is one. It is a quantity representing a monetary amount
expressed in currency units . QED.

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.

So then it would choke on the unit price example or any of the other
scenarios where you have to maintain currency amounts past two decimal
places. Thus its usefulness must be limited to those scenarios that do
not require currency amounts accurate past two places after the decimal
point.

More to the point, its meaningless to make or receive, e.g. a US dollar
payment with more than two decimal places.

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.

 

[Lew]

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.

 

[Martin Gregorie]

Inflation?

That would be my guess. IIRC one of the Dirhams (Saudi?) used to have
three decimal places but now they all have two.

In a similar vein, when the UK switched to decimal currency it really
screwed up by retaining the existing pound as the basic unit. At that
time there were 240 pennies. Decimalising that to 100 new pennies left an
over-large penny, so they invented a new half-penny as a half-asses sort
of fix. This was repaired by inflation, which was huge through the late
'70s and early '80s so that somewhere along the line the half penny was
dropped.

FWIW Canada, Australia and New Zealand all went decimal before the UK and
all introduced a dollar, worth 10 shillings (so one old pound was two
dollars) and so bypassed the problem completely. This also let most of
the new coins with the exact same value as old coins, so the new coins
were made exactly the same size and both could be used interchangeably,
thus saving replacement costs and avoiding confusion. Same with notes.
The dollar was the same size and colour as the 10 shilling note.