On Fri, 07 Jul 2000 01:11:20 EST, the world broke into rejoicing as
Richard Wackerbarth <[EMAIL PROTECTED]> said:
> On Thu, 06 Jul 2000, Christopher Browne wrote:
> > On 06 Jul 2000 09:10:23 EST, the world broke into rejoicing as
> >
> > Bill Gribble <[EMAIL PROTECTED]> said:
> > > Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > > > I agree that rather than describing the properties of a currency for
> > > > the "denominator" of an amount, we should simply reference the
> > > > currency. The properties of it are common to all instances of amounts
> > > > denominated in that currency. Further, that reference can be "factored"
> > > > and we can simply store the numerator of each entry.
> > >
> > > Storing the two halves that make a value in completely different
> > > layers of representation is wrong, IMO. If a "monetary value" is a
> > > single concept, it should be stored as a single entity. To do
> > > otherwise is just to ask for headache after headache.
>
> > Ah, but storing the denominator, which is identical for all USD
> > transactions, in each transaction, breaks normalization rules.
> > So this more or less begs the question:
> > Which headache do you want?
>
> > I'd rather go with the headache that diminishes storage requirements and
> > likely increases speed, rather than one that requires that I replicate
> > data, and gives the opportunity to replicate it _WRONG_.
>
> Further, I will argue that, when speaking of "commodities", Bill's
> denominator is really a display scaling factor that he has misplaced.
When you say "Bill has misplaced, Bill has overlooked, Bill's wrong,"
and such, this leaves little room for Bill to be prepared to be terribly
accepting of this. Don't attack the _person_; you'll just tick him off,
and that isn't useful to the goal of trying to convince him that you
have a better idea.
> Commodities are counted. That, by definition, means that they are represented
> by an integer. If you must use a rational, the denominator is always unity.
>
> Remember that we count CENTS and not DOLLARS. The fact that you choose to
> represent a large sum of CENTS by the equivalent DOLLAR amount is an artifact
> of the display rather than anything intrinsic to the counting process.
>
> And Bill has overlooked the fact that simply knowing the scaling factor is
> still not enough. He will still have to reference the currency for things
> like the currency symbol and other conventions about the display or to
> find/verify that the units are compatible.
>
> Another problem is that the display scale may be less than unity.
>
> In particular, consider bonds. One bond may have a face value of $5000 or
> $1000 or some other amount. The unit is the BOND, not the DOLLAR, or CENT. If
> I sell the smallest unit, I must sell a face value of $5000 (or whatever).
> Now, just to keep things interesting, the practice is to display the bond
> holding in face-value dollars rather than physical binds. Thus, Bill's
> display denominator is 1/5000.
>
> And we still have not discussed exchange rates. These clearly require TWO
> rather than ONE commodity. Further, when we compute a price from two
> commodity amounts, that tells you nothing about the "smallest unit". That
> information will have to be stored elsewhere.
I think I agree with the issues here; you've got a couple of useful examples
that demonstrate how the scaling needs to be associated with the commodity,
and not with the value itself.
I suggest the thought that how any amount is to be displayed is a matter
that needs to be passed through a dispatch function that considers the
commodity.
For instance, for an amount in $USD, you'd probably want to have an
amount displayed to look like:
$24,155.23
or
$-1,341.79
In contrast, a quantity of shares of stock might be displayed as:
142 22/32
or
72 11/32
or some such thing.
The display function needs to provide a way to treat the "denominator"
_as well as the denomination_. That would include the ability to
display the UK "Pound" symbol (that I seem unable to display here;
UK readers _might_ see one "#" here).
Since the use of such a "dispatch function" will be pervasive in working
with commodity values (note: my use of the word "commodity" as a more
generic term than "currency" or "stocks" or "inventory" seeks to be
more inclusive than any of them), I see no problem in keeping some of the
"factors" in places that will need to be accessed separately from each
"value." We're guaranteed a whole lot of indirection; we might as well
use that to minimize the amount of data that needs to be replicated.
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/linux.html>
"What a depressingly stupid machine." -- Marvin
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
