> Also all math within the function should be integer math, and the
> return
> result should be left as full precision real.
> This will avoid all rounding error.
> The result can then be rounded at application level.
It's impossible (AFAIK) to avoid all rounding errors in monetary amounts
as long as there continue to exist - anywhere in the world - irrational
denominations.
I can't name any such systems *currently* in use, although the most
obvious example is the Commonwealth (British) Shilling and Pence, set at
1s=12d. (Abbr for pence is d, not p.) If you want a fully generalizable
monetary currency system, you probably also have to accommodate such
bizzarities as the conversion between shillings and sheep :-) (1 shilling
= 1 sheep in Anglo-Saxon era, FYI... who needs a gold standard?!) FWIW,
the old French sou was worth 12 deniers (origin of "d" as abbreviation).
Not to mention the guinea, fixed at 21 shillings, where 20 shillings = 1
pound sterling, which makes 1 guinea = 1 1/21 pounds. If you want to
support arbitrary conversions, 44 1/2 guineas = 1 troy ounce of gold. Or
the Dutch stuiver, at 16 penning, although at least that's a rational
fraction.
If you want to retain rational mathematics, never mind integer math,
you'll pretty much have to declare that the type explicitly supports only
currencies in use from 1971-Feb-15 onward, although that's probably better
phrased as:
* You should probably limit the type to decimalized currencies, and
state
that limitation explicitly.
Aside from historical curiosities, the more I read of this proposal, the
more I smell feeping creaturism... increasingly, it doesn't sound like
something that can reasonably be black-boxed into a custom data type;
arbitrary monetary declaration, registration, etc., is an entire
application's worth of data, or at least a major subsystem. I would
compare this to the TZ subsystem in unix-like OSes: the complexity quickly
becomes insane once you start capturing temporal data. As an example,
what do you do with currencies that have been rebased or devalued, yet
retain their ISO currency code? The only solution I can see is to also
require an "effective date" as part of the type definition. If I want to
compare two pieces of data denominated in the *same* currency (ignoring my
previous case), since we have to store historical data (at least about
exchange rates, anyway) does the comparison take into account the
difference in a single currency's valuation?
For that matter, if it's encapsulated as a Pg custom type, how/where does
one store exchange rate data? (I don't know an awful lot about custom
data types in Pg, this might be a simple answer...)
This isn't an impossible task (again, witness the TZ subsystem), but what
we think of as historical curiosities today might well turn into reality
tomorrow - I'm not about to try predicting what government or regime X in
country Y might decide to do with its currency. Who gets to maintain all
that data? Some quasi-centralized maintenance group? Every user?
It sounds like a decent idea, but I would be more comfortable if this
remained encapsulated inside applications that need it, or if this became
some sort of standardized library (again, like TZ data) rather than a data
type specific to one database.
(Oh, if anyone cares, the various (historically recent) British coinages
are listed at
http://en.wikipedia.org/wiki/Coins_of_the_pound_sterling#Pre-decimal_coinage.)
-Adam Thompson
<athom...@athompso.net>
(204) 291-7950
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
