Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu!sgiblab!pacbell.com!amdahl!netcomsv!netcom.com!mmk
From: mmk@netcom.com (Mark Kunichika)
Subject: Re: Money isn't always money (Was: Re: A Money object)
Message-ID: <mmkCxqAsw.11p@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <37akc6$4ur$1@melbourne.dialix.oz.au> <johnson.781990710@hal.cs.uiuc.edu> <1274321664@to.mobil.com>
Date: Sat, 15 Oct 1994 19:14:56 GMT
Lines: 89

In article <1274321664@to.mobil.com>,
Curt Welch - RDR <curt@to.mobil.com> wrote:
[snip]
>I'm working on a financial system in Smalltalk and all our money values
>are floats and doubles.  I wouldn't think of using some type of integer.
>The difference is that our system is not an accounting system.  It's a
>risk analysis system.  We aren't calculating account balances, we are
>estimating the value of a portfolio (and how that value may change over
>time.)
Much like us in airline forecasting. I though passengers should always
be integers, but an expected value model for airline forecasting will
very reasonably spit out fractions of people. Of course, the precedent
has already been set for fractional people in the (formerly) average
2.3 kids in the US family.

>
>To calculate risk (which is in units of money), we do calculations like
>this: "(money * money * varance) sqrt" so we do end up multipling
>money * money.

But the issue of what 2 $ * 2 $ is is still an issue. It's not $, but
rather $ squared. This brings up the whole issue of "units" in magnitude
calculation. In the above example, I believe variance is unitless (I
am just guessing, being too lazy to look it up), so the end result of 
the calculation would still be in units of "money" (the sqrt of a value
in money squared being simply linear money).

>
>And any time you deal with multiple currencies, you end up divding and
>multipling money.  Think about it.  What is an exchange rate?  It's
>(money / money).  And to convert money in one currency to another, you
>end up doing: money * ( money / money).

Ah, but Curt, look where you put your parens. Ralph's monetary system
would still work. Money / money has a unitless result (number). And
one is allowed to multiply money by a number.

>
>So, the point is, money isn't always Money!  Sometimes you need to use
>floating point numbers and sometimes you need to use integers (I doubt
>you would ever need to use fractions).  It depends on the application.
>And just like all programs that deal with floating point numbers - you
>have to be careful about errors and rounding problems.

I think I've once recommended the use of fractions in this case: You
have three departments to which you are allocating overhead administrative
costs (or allocating fixed assets, like inventory). You can either
allocate fractional money (since no whole 1/3 monetary unit will suffice
and depending on rounding of the sum of the allocated values to get a 
whole number is non-ideal), or give 1 cent extra to one of the departments.
I've recommended either: 1. Allocate the 1/3 cent in the first pass,
reclaiming it for "round-off" allocation when appropriate- one can't
just allocate at the end since there will sometimes be 2/3 of a cent
allocated to each dept. in the first pass. 2. (same solution, really) Round
on the first pass, but in this pass, keep track of "remainders," that
is the value rounded off. One has to be careful of rounding and applying
the remainder value at the right time to make sure you don't end up with
"leftovers," especially negative ones from rounding up too much.

>
>Curt Welch

The idea of magnitudes with units as a subclass of magnitude with
specialized treatment of money (whether "integerized/cent-ized/fixed," 
fractioned, or "floated") is attractive to me. Money is _not_ an
integer is Ralph said. Concrete money is fixed (no fractions of a
cent allowed). Hypothetical money can be anything - my account balance
in my mutual funds is calcuated in hundreths of shares, equating to 
fractional cents. Mathematical models may need to carry precision
to a greater degree than can be conretized. There's a pattern in
here somewhere :-)

My potentially related/unrelated work problem is the inability of
AMR to standardize the distance between airports. There are ~170 million
airport combinations today, so storing the standard value is often
impractical. A standardization effort has resulted in the selection
of a calculation and a source for airport location. The problem is
in the implementation of the calculation and the rounding of the
result to an integer. I thought: no problem, everyone has plenty
of precision/accuracy. But _noooo_, some systems produce 100.499999
and some produce 100.500000, rounding to 100 and 101. So much for
demanding the use of the non-spherical earth if this can't be resolved.

-mark
-- 
Mark Kunichika                                            mmk@netcom.com
Senior Consultant                                         (817) 967-6293
SABRE Decision Technologies                               (214) 380-8540
American Airlines         
      All opinions expressed here are those of the author and not of AA
