Jason Rennie wrote:
> [EMAIL PROTECTED] said:
> > Now, having stated that, it would be silly to allow entry of
> > fractions. Even the stock & commodity markets have dropped fractions
> > and gone to decimals.
>
> Would it be reasonable to have the user enter a decimal and round that
> number
On Fri, 04 Aug 2000 11:16:49 EST, the world broke into rejoicing as
Robert Graham Merkel <[EMAIL PROTECTED]> said:
> Ben Stanley writes:
> > In Australia, we currently have a curious system. The smallest unit of
> > currency is 1 cent (AU$ 0.01), which is what bank accounts are kept in.
> > Ho
Ben Stanley writes:
> In Australia, we currently have a curious system. The smallest unit of
> currency is 1 cent (AU$ 0.01), which is what bank accounts are kept in.
> However, the smallest coin is 5 cents. All cash transactions are rounded
> to the nearest 5 cents.
>
> Thus, the denominat
In Australia, we currently have a curious system. The smallest unit of
currency is 1 cent (AU$ 0.01), which is what bank accounts are kept in.
However, the smallest coin is 5 cents. All cash transactions are rounded
to the nearest 5 cents.
Thus, the denominator for your fractionalised representat
Richard Wackerbarth wrote:
>
> As I see it, we seem to have some implicit common currency that we use as the
> "native" currency for a particular set of books. Here in the USA, it would be
> USD, but in Canada, it would probably be CDN. In either case, if I have one
> account in each currency, I
Phillip J Shelton writes:
> Hello,
>
> I have not had any experience in using any of the major non-free money software,
> and have only used one small shareware to mimic my bank statements. So the
> following is probably trivial but please bear with me, I would like some
> clarification.
>
Hello,
I have not had any experience in using any of the major non-free money software,
and have only used one small shareware to mimic my bank statements. So the
following is probably trivial but please bear with me, I would like some
clarification.
I have been watching the to-ing and throw-ing
Rolando Roman writes:
> i dont see printing availibility in gnucash, is that true?
1.4.x doesn't have printing. 1.5.x has report printing, as well as
check printing.
Robert Merkel [EMAIL PROTECTED]
On Wed, 02 Aug 2000 12:54:52 -0400, the world broke into rejoicing as
Buddha Buck <[EMAIL PROTECTED]> said:
> At 11:25 AM 8/2/00 -0400, Jason Rennie wrote:
>
> >[EMAIL PROTECTED] said:
> > > I view "$/8 USD" and "$/100 USD" to be -similar- commodities. You
> > > can't add or subtract them, but
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
i dont see printing availibility in gnucash, is that true?
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
On Wed, 02 Aug 2000 20:32:44 EST, the world broke into rejoicing as
Richard Wackerbarth <[EMAIL PROTECTED]> said:
> 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.
> 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 p
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'
At 11:25 AM 8/2/00 -0400, Jason Rennie wrote:
>[EMAIL PROTECTED] said:
> > I view "$/8 USD" and "$/100 USD" to be -similar- commodities. You
> > can't add or subtract them, but comparison should be possible.
>
>Is it true that you would *never* want to add/subtract such
>commodities? I can't t
[EMAIL PROTECTED] said:
> I view "$/8 USD" and "$/100 USD" to be -similar- commodities. You
> can't add or subtract them, but comparison should be possible.
Is it true that you would *never* want to add/subtract such
commodities? I can't think of any cases where you would want to, but
shoul
On Wed, 02 Aug 2000 06:53:18 EST, the world broke into rejoicing as
Richard Wackerbarth <[EMAIL PROTECTED]> said:
> 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 major
At 06:53 AM 8/2/00 -0500, Richard Wackerbarth wrote:
>Here, I think the question degenerates into "What is a commodity?"
>
>You and I view "$/8 USD" and "$/100 USD" as two different commodities. OTOH,
>I believes that Bill views them as the same commodity and feels that it is
>permissible to 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 22:32:23 EST, the world broke into rejoicing as
Richard Wackerbarth <[EMAIL PROTECTED]> said:
> 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 inte
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, 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 that the denominator
> take on negativ
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
Bill Gribble wrote:
>
> On Tue, Aug 01, 2000 at 04:36:56PM +0100, Steven Murdoch wrote:
> > For example the task of comparing two integers is trivial O(1)
> > complexity, but comparing two rationals is far from it and I think has
> > O(sqr_root(n)) complexity, so if this is done several times the
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 that the denominator
take on negative values (possibly hidden by a macro, i.e.
GNC_DEN
On Tue, Aug 01, 2000 at 04:36:56PM +0100, Steven Murdoch wrote:
> For example the task of comparing two integers is trivial O(1)
> complexity, but comparing two rationals is far from it and I think has
> O(sqr_root(n)) complexity, so if this is done several times the
> performance difference will
I think now would be a good time to more explicitly state a few ideas
about my last suggestion.
The reason I have done this is to allow values to be represented in
integers. This will have several other benefits I said in my previous
mail, but the more I think of it, he more I think the speed inc
[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" will obviously need to be changed. The
gnc_numeri
[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
determining the smallest difference isn't trivial, but it s
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 impacts the correctness of t
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, you wrote:
> 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.
>
>
[EMAIL PROTECTED] said:
> I might have one account denominated in eights of a share of XYZ
> stock and another in hundredths of a share of the same stock. In some
> respects, they are the "same", but they really need different
> denominators.
A denominator of 1000 would take care of both just
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
>
> [EMAIL PROTECTED] said:
> > I am not aware that anyone has suggested that there be a "universal"
> > denominator.
>
> The talk of having everything represented in "ergs" was be an example
> of using a "universal" denominator.
Based on the two postings concerning the "erg" as a fundamental
[EMAIL PROTECTED] said:
> I am not aware that anyone has suggested that there be a "universal"
> denominator.
The talk of having everything represented in "ergs" was be an example
of using a "universal" denominator.
[EMAIL PROTECTED] said:
> Therefore it is unnecessary to carry that denominat
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
[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 values of some variables to integers.
The numbe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 share
On Fri, 28 Jul 2000, you 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. I don't think we need to go so far as to burn
> the proposal, strew the ashes in a field, and
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.
That should make it easier to put down so that others can review it, comment on
it, improve on
> My question is would it be *easier* to implement the modifications
> needed to Gnucash if another type and it's associated funcions were
> added to the API that could only represent integers (say stored as a
> 64bit integer)?
>
Using 64 bit integers is a very powerful approach. I posted a note
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 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 accounts etc...). Bill's API
> is clearly sufficien
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 accounts etc...). Bill's API
is clearly sufficient for this purpose and already has the required
functions to accomodate
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 impacts the correctness of the
code, I'm happy to entertain it. I am not int
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
> > unit.
>
> Let's assume for
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 unit.
Let's assume for the moment that Bill's proposal is fundamentally
wrong
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, Jul 28, 2000 at 06:36:04AM -0500, Richard Wackerbarth wrote:
> I view Bill's implementation like Southwest Parkway, a multi-million
> dollar roadway leading nowhere. It was a fine roadway, but did not
> serve a real purpose because it addressed a non-existant need. It
> cost additional mil
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
> _financial amounts_.
>
> Once we get that library, the c
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
At 08:14 AM 7/28/00 -0500, Christopher Browne wrote:
>I'd rather put the emphasis on that next higher level library, which
>might look more like:
>
>struct finamt {
> numerator Q; /* Might be a rational value, if need be... */
> commodity C;
>};
>
>struct commodity {
> string IDENTIFIER;
On Thu, 27 Jul 2000 19:42:37 -0400, the world broke into rejoicing as
Terry <[EMAIL PROTECTED]> said:
> Richard, I'm curious (sometimes fatal :-) ) Bill has put together a fairly
> detailed proposal and implementation using rationals. I haven't seen
> a similar single discription and correspondin
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, 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 21:48:30 MST, the world broke into rejoicing as
Gordon Oliver <[EMAIL PROTECTED]> said:
> Hi all.
> One commentary that I would have with exact values is that
> in this (and any I imagine) accounting scheme we are representing
> one side of the story, i.e. we don't care what
On Wed, 26 Jul 2000 18:07:36 +0100, the world broke into rejoicing as
Steven Murdoch <[EMAIL PROTECTED]> said:
> Richard Wackerbarth wrote:
> >
> > On Tue, 25 Jul 2000, Terry wrote:
> > > Actually - yes - the stock are purchased through dividend
> re-investment.
> > > The dividend is compute
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 and
> conversions to assure that the sto
Steven Murdoch <[EMAIL PROTECTED]> writes:
> Say I buy 10 shares at 123_1/64 pence each. Gnucash will represent this
> as 7873/64 pence per share so the total transaction value will be
> 78730/64 pence. My dealer will pay the seller of the shares 1231 pence,
> and I will be billed for £12.31 as se
This discussion on internal representations reminds me of an idea I had once,
which it turns out some economists have also had - move all money to the 'erg
standard' - like the gold standard except that the fundamental unit of exchange
is the erg. Energy supplies and real-value prices tend over l
Steven Murdoch writes:
> The reason for the error is obvious...
Yes. You paid £12.31 for each 10 share purchase but told gnucash you paid
78730/64 pence. Why would you want to do that?
--
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin
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
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 proposal.
I don't want to make a theoretical point so I
Richard Wackerbarth wrote:
>
> 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
stoc
Christopher Browne writes:
> True. They were counting a discrete, countable quantity.
But delivering a continuous substance.
> Can you name one that people _actually use_ that is not discrete?
Gasoline.
> If we try to work using FP values,...
Relax, I'm not trying to get you to go back to F
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 -- though the only places wh
Rob Walker wrote:
>
> > On Mon, 24 Jul 2000 22:18:28 -0700, Clark Jones
> > <[EMAIL PROTECTED]> said:
>
> Clark> 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
> >>
Richard Wackerbarth writes:
> In practice, accounting always restricts the allowable values.
In practice, reality always restricts the allowable values. I don't see
how we can predict what those restrictions will be for anything but money,
though. Nor do I see the necessity of doing so.
> Rath
On 25 Jul 2000 18:17:35 EST, the world broke into rejoicing as
John Hasler <[EMAIL PROTECTED]> said:
> 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 abou
On 25 Jul 2000 09:29:49 EST, the world broke into rejoicing as
Bill Gribble <[EMAIL PROTECTED]> said:
> 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
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
> general. Treating price and quant
On Tue, 25 Jul 2000, you wrote:
> Terry writes:
> > Yes stock transactions
>
> Your broker bills you in thousandths of a dollar?
> --
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
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
general. Treating price and quantity as reals (always rationals or
integers in pract
Terry writes:
> Yes stock transactions
Your broker bills you in thousandths of a dollar?
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mai
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, you 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 -- though the only
Buddha Buck wrote:
>
> At 09:29 AM 7/25/00 -0500, you 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/10
Buddha Buck writes:
> I know that the local gas pumps do accurately treat the $1.699/gallon
> price as $1.699/gallon -- when I buy 10.000 gallons, I pay $16.99, not
> $17.00.
And when you buy 11.000 gallons you will be billed $18.69 (or maybe
$18.68), not $18.689.
> The pump evidentially knows a
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
Steven Murdoch <[EMAIL PROTECTED]> writes:
> "Floor(X): returns the largest (most positive) integral value less than
> or equal to X. When X is zero, the result has the sign of X; a zero
> result otherwise has a positive sign.
>
> Ceil(X) returns the smallest (most negative) integral value great
On Mon, 24 Jul 2000, Bill Gribble wrote:
> 2. gnc_commodity : representing currencies and other commodities
>
> 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
At 09:29 AM 7/25/00 -0500, you 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 -- though the
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 cents.
--
John Hasler
[EMAIL PROTECTED] (John Hasler
I haven't been on this list for long, so if this has already been
discussed please accept my apologies.
One thing I was unsure about was in the gnc_numeric API was about the
handling of negative amounts, especially during rounding. I have a few
questions/suggestions about this
For Floor and Ceil
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 -- though the only places where
> you're likely to run into
Phillip J Shelton <[EMAIL PROTECTED]> writes:
> Not really up on what is available my self so my comment is `Are
> there any engines out there that already do this type of math?
>
> And would it be safe to say you are looking at some kind of integer
> math?
The actual math code is quite simple.
> On Mon, 24 Jul 2000 22:18:28 -0700, Clark Jones
> <[EMAIL PROTECTED]> said:
Clark> 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).
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).
I hate to quibble with Gribble :-), but in actuallity the bill establishing
the Dollar
On Mon, Jul 24, 2000 at 05:41:58PM -0500, Bill Gribble wrote:
> 2. gnc_commodity knows the full name of the commodity
> ("International Business Machines", "US Dollars"), plus any
> mnemonic or nickname that is used for trading or quoting purposes
> ("IBM", "USD"), and the namespa
Not really up on what is available my self so my comment is `Are there any engines
out there that already do this type of math?
And would it be safe to say you are looking at some kind of integer math?
Phill
Bill Gribble wrote:
> 3. gnc_numeric : representing exact numbers
> --
Discussion of this topic on the list has been going on for a good long
while and it doesn't appear that we are going to reach a true
consensus.
With that in mind, I submit this proposal for modifying gnucash to use
exact quantities to represent numeric values. I understand that my
approach
99 matches
Mail list logo
