Problem reading/writing U.K. pound sign
loial
But it is not being written correctly to the output file, even though
I am specifying UTF-8
Should this code work?
Reading :
InputStream fr;
BufferedReader br;
try {
fr = new FileInputStream(strDocumentFile);
br = new BufferedReader(new InputStreamReader(fr, "UTF-8"));
}
catch (java.io.FileNotFoundException e) {
String strReturn = "FileNotFoundException trying to open " +
strInFile;
traceError (strReturn);
return strReturn;
}
catch (java.io.UnsupportedEncodingException e) {
String strReturn = "FileNotFoundException trying to open " +
strInFile;
traceError (strReturn);
return strReturn;
}
String s = null;
do {
try {
s = br.readLine();
} catch (Exception e) {
String strReturn = getExceptionStackString(e) + " while
reading " + strInFile;
traceError (strReturn);
return strReturn;
}
Writing :
OutputStream fw;
BufferedWriter bw;
try {
fw = new FileOutputStream(strOutFile,true);
bw = new BufferedWriter(new OutputStreamWriter(fw, "UTF-8"));
}
catch (java.io.FileNotFoundException e) {
strReturn = "FileNotFoundException trying to open " +
strOutFile;
traceError (strReturn);
return strReturn;
}
catch (java.io.UnsupportedEncodingException e) {
strReturn = "FileNotFoundException trying to open " +
strOutFile;
traceError (strReturn);
return strReturn;
}
bw.write(s);
Peter Duniho
> I am reading and writing a files which contains the U.K pound sign �
>
> But it is not being written correctly to the output file, even though
> I am specifying UTF-8
>
> Should this code work?
I'm sure the code does what the Java documentation says it does.
But, you haven't shown how you actually write out the � symbol � that
is, where you define and use that character as part of the output � nor
how you determine whether it's being read correctly, never mind have you
provided a SSCCE to demonstrate whatever issue you're having.
There's no way to know, given what code you did post, whether it would
in fact work. Or, rather, taken literally the code you did post cannot
possibly work, but there is some superset of that code that could.
For your convenience, I've included a SSCCE that does in fact write a �
symbol to an OutputStream, and then reads the � symbol back from an
InputStream representing the same data. My example uses an in-memory
stream, but you should be able to easily adapt it to handle a file
instead. (If you copy-and-paste the code, make sure you put it in a
source file that supports the � character, such as UTF-8�otherwise,
you'll have to specify the character point explicitly using the \u
notation).
Pete
import java.io.BufferedReader;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.io.UnsupportedEncodingException;
public class TestWriteUKPound
{
/**
* @param args
*/
public static void main(String[] args)
{
ReadStream(new ByteArrayInputStream(
((ByteArrayOutputStream)WriteUKPound(new
ByteArrayOutputStream())).toByteArray()));
}
private static OutputStream WriteUKPound(OutputStream stream)
{
OutputStreamWriter writer = null;
try
{
writer = new OutputStreamWriter(stream, "UTF-8");
writer.write("�");
}
catch (UnsupportedEncodingException e1)
{
// TODO Auto-generated catch block
e1.printStackTrace();
}
catch (IOException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
finally
{
try
{
if (writer != null)
{
writer.close();
}
}
catch (IOException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
}
return stream;
}
private static void ReadStream(InputStream stream)
{
BufferedReader reader = null;
try
{
reader = new BufferedReader(new InputStreamReader(stream,
"UTF-8"));
String str;
while ((str = reader.readLine()) != null)
{
System.out.println(str);
}
}
catch (UnsupportedEncodingException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
catch (IOException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
finally
{
try
{
if (reader != null)
{
reader.close();
}
}
catch (IOException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
loial
001£999.99
Here is my test program code which I am compiling and running on
linux.
import java.io.*;
import java.util.*;
public class poundtesting {
public static void main(String[] args) {
String strReturn;
String strDocumentFile = "/home/john/poundtest";
InputStream fr;
BufferedReader br = null;
try {
fr = new FileInputStream(strDocumentFile);
br = new BufferedReader(new InputStreamReader(fr, "UTF-8"));
}
catch (java.io.FileNotFoundException e) {
strReturn = "FileNotFoundException trying to open " +
strDocumentFile;
System.out.println(strReturn);
}
catch (java.io.UnsupportedEncodingException e) {
strReturn = "FileNotFoundException trying to open " +
strDocumentFile;
System.out.println(strReturn);
}
String s = null;
String outline = null;
do {
try {
s = br.readLine();
if (s != null) {
outline = s;
System.out.println(s);
}
} catch (Exception e) {
strReturn = " Error while reading " + strDocumentFile;
System.out.println(strReturn);
}
} while (s != null);
String strBatchFile = "/home/john/poundout";
OutputStream fw;
BufferedWriter bw = null;
try {
fw = new FileOutputStream(strBatchFile,true);
bw = new BufferedWriter(new OutputStreamWriter(fw, "UTF-8"));
}
catch (java.io.FileNotFoundException e) {
strReturn = "FileNotFoundException trying to open " +
strBatchFile;
System.out.println(strReturn);
}
catch (java.io.UnsupportedEncodingException e) {
strReturn = "FileNotFoundException trying to open " +
strBatchFile;
System.out.println(strReturn);
}
try {
bw.write(outline);
bw.newLine();
} catch (IOException e) {
strReturn = "IOEXception trying to write " + strBatchFile ;
System.out.println(strReturn);
}
try {
br.close();
bw.close();
} catch (Exception e) {
// Don't care
}
}
}
RedGrittyBrick
loial wrote:
> Here is my one line test data file
> 001£999.99
>
> Here is my test program code which I am compiling and running on
> linux.
>
<snip>
Your code works correctly on my PC. The output file contains a pound
sign encoded as code-point 0xa3 which is correct for UTF-8 and for
ISO-8859-1 Latin1.
What byte-values do you see in your output file? Can you post a hex dump?
--
RGB
John B. Matthews
<95a05c15-5f3a-4f97...@p8g2000yqb.googlegroups.com>,
loial <jldun...@googlemail.com> wrote:
> Here is my one line test data file
>
> 001£999.99
Your program appears to work as expected on Mac OS X 10.5.8, Java 1.5
and Ubuntu 9.10, Java version 1.6, as does Pete's. Here's the data file
contents, identical before and after. It looks correctly encoded to me:
000000: 30 30 31 c2 a3 39 39 39 2e 39 39 0a 001£999.99.
> Here is my test program code which I am compiling and running
> on linux.
What distribution, version and Java implementation?
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Lothar Kimmeringer
> The output file contains a pound
> sign encoded as code-point 0xa3 which is correct for UTF-8 and for
> ISO-8859-1 Latin1.
It surely isn't correct for UTF8. You have missed the peceding
0xc2 or there is something wrong with your test.
Regards, Lothar
--
Lothar Kimmeringer E-Mail: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
bugbear
> RedGrittyBrick wrote:
>
>> The output file contains a pound
>> sign encoded as code-point 0xa3 which is correct for UTF-8 and for
>> ISO-8859-1 Latin1.
>
> It surely isn't correct for UTF8. You have missed the peceding
> 0xc2 or there is something wrong with your test.
Depends wether you're talking about and encoding or a code point.
BugBear
Lothar Kimmeringer
The thread is about encoding and "RedGrittyBrick" say "encoded
as" leading me to the assumtion that his posting is as well.
RedGrittyBrick
Lothar Kimmeringer wrote:
> RedGrittyBrick wrote:
>
>> The output file contains a pound
>> sign encoded as code-point 0xa3 which is correct for UTF-8 and for
>> ISO-8859-1 Latin1.
>
> It surely isn't correct for UTF8. You have missed the peceding
> 0xc2 or there is something wrong with your test.
>
I was using gvim to inspect the output file, it showed the £ correctly
when I told it the file was utf8 encoded. I used Gvim's ga command to
show the code-point of the character under the cursor. I forgot about
the multibyte encoding details (For which I should have used the g8
command).
Thanks for the correction.
--
RGB
rossum
<jldun...@googlemail.com> wrote:
>I am reading and writing a files which contains the U.K pound sign £
>
>But it is not being written correctly to the output file, even though
>I am specifying UTF-8
[snip code]
One alternative is to use "GBP" instead, at least for output. How
much control do you have over the format of the input files?
rossum
John B. Matthews
Lothar Kimmeringer <news2...@kimmeringer.de> wrote:
> bugbear wrote:
>
> > Lothar Kimmeringer wrote:
> >> RedGrittyBrick wrote:
> >>
> >>> The output file contains a pound
> >>> sign encoded as code-point 0xa3 which is correct for UTF-8 and for
> >>> ISO-8859-1 Latin1.
> >>
> >> It surely isn't correct for UTF8. You have missed the peceding
> >> 0xc2 or there is something wrong with your test.
> >
> > Depends wether you're talking about and encoding or a code point.
>
> The thread is about encoding and "RedGrittyBrick" say "encoded
> as" leading me to the assumtion that his posting is as well.
I couldn't see anything wrong with RGB's statement, but I frequently
stumble over the terminology. This is especially true in column A of the
Latin-1 Supplement [1], where the code-point and code-value seem to
coincide. I've broken it down to make sure I understand [2]. I'd welcome
any corrections or clarifications.
Glyph: £ (pound sign)
Unicode code-point, escape: \u00a3
UCS-4/UCS-32 code-value, hex: 0xa3
UTF-8 encoding, no BOM, hex octets: c2a3
Given the UTF-8 octet sequence for the UCS-4 range 0000 0080-0000 07FF,
110xxxxx 10xxxxxx
-------- --------
c2 a3 = 11000010 10100011
10 100011 = 10100011 = a3
Mac users may like the desktop Calculator's "Programmer View", which
conveniently displays ASCII or Unicode glyphs.
[1]<http://www.unicode.org/charts/PDF/U0080.pdf>
[2]<http://www.ietf.org/rfc/rfc2279.txt>
Roedy Green
who said :
>I am reading and writing a files which contains the U.K pound sign �
>
>But it is not being written correctly to the output file, even though
>I am specifying UTF-8
See http://mindprod.com/jgloss/sscce.html
If you post a complete programs, it is easier for people to help you.
They don't then have to write a sandwich to run your code.
For code to write/read a pound sign see
http://mindprod.com/applet/fileio.html
For the pound sign use '\u00a3'. If you use the character plain, it
may get scrambled if your source code is not UTF-8 too.
Recall that the console is likely not UTF-8, no displaying a result
there will likely get scrambled.
see http://mindprod.com/jgloss/encoding.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
There is no end to what can be accomplished if you don�t care who gets the credit.
~ Art Rennison
Martin Gregorie
In a multicurrency financial program I'd expect to see the ISO currency
codes used rather than currency symbols for both input and output.
Many systems will accept further abbreviations too, e.g. "GBP 32.00" or
"USD 1.5B", and I wouldn't expect drop-down currency lists to be used
either, since entering a single field like those shown is faster than
using a mouse to select from a currency list and then typing the amount.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Roedy Green
<mar...@address-in-sig.invalid> wrote, quoted or indirectly quoted
someone who said :
>In a multicurrency financial program I'd expect to see the ISO currency
>codes used rather than currency symbols for both input and output.
This is CSV file the CurrCon uses to determine the currency symbol:
#currency abbr, decimals, currency symbol, currency name
AED, 2, \u00a4, Utd. Arab Emir. Dirham
AFA, 2, \u00a4, Afghanistan Afghani
ALL, 2, \u00a4, Albanian Lek
ANG, 2, \u00a4, NL Antillian Guilders
AON, 2, \u00a4, Angolan New Kwanza
ARS, 2, \u20b1, Argentine Pesos
AUD, 2, $, Australian Dollars
AWG, 2, \u00a4, Aruban Florins
BBD, 2, $, Barbados Dollars
BDT, 2, \u00a4, Bangladeshi Taka
BGL, 2, \u00a4, Bulgarian Lev
BHD, 2, \u00a4, Bahraini Dinars
BIF, 0, \u20a3, Burundi Francs
BMD, 2, $, Bermudian Dollars
BND, 2, $, Brunei Dollars
BOB, 2, \u00a4, Bolivian Boliviano
BRL, 2, \u20a2, Brazilian Real
BSD, 2, $, Bahamanian Dollars
BTN, 2, \u00a4, Bhutan Ngultrum
BWP, 2, \u00a4, Botswana Pula
BZD, 2, $, Belize Dollars
CAD, 2, $, Canadian Dollars
CHF, 2, \u20a3, Swiss Francs
CLP, 0, \u20b1, Chilean Pesos
CNY, 2, \u00a4, Chinese Yuan Renminbi
COP, 2, \u20b1, Colombian Pesos
CRC, 2, \u20a1, Costa Rican Colon
CSK, 2, \u00a4, Czech Koruna
CUP, 2, \u20b1, Cuban Pesos
CVE, 2, \u00a4, Cape Verde Escudos
CYP, 2, \u00a3, Cyprus Pound
DJF, 0, \u20a3, Djibouti Francs
DKK, 2, \u00a4, Danish Krone
DOP, 2, \u20b1, Dominican R. Pesos
DZD, 2, \u00a4, Algerian Dinars
ECS, 0, \u00a4, Ecuador Sucre
EEK, 2, \u00a4, Estonian Kroon
EGP, 2, \u00a3, Egyptian Pounds
ETB, 2, \u00a4, Ethiopian Birr
EUR, 2, \u20ac, Euros
FJD, 2, $, Fiji Dollars
FKP, 2, \u00a3, Falkland Islands Pounds
GBP, 2, \u00a3, British Pounds
GHC, 2, \u20b5, Ghanaian Cedi
GIP, 2, \u00a3, Gibraltar Pounds
GMD, 2, \u00a4, Gambian Dalasi
GNF, 0, \u20a3, Guinea Francs
GTQ, 2, \u00a4, Guatemalan Quetzal
GYD, 2, $, Guyanese Dollars
HKD, 2, $, Hong Kong Dollars
HNL, 2, \u00a4, Honduran Lempira
HRK, 2, \u00a4, Croatian Kuna
HTG, 2, \u00a4, Haitian Gourde
HUF, 2, \u00a4, Hungarian Forint
IDR, 2, \u00a4, Indonesian Rupiah
ILS, 2, \u20aa, Israeli New Shekels
INR, 2, \u20a8, Indian Rupee
IRR, 2, \ufdfc, Iranian Rial
ISK, 2, \u00a4, Iceland Krona
JMD, 2, $, Jamaican Dollars
JOD, 2, \u00a4, Jordanian Dinars
JPY, 0, \u00a5, Japanese Yen
KES, 2, \u00a4, Kenyan Shillings
KHR, 2, \u17db, Cambodian Riel
KMF, 0, \u20a3, Comoros Francs
KPW, 2, \u20a9, North Korean Won
KRW, 0, \u20a9, South-Korean Won
KWD, 2, \u00a4, Kuwaiti Dinar
KYD, 2, $, Cayman Islands Dollars
KZT, 2, \u00a4, Kazakhstan Tenge
LAK, 2, \u20ad, Lao Kip
LBP, 2, \u00a3, Lebanese Pounds
LKR, 2, \u00a4, Sri Lanka Rupees
LRD, 2, $, Liberian Dollars
LSL, 2, \u00a4, Lesotho Loti
LTL, 2, \u00a4, Lithuanian Litas
LVL, 2, \u00a4, Latvian Lats
LYD, 2, \u00a4, Libyan Dinar
MAD, 2, \u00a4, Moroccan Dirham
MGF, 0, \u20a3, Malagasy Francs
MMK, 2, \u00a4, Myanmar Kyat
MNT, 2, \u20ae, Mongolian Tugrik
MOP, 2, \u00a4, Macau Pataca
MRO, 2, \u00a4, Mauritanian Ouguiya
MTL, 2, \u20a4, Maltese Lira
MUR, 2, \u00a4, Mauritius Rupee
MVR, 2, \u00a4, Maldive Rufiyaa
MWK, 2, \u00a4, Malawi Kwacha
MXP, 2, \u20b1, Mexican Pesos
MYR, 2, \u00a4, Malaysian Ringgit
MZM, 2, \u00a4, Mozambique Metical
NAD, 2, $, Namibia Dollars
NGN, 2, \u20a6, Nigerian Naira
NIO, 2, \u00a4, Nicaraguan Cordoba Oro
NOK, 2, \u00a4, Norwegian Kroner
NPR, 2, \u00a4, Nepalese Rupees
NZD, 2, $, New Zealand Dollars
OMR, 2, \ufdfc, Omani Rial
PAB, 2, \u00a4, Panamanian Balboa
PEN, 2, \u00a4, Peruvian Nuevo Sol
PGK, 2, \u00a4, Papua New Guinea Kina
PHP, 2, \u20b1, Philippine Pesos
PKR, 2, \u00a4, Pakistan Rupee
PLZ, 2, \u00a4, Polish Zloty
PYG, 0, \u20b2, Paraguay Guarani
QAR, 2, \ufdfc, Qatari Rial
ROL, 2, \u00a4, Romanian Leu
RSD, 0, \u00a4, Serbian dinar
RUB, 2, \u00a4, Russian Roubles
SAR, 2, \u00a4, Saudi Riyal
SBD, 2, $, Solomon Islands Dollars
SCR, 2, \u00a4, Seychelles Rupees
SDD, 2, \u00a4, Sudanese Dinars
SEK, 2, \u00a4, Swedish Krona
SGD, 2, $, Singapore Dollars
SHP, 2, \u00a3, St. Helena Pounds
SIT, 2, \u00a4, Slovenian Tolar
SLL, 2, \u00a4, Sierra Leone Leone
SOS, 2, \u00a4, Somali Shillings
SRG, 2, \u00a4, Suriname Guilder
STD, 2, \u00a4, Sao Tome/Principe Dobra
SVC, 2, \u20a1, El Salvador Colon
SYP, 2, \u00a3, Syrian Pounds
SZL, 2, \u00a4, Swaziland Lilangeni
THB, 2, \u0e3f, Thai Baht
TND, 2, \u00a4, Tunisian Dinars
TOP, 2, \u00a4, Tonga Pa'anga
TRL, 0, \u20a4, Turkish Lira
TTD, 2, $, Trinidad/Tobago Dollars
TWD, 2, $, Taiwan Dollars
TZS, 2, \u00a4, Tanzanian Shillings
UAH, 2, \u20b4, Ukraine Hryvnia
UGS, 2, \u00a4, Uganda Shillings
USD, 2, $, US Dollars
UYP, 2, \u20b1, Uruguayan Pesos
VEB, 2, \u00a4, Venezuelan Bolivar
VND, 2, \u20ab, Vietnamese Dong
VUV, 0, \u00a4, Vanuatu Vatu
WST, 2, \u00a4, Samoan Tala
XAF, 0, \u20a3, CFA Franc BEAC
XCD, 2, $, East Caribbean Dollars
XOF, 0, \u20a3, CFA Franc BCEAO
XAG, 2, \u0020, Silver (oz.)
XAU, 3, \u0020, gold (oz.)
XPT, 3, \u0020, platitum (oz.)
YER, 2, \ufdfc, Yemeni Rial
YUN, 2, \u00a4, Yugoslav Dinars
ZAR, 2, \u00a4, South African Rand
ZMK, 2, \u00a4, Zambian Kwacha
ZWD, 2, $, Zimbabwe Dollars
Martin Gregorie
> On Tue, 12 Jan 2010 23:49:34 +0000 (UTC), Martin Gregorie
> <mar...@address-in-sig.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>>In a multicurrency financial program I'd expect to see the ISO currency
>>codes used rather than currency symbols for both input and output.
>
> This is CSV file the CurrCon uses to determine the currency symbol:
>
> #currency abbr, decimals, currency symbol, currency name
>
Yes, that's the info you'd need, but its faster for the user if its used
to validate the input string after entry, rather than to produce a long,
scrollable selection list. You need the decimal place info for both
validation and to expand abbreviations like 1.5M correctly. 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.
Lew
> 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.
>
While it is unconventional to quote, say, USD prices to the eighth-
cent, mil or beyond, it is not unheard of.
Admittedly it's a special-purpose use case when it happens, but one
should not always be too convinced that the minimum useful monetary
precision is one one-hundredth of the currency unit.
--
Lew
Tom Anderson
British Telecom phone bills are worked out in tenths of a penny
(millipounds?), then rounded (down) to pence at the end.
tom
--
The other big thing is the method by which these new discoveries had
been made. They had not been made in studies. They were not made by
the ransacking of ancient texts. Nobody deduced the existence of Nova
Scotia. These things were discovered by the very simple process of
driving a ship into them. A ship is a form of scientific instrument. --
Allan Chapman
Thomas Pornin
> Admittedly it's a special-purpose use case when it happens, but one
> should not always be too convinced that the minimum useful monetary
> precision is one one-hundredth of the currency unit.
As far as I know, banking rules in Europe mandate use of 5 decimals
internally, with explicit and deterministic rules for rouding.
--Thomas Pornin
Eric Sosman
> [...] I'm intrigued
> to see that there are no longer any currencies with three decimal places.
Today's quote for Motors Liquidation Company (MTLQQ.PK, the
successor/inheritor/janitor/whatever for General Motors) is a
whopping 0.7112 USD, up 0.0302 from yesterday's close of 0.681.
(Source: <http://finance.yahoo.com/q?s=MTLQQ.PK>)
--
Eric Sosman
eso...@ieee-dot-org.invalid
Martin Gregorie
Sure, but that sort of manipulation will usually be in some sort of
costing calculation - part of a BOM package. You also see it in UK equity
prices, which are quoted in pence to two decimal places rather than
pounds.
I was referring in particular to currency amounts within financial
transactions which AFAIK always specify the number of decimal places to
be used for a given currency.
Thomas Pornin is also correct - its usual to specify the exact
calculation rules to be applied to currency conversions. The European
Central Bank certainly defines the rules for converting between Euros and
other currencies and IIRC so does S.W.I.F.T.
Martin Gregorie
> On 1/13/2010 8:08 AM, Martin Gregorie wrote:
>> [...] I'm intrigued
>> to see that there are no longer any currencies with three decimal
>> places. [...]
>
> Today's quote for Motors Liquidation Company (MTLQQ.PK, the
> successor/inheritor/janitor/whatever for General Motors) is a whopping
> 0.7112 USD, up 0.0302 from yesterday's close of 0.681. (Source:
> <http://finance.yahoo.com/q?s=MTLQQ.PK>)
Thats a stock exchange price, not a currency amount, which is what I was
muttering about.
Arne Vajhøj
Words can have different meanings to different people.
But I would expect most developers to consider any price
including the price of 1 stock a currency amount.
Arne
Martin Gregorie
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
>> But I would expect most developers to consider any price including the
>> price of 1 stock a currency amount.
>
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.
>
"Monetary" is not synonymous with "currency"?
Just because 0.03750 is not an amount you actually paid in the
transaction doesn't mean it isn't a currency amount; it's just not the
actual currency amount of the actual transaction. You still have to
deal with the unit price when working up the transaction.
The computer system for Acme Widget Co. still has to handle that unit
price in its calculations and records. How else would you display the
answer to the query, "What is the unit price of the widget?" other
than as a currency amount?
Assuming you're using "currency amount" in the obvious, normal sense
of "monetary amount expressed in currency units". If you have some
non-obvious, ergo far less useful definition of "currency amount", do
please share it.
--
Lew
Martin Gregorie
> Arne Vajhøj wrote:
>>> But I would expect most developers to consider any price including the
>>> price of 1 stock a currency amount.
>>
>>
> 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.
>>
>>
> "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
>>> 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
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.
>> 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.
Lew
>> 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...@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
Martin Gregorie
> "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.
Kenneth P. Turvey
> 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 <evot...@gmail.com>
Martin Gregorie
> 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?
>
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.