Problem reading/writing U.K. pound sign
in [Java Programming]
|
From: Lew on 14 Jan 2010 15:41 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 dividend >>> of, say, 6 shares, value $4.2672, plus $0.68 c/f from a dividend of >>> $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 that >>> 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
From: Martin Gregorie on 14 Jan 2010 16:40 On Thu, 14 Jan 2010 12:41:56 -0800, Lew wrote: > 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. >> 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. > 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. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Lew on 14 Jan 2010 17:03 Lew wrote: >> 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. > Martin Gregorie <mar...(a)address-in-sig.invalid> wrote: > 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. -- Lew
From: Martin Gregorie on 14 Jan 2010 20:40 On Thu, 14 Jan 2010 14:03:29 -0800, Lew wrote: > "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. > Agreed, but it is *not* valid in a financial transaction because it doesn't represent an exact amount that can be transferred between people or bank accounts. I believe I made it explicit at the start of this subthread that I was talking about financial transactions and only them. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Kenneth P. Turvey on 15 Jan 2010 00:15
On Wed, 13 Jan 2010 13:08:51 +0000, Martin Gregorie wrote: > I'm > intrigued to see that there are no longer any currencies with three > decimal places. Some years back a few middle eastern currencies used > them. Inflation? -- Kenneth P. Turvey <evoturvey(a)gmail.com> |