On Wed, 05 Jul 2000 12:01:57 EST, the world broke into rejoicing as
Richard Wackerbarth <[EMAIL PROTECTED]> said:
> On Wed, 05 Jul 2000, Bill Gribble wrote:
> > Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > > No it is not. That is adding "apples" and "oranges".
> >
> > No, it isn't. Adding one "apple" to one "orange" is adding apples to
> > oranges. Adding 1.01 to 1.001 is adding a number in hundredths to a
> > number in thousandths, and there's nothing sacrilegious about it.
> >
> > I repeat: we need to enforce restrictions on what numbers we allow to
> > be used in what ways. I don't think those restrictions belong in the
> > library that implements numbers and the various dances that they do.
> >
> > > There is no reason that we should treat ALL measurements as numbers.
> > > You certainly want to treat things that are physically counted, like
> > > "Dollars" or "Shares" as a common meta-type because all of the operations
> > > on them don't care which units they are. It only matters that they are
> > > the same.
> >
> > That's all I'm talking about. I just include prices in the set of
> > objects including money and securities-holdings-amounts that should
> > use a common representation.
>
> I disagree. "Prices" are NOT in the same unit space as countable items.
> To FORCE them there places unreasonable constraints on the way we represent
> and handle them.
I agree with you on this; "Prices" are different particularly since they
have not one, but _TWO_ commodities associated with them.
> As I have said before, the design should not depend upon the
> representation.
On the other hand, if there turns out to be a single representation that is
sufficiently expressive to do all the things we want to do, then it may
be reasonable to have that as the One True Representation. I rather think
that we _can_ have a OTR that is Good Enough, by having a 64 bit integer
numerator, and a reference to a denominator that's either 32 or 64 bits
in size.
> Therefore, please humor me and consider that they are totally
> different. If, after specifying ALL the functionality, we find that
> we can merge them into a common type, that would affect only the
> implementation details.
Indeed. I agree that "prices" will be quite different from "quantities;"
I expect that there will be persistent difference between them.
The assumption that they Must Be The Same is as bad an idea as the
assumption that they Must Be Different.
I rather think that we should look at both, see what properties they
_need_ to have, and determine what common/differing properties fall out
of that. Intuition suggests to me that they will be somewhat different,
but we'll see...
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/linux.html>
"The entire structure of the antitrust statutes in this country is a
jumble of economic irrationality and ignorance. It is the product: (a)
of a gross misinterpretation of history; and (b) of rather naive, and
certainly unrealistic, economic theories."
-- Alan Greenspan
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
