Re: Problem reading/writing U.K. pound sign

From:

Lew <lew@lewscanon.com>

Newsgroups:

comp.lang.java.programmer

Date:

Thu, 14 Jan 2010 12:41:56 -0800 (PST)

Message-ID:

<8f09e091-0cc7-4f07-97f1-615edb63f4de@g31g2000vbr.googlegroups.com>

Martin Gregorie wrote:

Respectfully disagree. Its a common issue with pricing anything that is
sold only in multi-packs - and this includes equities, which are almost
never bought or sold as single items. For instance:

- Eric quoted MTLQQ.PK at 0.7112 USD. You'd normally buy equities
in shapes of at least $100 but, if you held a minimum quantity and
took dividends as additional shares you might end up with a dividen=

of, say, 6 shares, value $4.2672, plus $0.68 c/f from a dividend=

  $4.95

  IOW, the calculation will always be adjusted so any cash amount, in
  this case the dividend and the c/f value, will be in dollars and
  whole cents.

- If you're building a widget that needs 8 rivets, which are sold
$37.50
  in packs of 1000 the BOM package will for certain use a unit price
  of 0.03750 when costing the widget but, again, you'll never see tha=

used as a monetary amount. Its just a cost factor.

Lew wrote:

"Monetary" is not synonymous with "currency"?

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".

Martin Gregorie wrote:

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.

--
Lew