Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!EU.net!news2.EUnet.fr!news.fnet.fr!ilog!news
From: parquier@halles.ilog.fr (Pierre Parquier)
Subject: Re: Gnu Common Lisp HELP!
In-Reply-To: Erik Naggum's message of 14 Jan 1996 23:18:02 +0000
Message-ID: <PARQUIER.96Jan15111355@halles.ilog.fr>
Lines: 97
Sender: news@ilog.fr
Nntp-Posting-Host: halles
Organization: ILOG S.A., Gentilly, France
References: <30F51D2D.C84@ling.umu.se> <19960111T202920Z@arcana.naggum.no>
	<4d61kh$tj@camelot.ccs.neu.edu> <PARQUIER.96Jan14182219@halles.ilog.fr>
	<19960114T231802Z@arcana.naggum.no>
Date: 15 Jan 1996 10:13:54 GMT


parquier>  CoBOL has addressed this issues for decades (its core
parquier>  business, so to speak), and felt no need for rational.
parquier>  Why?

erik>  because Cobol has a different set of types than Common Lisp
erik>  has, obviously.  case in point: Common Lisp does not have
erik>  fixed-point numbers, and Cobol does not have ratios.  you pick
erik>  what you need from what you can.

Not so.  CoBOL folks get what they need for their application field,
because they define the language for their needs and make it evolve.
There is nothing special about CoBOL: it is a community of intelligent
people.  They don't use ratio for accounting, because accounting
requires something else.

Conversely you can easily implement your fixed point numbers in Lisp.
Extensibility of Lisp is usefull, let it show!

erik>  since this is not comp.lang.cobol, but comp.lang.lisp, I
erik>  thought my answer should address this audience.

Same with me.  To understand how to use Lisp (or specifically Common
Lisp) in an unusual way (accounting), we must peek in languages
already addressing the issue.  That's a cheap way to avoid
re-inventing the wheel, or, equally evil, commit known mistakes.

erik>  I did not intend to argue against other language's more (or
erik>  less) appropriate types for representing monetary values, only
erik>  to argue against the usage of floating point to represent
erik>  monetary values when Common Lisp offers rationals, which is a
erik>  far better type, especially with bignums for both numerator and
erik>  denominator.

Suggesting rationals for this is precisely the point I am chalenging.

parquier>  First, the problem with rational for monetary matters:
parquier>  there are not enough operations defined on ratios for
parquier>  accounting.  Eg you cannot compute a monthly interest rate
parquier>  given a yearly interest rate.

erik>  this I do not understand.  [...] one may very well divide an
erik>  annual interest rate by 12

Ahem, this is wrong.  I am sorry to get into accounting basics in
comp.lang.lisp, but once again, I think it is releavant to the
question of properly using numbers in Lisp (or Common Lisp in
particular).

To get a monthly interest rate, you must use the twelvth root
(YearRate^(1/12)).  That computation is not rational.

I forgot to make an other point against rationals in accounting
(although I referred to it when visiting how CoBOLers work): many
computations don't match an exact value, and you have to introduce an
error.  When you split $10 in three, your result have to be an integer
amount of cents (or dollars, or tenth of a cent, you decide), and you
want to have unequal yet predicatable values.  Same thing when you
apply a rate: what's 11% of $1.23?

From the two arguments above, it stems that rational are inappropriate
because:

- their domain is too restricted to match all operation (contrary to
  floats)

- they are too precise to support natural rounding (contrary to
  integers, or fixed point)

parquier>  [...] fixed point values, but that's essentially the same,
parquier>  and that's very different from a ratio

erik>  this, too, I do not understand.  a fixed-point value is a ratio
erik>  with a constant denominator, is it not?  there should be no
erik>  difference from computing with ratios

The set of ratios with a given denominator is not usable as ratios,
you can't define rational division on it: what is 1/100 / 10/100?
Such set of numbers (ie the fixed point numbers) without division (or
with euclidian division only) is not a set of rational nubers, it is a
set of (poorly disguised) integers.

erik>  except for the obvious issue of speed, there is no need to
erik>  leave rational space.

I see this differently: there is no reason to leave integers (or fixed
point, if you will) for ratios to manipulate monetary units.  And
there are two reasons not to adopt rationals: their performance is
hardly predictable, and their comparative cost is huge.

And again, if you want to keep it simple, just use floats and be
carefull with the output.  That's how I program my payrolls at home.

   __________________________________________________
   Pierre Parquier                   parquier@ilog.fr
   ILOG S.A.                      http://www.ilog.com
   *** Use Lisp for C++ libraries: use Ilog Talk! ***
