ne useful technique in doing this is to associate the "ownership"
with a role rather than a person and permit certain individuals to
alter the ownership property.
Often the policy will require that this ability be data sensitive.
--
llows us to use the standard arithmetical functions within
the database to perform summations, etc.
From an accounting viewpoint, "freight cars of corn" and "bushels of
corn" are NOT the same commodity. However, a "manufacturing" process
can convert one to the ot
On Wed, 02 Aug 2000, Buddha Buck wrote:
> > On Wed, 02 Aug 2000, Buddha Buck wrote:
> > > I view "$/8 USD" and "$/100 USD" to be -similar- commodities. You
> > > can't add or subtract them, but comparison should be possible.
> > > Conversion between them is possible without an explicit conversio
On Wed, 02 Aug 2000, Buddha Buck wrote:
> I view "$/8 USD" and "$/100 USD" to be -similar- commodities. You can't
> add or subtract them, but comparison should be possible. Conversion
> between them is possible without an explicit conversion ratio -- the ratio
> is implicit. They probably don'
On Wed, 02 Aug 2000, Jason Rennie wrote:
> [EMAIL PROTECTED] said:
> > gnc_numeric gnc_numeric_add(gnc_numeric a, gnc_numeric b,
> > gint64 denom, gnc_numeric_round_t how);
>
> [EMAIL PROTECTED] said:
> > The problem is that the calls to do simple things like "add"
On Tue, 01 Aug 2000, Jason Rennie wrote:
> [EMAIL PROTECTED] said:
> > You want the denominator in EACH account to be set so that 1/D
> > represents exactly the smallest difference in allowable values for
> > that account.
>
> Sure. That makes sense. There may be some situations where
> determi
On Tue, 01 Aug 2000, Christopher Browne wrote:
> > Placing this unification code inside the addition code is a computational
> > burden on EVERY addition, even the vast majority (if not all) of the
> > additions which are performed on ammounts from the same account that are
> > already in the sam
On Tue, 01 Aug 2000, Jason Rennie wrote:
> [EMAIL PROTECTED] said:
> > 1) Your API does not hide the implementation details. If we change the
> > representation of an amount, many calls will have to be changed
> > rather than localizing the changes to the "math" routines.
>
> The "constructor" w
On Tue, 01 Aug 2000, Jason Rennie wrote:
> [EMAIL PROTECTED] said:
> > Most book keeping is done within a currency and this will be
> > dramatically faster.
>
> Nope. Using the integer representation, you'll need one `if' statement
> to determine that you're dealing with two numbers of the same
On Tue, 01 Aug 2000, Bill Gribble wrote:
> On Mon, Jul 31, 2000 at 08:05:04PM -0500, Richard Wackerbarth wrote:
> > 2) The "denominator" may need to be the reciprocal of an integer
> > greater than unity.
>
> Good point. How about, as was suggested, an idea
On Tue, 01 Aug 2000, Jason Rennie wrote:
> [EMAIL PROTECTED] said:
> > 2) The "denominator" may need to be the reciprocal of an integer
> > greater than unity.
>
> Since the denominator should never be negative or zero if it is acting
> in its normal role, we could say that a negative denominato
On Fri, 28 Jul 2000, Bill Gribble wrote:
> On Fri, Jul 28, 2000 at 12:14:20PM -0500, Richard Wackerbarth wrote:
> > And you have yet to address the objections that I, and others, have been
> > raising for an equal period of time.
>
> If you can state any objection that impac
On Mon, 31 Jul 2000, Terry wrote:
> Richard, you have renewed my faith in the human condition - I observed
> many, many decades ago that there are a lot of people who only want to
> stand on the sidelines and throw brickbats at the participants, then
> whenever anything doesn't work exactly right
On Sun, 30 Jul 2000, Jason Rennie wrote:
> [EMAIL PROTECTED] said:
> > Therefore it is unnecessary to carry that denominator with the
> > individual values. It can be retrieved from the description of the
> > units in those very few places where it actually gets used.
>
> Yup. Makes sense. O
On Sat, 29 Jul 2000, Terry wrote:
> On Fri, 28 Jul 2000, you wrote:
> > > I haven't seen a
> > > similar single discription and corresponding implementation on your
> > > proposal.
> >
> > I haven't made it in that form because it is too trivial.
> > At the level of Bill's proposal, I have:
> >
>
On Sun, 30 Jul 2000, Jason Rennie wrote:
> [EMAIL PROTECTED] said:
> > In between two bank balances there are a finite number number of other
> > balances, therefore they _can_ be represented by the set of integers.
> > This reasoning is the root of my suggestion to allow restricting
> > allowable
On Sat, 29 Jul 2000, Bill Gribble wrote:
> The kind of duplicate detection you are looking for is in the feature
> list for the next revision of the QIF importer. It's a little
> trickier, because the fields describing the transaction are often very
> different (comparing a hand-entered transact
On Sat, 29 Jul 2000, Bill Gribble wrote:
> On Sat, Jul 29, 2000 at 01:30:05PM +0100, Steven Murdoch wrote:
> > It seems clear to me that there are many occasions where a value is
> > stored, and it's only permissable values are integers (things like
> > number of shares, bank balance, number of ac
On Fri, 28 Jul 2000, Jason Rennie wrote:
> So, here something from left field...
>
> All of this discussion concerning roundoff error, internal number
> representation, etc. seems to be assuming that there *is* a right answer.
> i.e. if we discuss and think hard enough, we'll be able to come up wi
OK, I'll give up on expecting a clean interface to solve the "round-off"
problem. I'm sure Bill will eventually get something that gives the right
answers.
The problem that I am now encountering has to do with the cost basis of
inventory (in particular equities).
Assume that, in January, I pu
On Fri, 28 Jul 2000, Jon Trowbridge wrote:
> On Fri, Jul 28, 2000 at 12:24:53PM -0500, Richard Wackerbarth wrote:
> > All you need to do that is switch to some form of integer amounts of SCU.
> > and associate a formatting routine to display the result in a different
> > u
On Fri, 28 Jul 2000, Bill Gribble wrote:
> On Fri, Jul 28, 2000 at 08:14:47AM -0500, Christopher Browne wrote:
> > Unfortunately, all Bill has provided is a way of representing and
> > manipulating rational values.
> >
> > But I don't think it represents what people really need to do with
> > _fin
On Fri, 28 Jul 2000, Bill Gribble wrote:
> > PLEASE, plan before you implement.
> "plan before you implement"? Do you want me to start quoting the
> MONTHS of correspondence that led to my most recent proposal?
And you have yet to address the objections that I, and others, have been
raising fo
On Fri, 28 Jul 2000, Robert Graham Merkel wrote:
> Richard Wackerbarth writes:
> > On Fri, 28 Jul 2000, Robert Graham Merkel wrote:
> > > > - If only SGML, then that forces anyone that gets a CVS archive
> > > > to add yet another component to those that th
On Fri, 28 Jul 2000, Christopher Browne wrote:
> Unfortunately, all Bill has provided is a way of representing and
> manipulating rational values. There's nothing particularly _wrong_ or
> awful about having that.
> But I don't think it represents what people really need to do with
> _financial
On Thu, 27 Jul 2000, Terry wrote:
> On Thu, 27 Jul 2000, you wrote:
> > Bill's proposal is to implement operations on a representation that can
> > express not only integral SCUs, but more general expressions. In using
> > this representation, it will be necessary to add appropriate constraints
>
On Fri, 28 Jul 2000, Robert Graham Merkel wrote:
> > - If only SGML, then that forces anyone that gets a CVS archive
> > to add yet another component to those that they install.
>
> And the people who will scream most loudly are those who are trying to
> build gnucash on anything other than Lin
On Fri, 28 Jul 2000, Christopher Browne wrote:
> here, and am decidedly _NOT_ taking an accounting approach...>
>
> We could probably do _pretty well_ with some fixed base if we used a base
> with quite a lot of useful divisors. For instance, 360 has, as factors:
> 2, 3, 4, 5, 6, 8, 9, 10, 12
On Thu, 27 Jul 2000, Steven Murdoch wrote:
> I've been thinking about storing gnc_numberic as a rational number and
> had a look at some finance/law/accounting books and I thought that there
> is one potential problem that may occur, please correct me if I'm wrong
> or have misunderstood the propo
On Tue, 25 Jul 2000, Terry wrote:
> Actually - yes - the stock are purchased through dividend re-investment.
> The dividend is computed to 1/1,000 USD (stock total is carried on their
> books to 1/1,000 and the dividend is computed to 1/1,000 USD per stock
> unit.) Thus the transaction value in US
On Tue, 25 Jul 2000, John Hasler wrote:
> Richard Wackerbarth writes:
> > Actually, price is a rational and quantity is an integer. (At least in
> > the pumps that I helped program)
>
> I'm not talking about gasoline anymore, but about prices and quantities in
>
On Tue, 25 Jul 2000, John Hasler wrote:
> The pump knows that 1.699 * gallons = total sale, anyway.
> IMHO transaction_total != price * quantity.
> Rather, transaction_total = f(price, quantity)
>
> where transaction_total is an integer,
> price and quantity are reals, and
Actually, price is
On Tue, 25 Jul 2000, John Hasler wrote:
> Bill Gribble writes:
> > Are there *any* places where correct record keeping requires one to keep
> > track of dollar values down to the 1/1000 of a dollar?
>
> Property tax rates are stated in mills, but the actual tax bills are always
> in dollars and ce
On Tue, 25 Jul 2000, Bill Gribble wrote:
> Clark Jones <[EMAIL PROTECTED]> writes:
> > I hate to quibble with Gribble :-), but in actuallity the bill
> > establishing the Dollar as the U.S. currency (written by Thomas
> > Jefferson) defines the "mill" -- which is 1/1000 of a U.S. Dollar --
> > tho
On Tue, 25 Jul 2000, Glen Ditchfield wrote:
> On Mon, 24 Jul 2000, Bill Gribble wrote:
> > 1. gnc_commodity knows about the smallest possible transactional
> > unit for trading the commodity (for example, 1/100 of a US Dollar
> > or 1/1000 of a mutual fund share).
> Is the smallest tr
On Tue, 25 Jul 2000, Bill Gribble wrote:
> I definitely don't think rounding should be a default. For most
> financial transactions, the math you're doing won't require any
> rounding/truncation at all, and for the ones that do (total-value
> computations, for example) you probably want to use R
On Fri, 21 Jul 2000, Eric Mitchell wrote:
> > Rather than attempt to make a generalized
> > translation widget that does everything for everybody, I think we should
> > look to customized preprocessors that each handle one particular format
> > and translate it into a consistent format for importi
On Fri, 21 Jul 2000, Keith Refson wrote:
> One of the UK banks (which I am considering switching my accounts to
> -- hence the message) offers the option to interface with Microsoft
> Money. There is apparently no obvious or straightforward way to
> download a QIF file (as allowed by my current p
On Fri, 21 Jul 2000, James A. Treacy wrote:
> At a minimum, could the importer be modified so that you can select which
> field is used to select accounts when importing, e.g. the Memo field
> instead of the category (L in .qif)? When importing data from my bank, all
> the transactions appear to c
On Fri, 21 Jul 2000, Rob Walker wrote:
> I have 3 1/2 years of
> data there, will it create these new accounts for me as it goes when
> it encounters my new categories while I do my imports?
Fundamentally, yes. The procedure works best if you have exported all of the
data for another set of book
On Wed, 19 Jul 2000, Terry wrote:
> > > Again, I do have a valid reason for asking and which relates to gnucash
> > > directly.
> > I fail to see how this relates to gnucash. Just because there are a limited
> > number of fractions in common usage (I would guess that is caused by the human
> > in
On Tue, 18 Jul 2000, Terry wrote:
> > I specifically said "some" rational arithmetic. Prices, by their definition,
> > will require the equivalent of rational arithmetic within the implementation of
> > the operations that use them.
>
> No I still disagree - rational arithmetic is not necessary.
On Tue, 18 Jul 2000, Terry wrote:
> I have a question for the gnucash developer community regarding commodities,
> stocks etc. and how they are priced, traded, listed, whatever.
>
> I have always seen such things listed/priced/traded as single fractions, i.e.,
>
> a single stock would be "liste
On Mon, 17 Jul 2000, Jason Rennie wrote:
> [EMAIL PROTECTED] said:
> > I believe that, although useful, your proposal can be accomplished by
> > a more general mechanism. "Taxability" is just one 'trait' that you
> > may want to assign to an account. By having a generalized system of
> > assigning
On Mon, 17 Jul 2000, Terry wrote:
> On Mon, 17 Jul 2000, you wrote:
>
> >
> > Seriously, some people are focusing on the wrong aspect of the problem.
> > The math will require some rational arithmetic. However, the real problem is
>
> No I don't think rational arithmetic is the way to go. Ratio
On Mon, 17 Jul 2000, Rob Walker wrote:
> Richard> Even that is not good enough. In a multi-user system, each
> Richard> user will want their own per account style.
> Good thought. I didn't realize that our multi-user gnucash was going
> to require logins to gnucash, but I thought that it would
On Sat, 15 Jul 2000, Christopher Browne wrote:
> > > As tax issues vary so much between jurisdictions, and are so complex,
> > > and most people will get accounting advice on them anyway, I'm
> > > hesitant to do them.
> >
> > You should forget the tax. In each country and in each year are very
On Sun, 16 Jul 2000, James A. Treacy wrote:
> On Mon, Jul 17, 2000 at 09:42:25AM +1000, Ben Stanley wrote:
> >
> > Of course, the proper fix for this problem is for some brave soul to
> > write an installer package to make the installation painless :-)
This is virtually impossible unless you sup
On Sun, 16 Jul 2000, Rob Walker wrote:
> >> The default register mode is nice, and I use it, but what about
> >> remembering what mode each register was last in, and each time that
> >> register is opened, opening it up with the last register setting?
>
> Dave> Do you mean remebering by account
On Wed, 12 Jul 2000, [EMAIL PROTECTED] wrote:
> i have create the file it.po . For to have the gnucash in italian what i
> must to do??
Do you mean "What do I have to do to get my copy to use it?"
or
"It works. What do I have to do to get it included in the gnucash
distribution?"
__
On Sat, 08 Jul 2000, Terry Boldt wrote:
> On Sat, 08 Jul 2000, you wrote:
> > Stocks can also be in fractional shares, thanks to things like stock
> > splits and "share-dividends".
>
> This I can atest to - one of the insurance companies I deal with converted
> from a mutual to public a few years
On Sat, 08 Jul 2000, Christopher Molnar wrote:
> Thanks to Richard and Bill who got back to me.
>
> I have sent both of you the QIF file that is causing the problem and I am
> hoping that you find the problem, or tell me what I was doing wrong. The
> export was done from Quicken Deluxe 2000 on a W
On Sat, 08 Jul 2000, Christopher Molnar wrote:
> Hello,
>
> I have a number of friends who have told me that they would use linux if
> there was a replacement for quicken. Well, I had never tried it so I
> started installing GNUCASH. Has all the features I want and need (working
> with 1.4.1). How
On Sat, 08 Jul 2000, Christopher Browne wrote:
> > Although this is functional, I object to re-denomination because
> > the auditors want the ledger to match the original transaction
> > documents.
> >
> > Once an entry is properly entered, that entry should never change.
>
> The thing that would
On Sat, 08 Jul 2000, Clark Jones wrote:
> Randolph Fritz wrote:
> > On Fri, Jul 07, 2000 at 01:11:20AM -0500, Richard Wackerbarth wrote:
> > > Commodities are counted. That, by definition, means that they are
> > > represented by an integer.
> Stocks can also be i
On Sat, 08 Jul 2000, Hendrik Boom wrote:
> > Hmmm... I don't recall anybody mentioning "time" as the unit of
> > measure... convert to seconds? minutes? hours? days? weeks? months?
> > years? I often deal with measurements in nanoseconds... many things get
> > charged for by unit time... e.g
On Sat, 08 Jul 2000, Hendrik Boom wrote:
> One of the big issues seems to be whether we have just one denominator
> for a commodity, or many.
> Let each commodity to have its own common denominator, but change this
> denominator when new transactions make it necessary. The new denominator
> be a
On Fri, 07 Jul 2000, Randolph Fritz wrote:
> On Fri, Jul 07, 2000 at 01:51:35PM -0500, Richard Wackerbarth wrote:
> > Right. And the dry goods were either measured in units of (3 inches) or
> > greater or no effort was made to account for the individual amounts sold.
> >
On Fri, 07 Jul 2000, Hendrik Boom wrote:
> > I don't think there is one; the _arguable_ counterexample would be the
> > situation where a market changes "denominations," but that may also be
> > argued to redenominate the commodity, which means it's not really the
> > same commodity anymore...
> >
On Fri, 07 Jul 2000, Jon Trowbridge wrote:
> Well, for what it is worth, holding shares in Red Hat means that you
> *own* a (probably very small) percentage of Red Hat, and your rights
> and obligations flow from that ownership.
>
> If you hold futures contracts, you own *nothing*. Instead, you
On Fri, 07 Jul 2000, John Hasler wrote:
> Buddha Buck writes:
> > Are "1/100 Dollars" and "1/64 Dollars" considered the same "commodity" or
> > different "commodities"?
>
> Your broker may quote you prices in "1/64 Dollars" but he will always bill
> you in "1/100 Dollars". You will never have to
On Fri, 07 Jul 2000, Buddha Buck wrote:
> I am concerned about "commodities" that differ by simple scaling factors.
>
> Are "1/100 Dollars" and "1/64 Dollars" considered the same "commodity" or
> different "commodities"? Should they be comparable? Should they use the
> same dispatched printing r
On Fri, 07 Jul 2000, Jon Trowbridge wrote:
> I think that the differences are substantial.
>
> A futures contract is just that; a contract. It has no intrinsic
> value outside of the gain or loss the execution of that contract might
> expose you to.
>
> > I typically pay off the margin and actua
On Fri, 07 Jul 2000, Randolph Fritz wrote:
> On Fri, Jul 07, 2000 at 07:39:36AM -0500, Richard Wackerbarth wrote:
> > That is not COUNTING. That is MEASURING and PRICING.
> >
> > And by the time the transaction gets past the cash register, that measure
> > has be
On Fri, 07 Jul 2000, Jon Trowbridge wrote:
> This is correct. One CBOT Soybean futures contract is for 5,
> bushels of beans, but the price is quoted by the bushel, in eighths of
> a cent.
Of course there are no actual soybeans involved. You are really just trading
pieces of paper :-)
> O
On Fri, 07 Jul 2000, John Hasler wrote:
> Richard Wackerbarth writes:
> > Besides, "milk" and "sugar" are poor examples. They are seldom sold by
> > the gallon (pound) but rather by the "container".
>
> Actually, milk is sold by the hundredwei
On Fri, 07 Jul 2000, Randolph Fritz wrote:
> On Fri, Jul 07, 2000 at 01:11:20AM -0500, Richard Wackerbarth wrote:
> > Commodities are counted. That, by definition, means that they are
> > represented by an integer. If you must use a rational, the denominator is
> > alw
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 pr
On Thu, 06 Jul 2000, you wrote:
> Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > For example, if the sales tax rate is 8 3/4 % (0.0875) we can
> > represent that as 37/400 or as 875/1. When we apply that to a
> > purchase of $1 (100/100) we get an answer of 37/
On Thu, 06 Jul 2000, Jon Trowbridge wrote:
> On Thu, Jul 06, 2000 at 12:33:04PM -0500, Richard Wackerbarth wrote:
> (2) That representing the prices of financial instruments is a
> different matter that representing quantities of currency for
> accounting purposes, and thus
On Thu, 06 Jul 2000, Shimpei Yamashita wrote:
> > 2) If you assume that all of the denominators for a given currency are
> > the same, you have not really gained anything by storing them repeatedly.
> > And you have introduced an additional possibility of error trying to
> > enforce the assertion
On Thu, 06 Jul 2000, Bill Gribble wrote:
> Buddha Buck <[EMAIL PROTECTED]> writes:
> > So, why the argument?
>
> It's a high-priority goal of mine to make the result of this process
> be a straightforward, testable, stand-alone mathematical library for
> dealing with financial numbers that other p
On Thu, 06 Jul 2000, Shimpei Yamashita wrote:
> On Wed, Jul 05, 2000 at 09:10:12PM -0500, Christopher Browne wrote:
> > I would anticipate that having the basic representation be via
> > rational numbers (e.g. - numerator + denominator in each entry) will
> > _prevent_ using an SQL DBMS, because S
On Thu, 06 Jul 2000, Bill Gribble wrote:
> 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
On Wed, 05 Jul 2000, Christopher Browne wrote:
> > 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. Fu
On Wed, 05 Jul 2000, Christopher Browne wrote:
> b) One that is strongly tied to the "commodity."
>
> Thus, you have:
>
> struct gnc_commodity_value {
>gint64 quantity;
>creference commodity_id;
> };
>
> along with
>
> struct commodity_info {
>creference commodity_id;
>char commod
On Wed, 05 Jul 2000, Christopher Browne wrote:
> > 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 t
On Wed, 05 Jul 2000, Rob Browning wrote:
> Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > Personally, I think that this is one weakness in the present
> > approach to report generation. I would prefer to see an
> > implementation that does the calculations in the
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
>
On Wed, 05 Jul 2000, Rob Browning wrote:
> Handling error conditions is a PITA if you want to write in a more
> functional style. One way to handle it is to make it so that #f as a
> return value is always an error, and if there's a real value, then you
> return something like (cons #t value).
On Wed, 05 Jul 2000, Bill Gribble wrote:
> At the top level, I think the first thing to nail down is a numeric
> representation rather than a monetary-value representation. There
> needs to be a layer that enforces restrictions such as "can't add
> dollars to pounds", but I believe that we must
On Tue, 04 Jul 2000, Rob Browning wrote:
> Well, we had been planning, and I think Bill's been working on,
...
> Does this seem to match OK with what everyone needs?
In a word, NO!
Although it might work, I see some real problems. Which brings me to the
fundamental question: "Why is anyone IM
On Mon, 03 Jul 2000, Robert Graham Merkel wrote:
> It has occurred to me that we really need some account-level
> meta-information beyond the fixed fields and ...
> make our reporting
> a whole lot more powerful and easier to use - as a simple example, if
> somebody specified a "project" field, w
On Sun, 02 Jul 2000, Christopher Browne wrote:
> Buddha Buck <[EMAIL PROTECTED]> said:
> > After a 2:1 stock split, I
> > can simply change the recorded price to "200 MSFT = $5010" and the
> > number of shares bought to 200, and accounting wise, everything works
> > out OK -- including the cost
On Sun, 02 Jul 2000, Robert Graham Merkel wrote:
> > There is virtually no value in having a large number of "accounts" if I
> > cannot automate the summary of those accounts for the purpose at hand.
> >
> > The way I summarize things has to vary with the purpose.
>
> Perhaps I misspoke. Wha
On Sun, 02 Jul 2000, Robert Graham Merkel wrote:
> To get a handle on the reporting features
> * Periodic income/expense reports (over a year, by month, for
> example). Don't have, but it's not hard.
The sticky thing here has to do with the generation of reports that
cross accounting periods. W
On Sat, 01 Jul 2000, Robert Graham Merkel wrote:
> There has been some discussion recently over whether the engine should
> have features that allow extracting higher-level summary information
> (such as totals etc.) for reporting purposes.
> Transaction reports
> Investment reports
> "Total re
On Fri, 30 Jun 2000, Clark Jones wrote:
> The "business oriented" languages usually do it with "binary
> coded decimal", rather than scaled integers.
BCD is a big "win" if you are mostly doing I/O rather than computation.
For example, in the typical customer billing, you may have to output
virtua
On Fri, 30 Jun 2000, Christopher Browne wrote:
> Come on, people. The issue is _not_ what "object system" is being
> used, or what language is being used, but rather _what the numeric
> representation should be_.
To a large extent, I agree.
> C and C++ have the _same_ basic sets of basic data
On Fri, 30 Jun 2000, Clark Jones wrote:
> Well, floating point is definitely NOT the proper solution for US dollars
On this, I think we finally agree.
> One could use multiprecision integer and represent
> US dollars in "cents", but that becomes a real pain in the tush, and so
> is not a proper
On Fri, 30 Jun 2000, Clark Jones wrote:
> If someone is going to go to the trouble of implementing a
> calculator popup, they might as well make it available whenever you're
> entering data into a "currency" field (e.g., a "credit" or a "debit").
> Also, the currently displayed "value" in the "ca
On Fri, 30 Jun 2000, Ralf Gorholt wrote:
> perhaps I understand something wrong but I think one of the purposes of
> operator overloading in C++ is to be able to write something like "x = y +
> z" instead of "gnc_money_plus(x, y, z)"
You are correct. However Robert was pointing out that you do n
On Tue, 27 Jun 2000, Dave Peticolas wrote:
> > > ... in the reconcile window,
> >
> > So they act just like check boxes.
> They have more information than check boxes. Some can have 'c' to
> indicate a 'cleared' transaction.
Reconciliation forms a partition on the entries within an account.
Eac
On Sat, 24 Jun 2000, Christopher Browne wrote:
> - When the "huge horde of balances" pop up to be recomputed, it may
> very well be that this indicates that something is wrong. There
> should not be thousands of things getting recomputed.
Yes, there was something wrong. Some computer change
On Sat, 24 Jun 2000, Robert Graham Merkel wrote:
> Oh, and one other thing. Performance when doing monetary arithmetic
> is currently not an issue. As far as I can see, this isn't likely to
> change, whatever implementation we end up using. Is this the case?
I think you are wrong. When you ha
On Fri, 23 Jun 2000, Sean Millichamp wrote:
> On Fri, 23 Jun 2000, Rob Walker wrote:
> > Richard> Actually, income and expenses get "closed" at the end of the
> > Richard> accounting period by transferring their balance to the equity
> > Richard> accounts.
> For those who want to close the accoun
On Fri, 23 Jun 2000, Bill Gribble wrote:
> 7. Abstraction. Since we have made at least one fundamental mistake
> in specifying the original representation of monetary values in
> gnucash, we have to assume that we may make others. We are going
> to have to do significant surger
On Fri, 23 Jun 2000, Rob Walker wrote:
> Bill> This is basically like a Quicken
> Bill> category; as you get more paychecks, the balance of the account
> Bill> will increase and you can see the total of your salary income.
>
> Isn't there a "magic" account which keeps getting bigger and bigger,
>
On Wed, 21 Jun 2000, Christopher Browne wrote:
> > I believe, historically at least, banks have used "mils," or $0.001.
> > They may use finer divisions now. Currently stock exchanges use
> > sixteenths (or is it eights?), but there is talk of going decimal.
>
> I'm quite disappointed in the tho
On Wed, 21 Jun 2000, Christopher Browne wrote:
> Although that's only half the story; the other half is that you
> do have another amount that needs to be tracked, namely the cost.
Right. You must track both the number of units AND their actual cost.
> It is pretty useless on an ongoing basis, w
1 - 100 of 202 matches
Mail list logo
