Re: Proposal for 2.0: New monetary data types

["Adam Thompson" <..hidden..>]

> Well, technically they are still rational.  We haven't yet seen 1/pi
> denominations or the like ;-)

I suspected that was the wrong terminology.  I guess for "rational" I 
really meant "numbers that when expressed in floating-point notation have 
a shorter significand (mantissa) than the data type permits".  This isn't 
quite exactly the same thing as a non-repeating decimal, or a real number 
having no periodic component, but is probably the more accurate way to 
phrase it anyway since the presence of rounding was my concern.

> Part 1 is a multicurrency monetary set of data types.  These include
> basic operations (monetary + monetary, monetary + numeric,
> monetary/monetary, monetary/numeric, and so forth).  There are a few
> other functions to convert to numeric, to extract a currency, and to
> represent as text.  A function to change between currencies at a
> specified rate will be part of this module.  While I am involved in
> the spec process I will probably not be writing this section (which
> will probably be written in C).

This makes sense; I wasn't aware the money type was deprecated. 
(Interesting: in SQL Server 2008 the money type "has fewer precision 
complications" than numeric, according to some docs I was reading on the 
weekend.  No idea what that means.)

> Part 2 is a monetary subsystem for financial applications.  This will
> include currency validation logic, date-based exchange-rate handling,
> and the like.

This is the scary part; as a one-man band, maintaining this part seems 
like a Sisyphean task.  As a community, though, it's feasible, although 
barely (IMHO).

If part 1 relies on "at a specified rate", leaving the specification of 
rate up to the user, and part 2 concerns itself with (among other things) 
specifying that rate, that seems like a good separation of concerns.

I still don't see how to cleanly separate the aspects of the project 
without limiting its use to decimalized currencies, but that would seem to 
be an acceptable limitation.  After all, I don't expect your average 
date/timestamp data type to support archaeological dates.  And despite my 
earlier comments about prediction, it would probably take a major 
socio-political upheaval (e.g. nuclear winter, mass die-off, luddite 
revolution, etc.) before non-decimalized currency could be introduced.  We 
probably won't be worrying about currency data types in that event anyway.

This still seems complicated, but the pure data type will definitely find 
useful applications.

Thank you for taking the time to explain,
-Adam Thompson
 <..hidden..>
 (204) 291-7950