«

"Sudsy" <> wrote in message
news:...
> Roedy Green wrote:
> <snip>
> > It does get a bit strange when you bill people in foreign countries.
> > You bad better stick to mentioning the billing amount in one currency
> > only, even if they pay you in other ones. Otherwise it gets very
> > complicated what you mean by the outstanding balance. It differs
> > depending on what currencies you use and how they have fluctuated in
> > the interim.
>
> I was merely attempting to hint at the potential pitfalls. You can
> record the transaction in either the source or target currency, but
> there are always going to be ways to abuse the system.
> If you standardize on target then what happens when a country de-
> valuates its currency, for example?
> Would you agree that it can get complex?

No I don't agree, the "bill" should be completely nailed down at the
time the transaction is processed. If/when the end user decides to pay
there may be other adjustments like penalty interest, devaluation (as
you mention), bankrupcy and a bunch of other stuff.
For example: if I don't pay my bill for 10 years you should not have
to go back and change the original credit card slip.

>

On Wed, 16 Jun 2004 04:18:54 GMT, Roedy Green
<look-> wrote or quoted :

>See http://mindprod.com/zips/java/currcon.html
>and
>http://mindprod.com/projects/currencyconverter.html
>
>for details on how it works.

I have added some new documentation on how it works:

see http://mindprod.com/zips/java/currcon.html#MACROS
and
http://mindprod.com/zips/java/currcon.html#SOURCES


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

"Sudsy" <> wrote in message
news:...
> Neill wrote:
> <snip>
> > BTW, how can you say the applet uses the latest currency conversion
rates?
> > Does the applet load the rates upon each use? From where?
>
> Not meaning to dissuade you, but are you truly prepared for the
> complexities you're about to face?
<snip>

I'm not doing conversions, just simple math. I'm going by an article from
JavaWorld for now,
http://www.javaworld.com/javaworld/j...601-cents.html

In the article, it states BigDecimal loses accuracy around 13 digits or
more. Just curious what other people are using.

http://www.strikeiron.com provides currency conversion web services if you
need accurate rates in the future.


--

Neill Laney
http://www.laneyconsulting.com

"Liz" <> wrote in message
news:ncNzc.40482$eu.27737@attbi_s02...
>
> "Neill" <> wrote in message
> news:Q_Kzc.45399$. com...
> > I'm working on a shopping cart application and need to crunch some
> currency
> > numbers. This has been discussed on mailing lists I monitor, and it
seems
> > the recommended way is to create a currency class. Any pointers,
examples,
> > suggestions? TIA
> > --
> >
> > Neill Laney
> > http://www.laneyconsulting.com
> >
>
> If you don't want to go insane you will want to tap into a "web service"
> that you can "consult", perhaps using SOAP, for each transaction. The
> exchange rate changes quickly, so you will need to record the parameters
> for each transaction for further processing; you can't go back and do
> another
> lookup because the value will have changed. Maybe need to store this in a
> database.


Thanks, in fact, http://www.strikeiron.com offers just that. I'm not doing
conversions, just simple addition and multiplying. BigInteger is working
fine for now, just curious about statements I've heard made about creating
your own currency class to handle financial calculations.

"Tony Morris" <> wrote in message
news:cao163$ihq$...
>
> "Neill" <> wrote in message
> news:Q_Kzc.45399$. com...
> > I'm working on a shopping cart application and need to crunch some
> currency
> > numbers. This has been discussed on mailing lists I monitor, and it
seems
> > the recommended way is to create a currency class. Any pointers,
examples,
> > suggestions? TIA
> > --
> >
>
> The only problem I see with that solution is the problem itself.
> The problem with the problem is that the problem is not defined.
>
> More specifically, "need to crunch some currency numbers" is hardly a well
> specified requirement.
> Many people under-estimate the implied consequences when the problem
> definition is unclear (as in this case).
>
> --
> Tony Morris
> (BInfTech, Cert 3 I.T.)
> Software Engineer
> (2003 VTR1000F)
> Sun Certified Programmer for the Java 2 Platform (1.4)
> Sun Certified Developer for the Java 2 Platform
>
>

Sorry bout that, it's for a shopping cart application that needs simple
multiplication and addition. BigDecimal is working fine, just curious about
statements I've heard from other people about creating your own class to
handle financial calculations.

--

Neill Laney
http://www.laneyconsulting.com

Neill wrote:
> I'm not doing conversions, just simple math. I'm going by an article from
> JavaWorld for now,
> http://www.javaworld.com/javaworld/j...601-cents.html
>
> In the article, it states BigDecimal loses accuracy around 13 digits or
> more.

No, it doesn't. BigDecimal *never* "loses accuracy". What the article
states correctly is that double has a limited precision and
the sample code uses double as an intermediary for displaying
values via NumberFormat. Unfortunately, while the Java API proviced
a class that allows arbitrary-precision arithmetics, it does not
provide a means for formatting such numbers without imposing
limits of precision.

Neill wrote:
>
> I'm not doing conversions, just simple math. I'm going by an article from
> JavaWorld for now,
> http://www.javaworld.com/javaworld/j...601-cents.html
>
> In the article, it states BigDecimal loses accuracy around 13 digits or
> more. [...]

You've misread the article; go back and read it again.
(The article's caveat concerns conversion from BigDecimal
to double, not BigDecimal per se.)

--

On Wed, 16 Jun 2004 16:40:44 GMT, "Neill" <>
wrote or quoted :

>In the article, it states BigDecimal loses accuracy around 13 digits or
>more. Just curious what other people are using.

You are thinking of double, not BigDecimal. BigDecimal lets you fill
ram with complete precision.

See http://mindprod.com/jgloss/currency.html for your options.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

On Wed, 16 Jun 2004 16:48:26 GMT, "Neill" <>
wrote or quoted :

>Sorry bout that, it's for a shopping cart application that needs simple
>multiplication and addition. BigDecimal is working fine, just curious about
>statements I've heard from other people about creating your own class to
>handle financial calculations.

You perhaps want something that tracks how many digits past the
decimal each currency wants and display the national budgets to the
penny.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

The department of commerce provides conversion rates
and they use six decimal places. For example
12/19/2003 1.188733
for euro to usd


"Neill" <> wrote in message
news:gK_zc.47526$. com...
>
> "Sudsy" <> wrote in message
> news:...
> > Neill wrote:
> > <snip>
> > > BTW, how can you say the applet uses the latest currency conversion
> rates?
> > > Does the applet load the rates upon each use? From where?
> >
> > Not meaning to dissuade you, but are you truly prepared for the
> > complexities you're about to face?
> <snip>
>
> I'm not doing conversions, just simple math. I'm going by an article from
> JavaWorld for now,
> http://www.javaworld.com/javaworld/j...601-cents.html
>
> In the article, it states BigDecimal loses accuracy around 13 digits or
> more. Just curious what other people are using.
>
> http://www.strikeiron.com provides currency conversion web services if you
> need accurate rates in the future.
>
>
> --
>
> Neill Laney
> http://www.laneyconsulting.com
>
>