Re: RFC : Correcting some problems in rounding/number handling

[Dave Peticolas]

Christopher Browne writes:
> 
> By the way, it is _well_ worth taking a look at the GnuE docs;
> 
> 
> This page indicates:
> 
> "Amounts of money will not be stored as decimal(9,2) because there are
> some coutnries (e.g. -in the middle east) where there are 3 digits after
> the decimal point.  I would suggest to use a signed 64-bit-integer,
> unless the database does not support that.  In that case, decimal(18,0)
> would possibly be appropriate for every currency of the world.  In either
> case, amounts of money would be expressed in the smallest unit, e.g. in
> US-Cents, in British Pence, in German Pfennig and so on.
> 
> THere would of course be a currency table in which per currency is
> defined how many digits are after the decimal point, and how calculated
> amounts in that currency are to be rounded (e.g. - in Switzerland amounts
> are rounded by 0.05!)."

Thanks for the GNUe reference, I wasn't aware of that project. It
occurred to me that they might have addressed the re-denomination
problem already, so I subscribed to their list and asked.

It turns out that the section you quote is just a proposal to start
discussion -- they have not decided on a specific solution yet. They
also had not considered currency redomination. At any rate, the first
response I received basically summarized our main proposals :)

The poster (Reinhard Mueller, one of their main people, I think)
leaned toward creating new currencies as redominations occur, but
there will probably be more responses.

Given the commonalities between our two projects, I'm hoping we
will be able to share our work in the future.

thanks,
dave

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Randolph Fritz]

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 always unity.
> 

Unless they're sold by the foot--like lumber, fabric and wire, the
pound--like nails, iron, and sugar, or the gallon--like milk and gasoline.

> 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.

Well, we may...but banks count hundreths of a cent.

I think you are trying to find mathematical perfection in commerce,
and I have some doubt of the enterprise.
-- 
Randolph Fritz
Eugene, Oregon, USA

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

A howto for tranlators

[Yannick LE NY]

I'm creating a howto  for tranlators.
Dave, can you add it in the repertory with the po files?
If you find some grammatical errors , you can correct it.

Yannick


This document explain how to create the po file for each country
by Yannick  LE  NY <[EMAIL PROTECTED]>, the french translator.
V1.0 - 2707

1)Take the file gnucash.pot, edit it with any text editor and save it as 
CODE-COUNTRY.po
(but as a text file only not formatted text)
where the CODE-COUNTRY is a two or more letters for each country.
For example: it for italy, fr for france, de for germany, but fr_BE for people who 
speaks
french in belgium.
For france, the file is fr.po

2)Now at the top of the file, you have this:

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR Free Software Foundation, Inc.
# FIRST AUTHOR , YEAR.

You need to change this with the good information.

For example in the de.po file, we have this:

# Messages in Deutsch für GnuCash
# Copyright (C) 1999 Free Software Foundation, Inc.
# Jan-Uwe Finck <[EMAIL PROTECTED]>, 1999.

3)After this, you need to translate each english strings in your language,
as this:

Before:

#: messages-i18n.c:11
msgid ""
"The GnuCash personal finance manager.\n"
"The GNU way to manage your money!"
msgstr ""

After, the tranlation in the de.po file:

#: messages-i18n.c:11
msgid ""
"The GnuCash personal finance manager.\n"
"The GNU way to manage your money!"
msgstr ""
"GnuCash: Ihr persönlicher Finanzmanager.\n"
"Der GNU-Weg, ihr Geld zu verwalten !"

4)When you have finished to translate all the strings in your language or 
maybe a part, you save it.

5)Now, if you have gettext's package installed, you can compile your po file as this:
msgfmt fr.po --output=./gnucash.mo in command line in /gnucash/po for the file for 
france
and copy it on a redhat 6.1 GPL in /usr/share/locale/fr/LC_MESSAGES and you will have 
your
menus and messages in french.

But this thing work only if the locales are set correctly as this:

In french, with bash:
export LANG=fr_FR

In french, withtcsh:
setenv LANG fr_FR

6)Your po file works, you need to compress your file with gzip.
In command line, type gzip fr.po for the french file and now you have a new file 
compressed:
 fr.po.gz. Take this file and send it by e-mail at [EMAIL PROTECTED]

   

Some remarks, Dave update regularly the po files, and you need to add some translations
in the file or correct some strings.

In the updated po files, you should not have the word fuuzy, else gnucash don't use 
the translated
string.

Two case in the file de.po :

1)You have this:

#: messages-i18n.c:35
#, fuzzy, c-format
msgid ""
"There was an error writing the file\n"
" %s\n"
"\n"
"%s"
msgstr ""
"Es gab einen Fehler beim Öffnen der Datei. \n"
" %s."

You need to correct the translated string and change this text to have
this after and it will work with the translated string.

#: messages-i18n.c:35
#, c-format
msgid ""
"There was an error writing the file\n"
" %s\n"
"\n"
"%s"
msgstr ""
"Es gab einen Fehler beim Öffnen der Datei. \n"
" %s."

2)You have this:

#: messages-i18n.c:251
#, fuzzy
msgid "Show Income/Expense"
msgstr "Einnahmen/Ausgaben anzeigen"

You need to correct the translated string and change this text to have
this after and it will work with the translated string.

#: messages-i18n.c:251
msgid "Show Income/Expense"
msgstr "Einnahmen/Ausgaben anzeigen"





 










 


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Christopher Browne]

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] - 
"What a depressingly stupid machine."  -- Marvin

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

RE: RFC : Correcting some problems in rounding/number handling

[Buddha Buck]

Just replying to one point here...
> (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.

While I can deal with "commodity" as being a more generic term than
"currency" or "stocks", 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 routine?

On the one hand, we are dealing with "dollars" and "dollars" here, not
"apples" and "oranges".  That we are using different granulations doesn't
change that.

On the other hand, we are dealing with "cents" and "sixtyfourths", which
-are- "apples" and "oranges" (or one could make a case for "McIntosh" and
"Granny Smith", I suppose).

Or, going into the world of stocks, are "lots of XYZ Corp" different
"commodities" than "shares of XYZ Corp"?

> --
> [EMAIL PROTECTED] - 
> "What a depressingly stupid machine."  -- Marvin
> 
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: 
> [EMAIL PROTECTED]
> 
> 

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Richard Wackerbarth]

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
> > always unity.
>
> Unless they're sold by the foot--like lumber, fabric and wire, the
> pound--like nails, iron, and sugar, or the gallon--like milk and gasoline.

That is not COUNTING. That is MEASURING and PRICING.

And by the time the transaction gets past the cash register, that measure has 
been converted to a countable quantity.

Besides, "milk" and "sugar" are poor examples. They are seldom sold by the 
gallon (pound) but rather by the "container". And the price of two 
"half-gallon containers of milk" is not the same as that of "one one-gallon 
container of milk". Please go to the store and purchase 1/3 gallon of milk 
for me.

> > 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.
>
> Well, we may...but banks count hundreths of a cent.

Not in my bank account. The balance is ALWAYS an exact multiple of one cent.
Even when I earn $1.5748 in interest each month, those fractional cents NEVER 
accumulate to give me that additional cent.

Besides, if you can find a ledger that records hundreths of a cent, then you 
simply denominate it in that "smallest countable unit".

> I think you are trying to find mathematical perfection in commerce,
> and I have some doubt of the enterprise.

Then you have never dealt with bookkeeping. There is certainly roundoff in 
the computation of what a transaction will be. But the books show the EXACT 
amount recorded for the transaction.

I assure you that EVERY accounting ledger I have seen records COUNTABLE 
amounts of the commodity in question, particularly when that commodity is 
money.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Jon Trowbridge]

On Thu, Jul 06, 2000 at 09:51:39PM -0500, Christopher Browne wrote:
> So I disagree with Jon, in that the "great pain and suffering" is
> a _given_, and equally affects _both_ schemes.

This is (basically) correct: the BG system works well (IMHO) for
things like decimalizations of markets, but doesn't help in the case
of stock splits.

I think that stock splits are, in many ways, a different problem.  The
reason is that splits really affect share *quantities*; split-adjusted
share prices are really an artifice (though a useful and important
one) for analyzing share prices over times.

With splits, you need to be able to reconstruct:
(1) The actual historical share price for any given day.
(2) The split-adjusted historical share price.
(3) How quantities of shares change over time due to splits.

So you are really stuck carrying around a look-up table of dates and
splittings.  Because you need to keep this data around anyway, you are
probably best off storing the non-split-adjusted/"actual" prices of
shares and constructing the split-adjusted prices on the fly.

(In my work I only ever really deal with futures markets, which I find
to be incredibly annoying.  People I've spoken to who deal with
equities say they are much worse...)

-JT

-- 
GNU/Linux: Free your mind and your OS will follow.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Hendrik Boom]

> 
> 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...
> --

When I owe someone 12 1/2 shares of some security on a futures contract
and the exchange redenominates to decimal, he is likely to accept
12.5 shares instead.  It really is the same commodity.

-- hendrik.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[John Hasler]

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 hundredweight (my neighbors are presently
complaining about the price).  Not sure about sugar.

> There is certainly roundoff in the computation of what a transaction will
> be. But the books show the EXACT amount recorded for the transaction.

Yes.  A bookkeeping system records actual transactions, not the product of
price and quantity.  Buy one share of Gnucash, Inc at 9-7/8 and your broker
will bill you something like $9.88 plus $11.00 commission, and that's what
you need to record.

I have inventoried commodities that were measured in fractions, but never
to more than two decimal places.

Now I get to deal with the fact that my coop accepts corn into storage by
the bushel and returns it to me by the pound.  Sort of like having your
bank report deposits in old pounds and withdrawals in new.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[John Hasler]

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 record a transaction in
"1/64 Dollars".
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: shares and fonds

[Bob Stanfield]

On Fri, 7 Jul 2000, Robert Graham Merkel wrote:

> Poldi Winkler writes:
> 
..
> 
> Better graphing capabilities are on the way.  In fact, over the next
> couple of days I'm going to give an outline of what I think the basic
> graphing capabilities we need are, and comments on that proposal would
> be appreciated.
> 
> 
> Robert Merkel[EMAIL PROTECTED]
> 
I have put together a program for my own consumption that
tracks and graphs my portfolio. Through daily downloads I have
loaded my MySQL database with a history of the portfolio.

One feature I use is the tracking a comparison between two+ 
stocks and/or a stock index with the the computation of the Beta and 
covariance. (The stock prices are normalized for the comparison)

A second important graph is the tracking of my portfolio 
asset allocation. This is table driven. This allows me the discipline
of re-balancing the portfolio between growth/mature stocks and fixed 
income instruments as the market bounces off the wall.

A third chart I am working on is an ad hoc chart/report based 
on MySQL "select ..." statements maintained in a separate reports file.
This is not user friendly, but defines a functional need.

BTW, my data is stored on a MySQL database mostly to give
me data integrity discipline that my broker does not seem to recognize
their clients might know about and want.

Bob Stanfield
29 Ledge Lane
Pipersville, PA 18947
Voice 610-294-9884   
FAX   610-294-8119 



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Richard Wackerbarth]

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 hundredweight (my neighbors are presently
> complaining about the price).  Not sure about sugar.

Oh, at THAT level :) I was describing the retail consumer transaction.
Actually, it isn't necessarily sold by the hundredweight. It make be PRICED 
by the hundredweight and sold by the quarter pound.

The same thing is true of "futures" and bonds. If I recall correctly, 
'beans are sold by the freight car load but priced by the bushel.

> > There is certainly roundoff in the computation of what a transaction will
> > be. But the books show the EXACT amount recorded for the transaction.
>
> Yes.  A bookkeeping system records actual transactions, not the product of
> price and quantity.  Buy one share of Gnucash, Inc at 9-7/8 and your broker
> will bill you something like $9.88 plus $11.00 commission, and that's what
> you need to record.

> I have inventoried commodities that were measured in fractions, but never
> to more than two decimal places.

But they were inventoried in a common unit if they are in the same inventory.
You would not have both 3 1/8 bushels and 4.02 bushels on the same ledger.
At some point, they would be redemoninated to a common unit, perhaps 3.12 and 
4.02.

> Now I get to deal with the fact that my coop accepts corn into storage by
> the bushel and returns it to me by the pound.  Sort of like having your
> bank report deposits in old pounds and withdrawals in new.

But I am sure that they do the exchange at the time of entry or withdrawal.
If you ask for your balance in storage, it will be either so many bushels or 
so many pounds.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Jon Trowbridge]

On Fri, Jul 07, 2000 at 11:56:33AM -0500, Richard Wackerbarth wrote:
> 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 hundredweight (my neighbors are presently
> > complaining about the price).  Not sure about sugar.
> 
> Oh, at THAT level :) I was describing the retail consumer transaction.
> Actually, it isn't necessarily sold by the hundredweight. It make be PRICED 
> by the hundredweight and sold by the quarter pound.
> 
> The same thing is true of "futures" and bonds. If I recall correctly, 
> 'beans are sold by the freight car load but priced by the bushel.

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.  (The minimum price change on the exchange is 1/4 of a cent,
but the prices are all quoted in eighths.  Go figure.)

So if you are long one soybean future and the price goes up 1/4 of a
cent per bushel, you are up $12.50 ($12.50 = 1250 cents = 5000 / 4).

Thus rather than being able to calculate P&L with

(# of contracts) x (price change)

you need to compute

(# of contracts) x (price change) x (conversion factor).

Except, of course, for Australian Bond Futures.  Don't even get me
started on those...

Of course, with futures the value of the instrument doesn't change per
se; instead, your account gets "marked to market" daily reflecting the
profit/loss you would face associated with delivery of the contracted
goods due to the difference between the contracts price and the
current market price.  Another strange bit of accounting that it would
be nice to be able to handle.

-JT

-- 
GNU/Linux: Free your mind and your OS will follow.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Richard Wackerbarth]

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 :-)

> Of course, with futures the value of the instrument doesn't change per
> se;

I think that the "value" does change. The "amount" remains constant, but the 
exchange rate varies.

> instead, your account gets "marked to market" daily reflecting the
> profit/loss you would face associated with delivery of the contracted
> goods due to the difference between the contracts price and the
> current market price.  Another strange bit of accounting that it would
> be nice to be able to handle.

I guess I don't understand how this is different from my stock portfolio 
except that you subtract the underlying delivery price and only look at the 
"profit". I think that it has exactly the same components as a margin 
purchase of stock.

Ignoring commission, etc. If I create a futures contract, I am saying that, 
at the prescribed date, I will exchange a load of beans for this contract 
plus a designated sum of cash. Therefore the contract is the combination of 
two sub accounts. The first of the load of beans and the second is the 
obligation to pay the cash. If the value of the load of beans is equal to the 
delivery price, the contract is even. If the beans are worth more, then the 
contract is worth more. This is the same as my brokerage account. When I tell 
the broker to buy a share of RedHat, I gain a share of RedHat and take on the 
obligation to pay the delivery price.

The only difference is that you structure your reporting a little differently.
I typically pay off the margin and actually take delivery of the RedHat.
(Maybe that's why my closet is full of Millinery :)
You, on the other hand, never expect to pay the margin or have the beans 
dumped in your yard. As a result, you look at the cost to get out of the 
agreement. But this is that same thing that I do if I am considering selling 
my stock. I consider the difference in the cost to get in and how much I can 
receive when I get out.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[John Hasler]

Richard Wackerbarth writes:
> But they were inventoried in a common unit if they are in the same
> inventory.  You would not have both 3 1/8 bushels and 4.02 bushels on the
> same ledger.

I've never had to inventory anything using other than decimal fractions,
and never to more than two decimal places.  The pricing is sometimes in
negative powers of two, but when the bill comes everything always works out
to dollars and cents and units and sometimes hundredths of a unit.

> If you ask for your balance in storage, it will be either so many bushels
> or so many pounds.

Actually, the balance is stated in "units".  I'm supposed to know that the
unit is 32 pound bushels for feed oats and 56 pound bushels for feed corn.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Randolph Fritz]

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 
> been converted to a countable quantity.
> 

hunh?  I mean, the last time I bought half a yard of fabric, the
cutter wrote half a yard on a slip, computed a price, and I took that
to the cash register.

> Besides, "milk" and "sugar" are poor examples. They are seldom sold by the 
> gallon (pound) but rather by the "container". And the price of two 
> "half-gallon containers of milk" is not the same as that of "one one-gallon 
> container of milk". Please go to the store and purchase 1/3 gallon of milk 
> for me.

Only at the retail level--gnucash is supposed to work for business,
too, no?

> 
> 
> Not in my bank account. The balance is ALWAYS an exact multiple of one cent.
> Even when I earn $1.5748 in interest each month, those fractional cents NEVER 
> accumulate to give me that additional cent.
> 

According to my banking consultant friend, the major US banks he
worked for (Chase, Manufacturers Hanover, Citibank) did all their
dollar computations to four decimals of precision and rounded to two
for output; he mentioned GM as one of the customers whose accounts
this applied to.  Has the practice changed, then?

> Besides, if you can find a ledger that records hundreths of a cent, then you 
> simply denominate it in that "smallest countable unit".

Perhaps then for money four decimal points of precision (if rounding
after every computation is to the nearest 1/10,000th) is sufficient?

-- 
Randolph Fritz
Eugene, Oregon, USA

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Jon Trowbridge]

On Fri, Jul 07, 2000 at 01:03:10PM -0500, Richard Wackerbarth wrote:
> On Fri, 07 Jul 2000, Jon Trowbridge wrote:
> 
> > Of course, with futures the value of the instrument doesn't change per
> > se;
> 
> I think that the "value" does change. The "amount" remains constant, but the 
> exchange rate varies.
> 
> > instead, your account gets "marked to market" daily reflecting the
> > profit/loss you would face associated with delivery of the contracted
> > goods due to the difference between the contracts price and the
> > current market price.  Another strange bit of accounting that it would
> > be nice to be able to handle.
> 
> I guess I don't understand how this is different from my stock portfolio 
> except that you subtract the underlying delivery price and only look at the 
> "profit". I think that it has exactly the same components as a margin 
> purchase of stock.

>From an accounting standpoint, maybe they are the same.  (I'm an
accounting primitive.)  However, they are technically quite different.

> Ignoring commission, etc. If I create a futures contract, I am saying that, 
> at the prescribed date, I will exchange a load of beans for this contract 
> plus a designated sum of cash. Therefore the contract is the combination of 
> two sub accounts. The first of the load of beans and the second is the 
> obligation to pay the cash. If the value of the load of beans is equal to the 
> delivery price, the contract is even. If the beans are worth more, then the 
> contract is worth more. This is the same as my brokerage account. When I tell 
> the broker to buy a share of RedHat, I gain a share of RedHat and take on the 
> obligation to pay the delivery price.
> The only difference is that you structure your reporting a little
> differently.

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 actually take delivery of the RedHat.

Remember, "margin" in futures trading means something totally
different than "margin" in stock trading.  Futures margin is a
performance bond, meant to guarantee that you will uphold your side of
the contract.

Stock has intrinsic value, value and you are exchanging one thing of
value (money) for another (stock) at the time of purchase.

Soybeans (and most other physical commodities) are not cash settled:
at the delivery date, beans are swapped for dollars at the price
agreeds on when the contract was entered into.  In the meantime, your
futures account (as well as the account of your counterparty in the
contract) has already been adjusted to account for the changes between
the original price and the current market price.

Another tidbit: because futures contracts have no intrinsic value, it
is basically impossible to define the ROI on individual futures
trades.  Fun, huh?

-JT

-- 
GNU/Linux: Free your mind and your OS will follow.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Richard Wackerbarth]

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 been converted to a countable quantity.
>
> hunh?  I mean, the last time I bought half a yard of fabric, the
> cutter wrote half a yard on a slip, computed a price, and I took that
> to the cash register.

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.

Particularly in a business such as dry goods, the amount that you actually 
receive does not match the amount for which you were charged. The merchant 
has figured this waste into the price he charges.

For such a merchant, it is far simpler to estimate the amount sold until he 
takes a physical inventory of what remains and makes the adjustment necessary 
to bring the inventory into balance.

> > Besides, "milk" and "sugar" are poor examples. They are seldom sold by
> > the gallon (pound) but rather by the "container". And the price of two
> > "half-gallon containers of milk" is not the same as that of "one
> > one-gallon container of milk". Please go to the store and purchase 1/3
> > gallon of milk for me.
>
> Only at the retail level--gnucash is supposed to work for business,
> too, no?

And, as Jon points out, that accounting is done in an even different set of 
"units".

> > Not in my bank account. The balance is ALWAYS an exact multiple of one
> > cent. Even when I earn $1.5748 in interest each month, those fractional
> > cents NEVER accumulate to give me that additional cent.
>
> According to my banking consultant friend, the major US banks he
> worked for (Chase, Manufacturers Hanover, Citibank) did all their
> dollar computations

Computations are intermediate results which are never entered in the ledger.

> to four decimals of precision and rounded to two for output;

It is only this rounded result that gets posted to the ledger.

> he mentioned GM as one of the customers whose accounts
> this applied to.  Has the practice changed, then?

I suspect that even GM received all charges and payments in cents without any 
fractions.

> > Besides, if you can find a ledger that records hundreths of a cent, then
> > you simply denominate it in that "smallest countable unit".

> Perhaps then for money four decimal points of precision (if rounding
> after every computation is to the nearest 1/10,000th) is sufficient?

We should make no such assumption. Each ledger should be allowed to be 
expressed in whatever units are used. However, for convenience, we should 
offer the most common unit for the particular commodity as the default.

For example, before decimalization, it would have been 1/240 Pound Sterling.
I think that someone indicated that it is 0.05 Swiss Franc, etc.



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Richard Wackerbarth]

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 actually take delivery of the RedHat.
>
> Remember, "margin" in futures trading means something totally
> different than "margin" in stock trading.  Futures margin is a
> performance bond, meant to guarantee that you will uphold your side of
> the contract.

Is it a bond (as in pledging of assets wherein you still retain the earnings 
thereon) or is it a partial payment (as an escrow account).


> Stock has intrinsic value, value and you are exchanging one thing of
> value (money) for another (stock) at the time of purchase.

Nope. It looks like a sheet of paper to me. :-) Often its just an entry in 
somebody's books.

The Soybean contract is no different.

Both of them are contracts giving the owner various rights and obligations.

Owning a few shares of RedHat gives me the right to a pro-rata share of any 
distribution or liquidation and the right to cast a pro-rata vote on certain 
corporate decisions. It doesn't give me the individual right to physically 
liquidate their inventory and walk out with my 3 copy share.

> Another tidbit: because futures contracts have no intrinsic value, it
> is basically impossible to define the ROI on individual futures
> trades.  Fun, huh?

I disagree. ROI and IRR are well defined concepts that apply equally to these 
contracts. The inputs are the amounts that you surrender and the outputs are 
the amounts that you receive in return. If you are required to give up $1000 
because it is pledged to the contract, that is your investment. If you later 
sell the contract for a profit of $12.50, that $12.50 and the original $1000 
are the returns.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

RE: RFC : Correcting some problems in rounding/number handling

[Richard Wackerbarth]

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 routine?
>
> On the one hand, we are dealing with "dollars" and "dollars" here, not
> "apples" and "oranges".  That we are using different granulations doesn't
> change that.
>
> On the other hand, we are dealing with "cents" and "sixtyfourths", which
> -are- "apples" and "oranges" (or one could make a case for "McIntosh" and
> "Granny Smith", I suppose).

I think that we MUST take the "apples" and "oranges" approach.

Otherwise, what is the balance in the "fruit basket"?

Receive $3/64
Receive $0.02
Spend $1/64

What is the balance?

It's value is a little more than $3/64
and a little more than $0.05

But we must be exact.
The balance is exactly $0.02 + $2/64 which we might print as $0.02 + $1/32

It is also of the same exact value as $0.05125
But those are "bananas".

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Jon Trowbridge]

On Fri, Jul 07, 2000 at 02:40:29PM -0500, Richard Wackerbarth wrote:
> On Fri, 07 Jul 2000, Jon Trowbridge wrote:
> > Remember, "margin" in futures trading means something totally
> > different than "margin" in stock trading.  Futures margin is a
> > performance bond, meant to guarantee that you will uphold your side of
> > the contract.
> 
> Is it a bond (as in pledging of assets wherein you still retain the earnings 
> thereon) or is it a partial payment (as an escrow account).

It is in fact a bond.  You earn interest on all of the money in a
futures account, including that which goes towards meeting any margin
requirements.

> > Stock has intrinsic value, value and you are exchanging one thing of
> > value (money) for another (stock) at the time of purchase.
> 
> Nope. It looks like a sheet of paper to me. :-) Often its just an entry in 
> somebody's books.
> 
> The Soybean contract is no different.
> 
> Both of them are contracts giving the owner various rights and obligations.
> 
> Owning a few shares of RedHat gives me the right to a pro-rata share of any 
> distribution or liquidation and the right to cast a pro-rata vote on certain 
> corporate decisions. It doesn't give me the individual right to physically 
> liquidate their inventory and walk out with my 3 copy share.

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 are
legally bound to perform a specific action at a specific time.  Now
after you perform that action, you might be the proud owner of, say,
1000 barrels of crude oil. 

If you offset your futures position before the delivery date, you are
freed of that legal obligation.  You still own nothing.  You never
owned anything.  However, you still can have made or lost some money.

> > Another tidbit: because futures contracts have no intrinsic value, it
> > is basically impossible to define the ROI on individual futures
> > trades.  Fun, huh?
> 
> I disagree. ROI and IRR are well defined concepts that apply equally to these 
> contracts. The inputs are the amounts that you surrender and the outputs are 
> the amounts that you receive in return.

Ah, but you never had to surrender anything, now did you?

You can argue that if the margin is $1000, you were forced to
"surrender" that $1000 and hence it should be the denominator in any
calculation of returns.  (This is the method favored by con men who
peddle dubious futures investments in gold or foreign exchange in late
night infomercials, since it can produce *extremely* high ROI numbers.)

There are lots of problem with this.  For example, your margin
requirements can change over time, because of a change in policy by
the exchange or your broker --- should that change your ROI?  And if
you lose money, more margin needs to be posted: you could lose $2000
in a trade with a margin requirement of $1000: was your ROI -200%?

-JT

-- 
GNU/Linux: Free your mind and your OS will follow.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Richard Wackerbarth]

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 record a transaction in
> "1/64 Dollars".

That is correct. I think folks may be confusing "commodities" and "prices".
They are fundamentally different.
With a commodity (something tangible that you can actually see and measure) 
you are only concerned with "how much" and "of what". For example, "two" 
"bushels of wheat". Let's call that pair a "pile". Now "piles" come in 
various "sizes" and are of various materials (corn, beans, money), the 
"commodity".

When you talk about a "price", you are referring to a rate of exchange.
A pile of this can be exchanged for a different sized pile of that.
We need to know the size of this pile and the size of that pile as well as 
what commodity this is and that is. 

A pile of 199 pennies can be exchanged for a pile of 64 lemon drops.

Now, in addition to the above mentioned properties, we also need to know the 
smallest recognizable change in the size of a pile or price.

Since we require that we be able to represent that amount exactly, we must 
linearly map the "size" onto the rational numbers. This implies that we must 
include the exact reciprocal of this smallest unit in the scaling factor.

Now, for convenience, it is useful to make the scaling factor either just 
this reciprocal or the radix multiple of it (unless the radix is odd)

The denominator of an amount because it is always a known constant. If we 
apply a uniform policy in assigning scaling factors, it will be a global 
constant. We need the scaling factor because it is the "exchange rate" used 
to convert to printable units.

However, this is a common property of every value in this denomination and, 
like the denominator, need not be stored with the individual values.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Richard Wackerbarth]

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 are
> legally bound to perform a specific action at a specific time.  Now
> after you perform that action, you might be the proud owner of, say,
> 1000 barrels of crude oil.

I disagree. You own the beans and are required to accept delivery and make 
payment upon that delivery.

That is no different than my RedHat stock. If I "buy" today, I am actually 
contracting to take delivery on next Thursday.

> If you offset your futures position before the delivery date, you are
> freed of that legal obligation.

And similarly for the stock.

> Ah, but you never had to surrender anything, now did you?

Yes. At a minimum, I surrendered the right to place my "margin" in another 
investment. Therefore I can argue that it is a part of the contract and the 
interest earned thereon is a part of the investment return.

At the other extreme, I can argue that you have "invested" the total amount 
that you have "at risk", namely the delivery price, and financed most of that 
amount just as you would in the margin purchase of a security.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Richard Wackerbarth]

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...
> > --
>
> When I owe someone 12 1/2 shares of some security on a futures contract
> and the exchange redenominates to decimal, he is likely to accept
> 12.5 shares instead.  It really is the same commodity.

No, you are exchanging 25 half shares for 125 tenth shares.

What if the amount were 3/64 of a share? How many hundreth shares do you want?


PS: The shares are worth One Billion Dollars US

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Randolph Fritz]

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.
> 
> Particularly in a business such as dry goods, the amount that you actually 
> receive does not match the amount for which you were charged. The merchant 
> has figured this waste into the price he charges.
> 

I just bought some velcro ribbon...trust me, the amount I actually
received matches the amount I bought to within at most 1/4".  If I was
buying wide vellum from an art supply shop, it would be within 1/16".

>
> For such a merchant, it is far simpler to estimate the amount sold until he 
> takes a physical inventory of what remains and makes the adjustment necessary 
> to bring the inventory into balance.
> 

Yes, yes.  However the receipt I have, which is the merchants's original
transaction document, is written in yards.  This merchant is measuring
(rational numbers) rather than counting (cardinal numbers), and
keeping track of cash at their register.

One of the ways in which the widespread availability of computers
transforms traditional bookkeeping practice is that jobs which were
previously back office are now done in real time at the cash register.
This, to me, suggests that gnucash might be more useful to these
merchants if it accomodated the way the merchants do business, rather
than requiring the merchant to do conversions into a traditional
accounting form.  

I wonder...do you think that the ability to compute an approximate
inventory at any time would be of value to, say, a small fabric store?
It seems to me it would be helpful in maintaining inventory.

> >
> > According to my banking consultant friend, the major US banks he
> > worked for (Chase, Manufacturers Hanover, Citibank) did all their
> > dollar computations
> 
> Computations are intermediate results which are never entered in the ledger.
> 
> > to four decimals of precision and rounded to two for output;
> 
> It is only this rounded result that gets posted to the ledger.
> 

My consultant confirms this.  I stand corrected.

> 
> > Perhaps then for money four decimal points of precision (if rounding
> > after every computation is to the nearest 1/10,000th) is sufficient?
> 
> We should make no such assumption.
> 

Why not?  Seriously, if the big banks do it, does gnucash need to do
more?  Compute with four decimal places, store two, and stop agonizing
over it.  

>
> For example, before decimalization, it would have been 1/240 Pound Sterling.
> I think that someone indicated that it is 0.05 Swiss Franc, etc.
> 

H...I wonder how international banks handle the problem.

-- 
Randolph Fritz
Eugene, Oregon, USA

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Richard Wackerbarth]

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.
> >
> > Particularly in a business such as dry goods, the amount that you
> > actually receive does not match the amount for which you were charged.
> > The merchant has figured this waste into the price he charges.
>
> I just bought some velcro ribbon...trust me, the amount I actually
> received matches the amount I bought to within at most 1/4".  If I was
> buying wide vellum from an art supply shop, it would be within 1/16".
And gold chain even closer.

So what? Each item has its own "smallest unit of measure" and there is some 
approximation made when the larger inventory is partitioned into the portion 
that you purchased and that which you did not.

> Yes, yes.  However the receipt I have, which is the merchants's original
> transaction document, is written in yards.  This merchant is measuring
> (rational numbers) rather than counting (cardinal numbers), and
> keeping track of cash at their register.

I don't think so. He measured to do the cutting, but counted for the sale.
Did you have the option of purchasing 1 1/2 yards? Probably. 1 1/8 yards? 
Perhaps. 1 1/144 yards? I doubt it.

Just because we display "1 1/3 yards" doesn't mean that we cannot store the 
transaction as "48 inches"

> One of the ways in which the widespread availability of computers
> transforms traditional bookkeeping practice is that jobs which were
> previously back office are now done in real time at the cash register.
> This, to me, suggests that gnucash might be more useful to these
> merchants if it accomodated the way the merchants do business, rather
> than requiring the merchant to do conversions into a traditional
> accounting form.

See above. Input and Output do not have to be in the same units as storage.
If I were building a cash register for the dry goods store, I would certainly 
include keys for 1/2, 1/3, 3/4, etc. Or at least have some input convention 
that allowed it.

> Why not?  Seriously, if the big banks do it, does gnucash need to do
> more?  Compute with four decimal places, store two, and stop agonizing
> over it.

But "computing with four decimal places" MAY be harder than doing it more 
accurately. The banks are probably doing the calculations in BCD. Although we 
can, I don't think that is the likely implementation.

Remember, if we design things properly, we can change the internal 
representation without having any real effect on the bulk of the system.

> > For example, before decimalization, it would have been 1/240 Pound
> > Sterling. I think that someone indicated that it is 0.05 Swiss Franc,
> > etc.
>
> H...I wonder how international banks handle the problem.

Probably in either BCD or, in the case of the old British Currency, Pounds, 
Shillings, Pence.

Remember that the requirement is only that I be able to handle the amounts.

Most banking applications are defined in terms of the character fields of the 
I/O record. They rarely use binary because the I/O conversion dominates the 
math.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: shares and fonds

[Robert Graham Merkel]

Bob Stanfield writes:

 >  I have put together a program for my own consumption that
 > tracks and graphs my portfolio. Through daily downloads I have
 > loaded my MySQL database with a history of the portfolio.
 > 
 >  One feature I use is the tracking a comparison between two+ 
 > stocks and/or a stock index with the the computation of the Beta and 
 > covariance. (The stock prices are normalized for the comparison)
 > 

Excuse my ignorance here - my stats is a little rusty (and was only
fairly limited to begin with).  Could you please explain what these
statistics mean (at a high level, don't worry about the nitty-gritty
of computing them), and what they help you do?  I'm guessing that
covarience is related to how accurately the value of one stock/index
predicts the value of another, but beyond that you've lost me.  

 >  A second important graph is the tracking of my portfolio 
 > asset allocation. This is table driven. This allows me the discipline
 > of re-balancing the portfolio between growth/mature stocks and fixed 
 > income instruments as the market bounces off the wall.
 > 
Yep, this is on my list.

 >  A third chart I am working on is an ad hoc chart/report based 
 > on MySQL "select ..." statements maintained in a separate reports file.
 > This is not user friendly, but defines a functional need.

So this is a hack you provide to let you graph just about anything in,
as you said, an "ad hoc" manner?  We provide similar facilities.



 >  BTW, my data is stored on a MySQL database mostly to give
 > me data integrity discipline that my broker does not seem to recognize
 > their clients might know about and want.
 
While we're not using a database yet, it's a medium-to-long term goal.


Robert Merkel  [EMAIL PROTECTED]



--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: RFC : Correcting some problems in rounding/number handling

[Randolph Fritz]

On Fri, Jul 07, 2000 at 05:12:17PM -0500, Richard Wackerbarth wrote:
> 
> But "computing with four decimal places" MAY be harder than doing it more 
> accurately. The banks are probably doing the calculations in BCD. Although we 
> can, I don't think that is the likely implementation.
> 
> Remember, if we design things properly, we can change the internal 
> representation without having any real effect on the bulk of the system.
> 

In bookkeeping practice representation and mensuration are
intertwined.  Historically, business computing has dealt with this
problem by the simple expedient of using BCD, which also has the
advantage of being understood by bookkeepers who program in COBOL.

In principle this can also be dealt with by sub-classing the rational
numbers, however, subclasses proliferate.  At the very least one is
likely to end up with with a fixed-precision decimal subclass that
looks very much like BCD--Java's BigDecimal or SQL's NUMBER, in other
words.  It's going to take considerable effort to make rounding and
overflow work in the way that bookkeepers and customers expect, and I
believe that meeting those expectations is important--if nothing else
it makes for more accurate and simpler export and import of data.

> And gold chain even closer.

:) To the gram, I believe.  Or even the tenth thereof.

> 
> So what? Each item has its own "smallest unit of measure" and there is some 
> approximation made when the larger inventory is partitioned into the portion 
> that you purchased and that which you did not.
> 
> [...]
> 
> Just because we display "1 1/3 yards" doesn't mean that we cannot store the 
> transaction as "48 inches"
> 

Sure.  As long as the merchant sees that they are measuring and
rounding.

> 
> See above. Input and Output do not have to be in the same units as storage.
> If I were building a cash register for the dry goods store, I would certainly 
> include keys for 1/2, 1/3, 3/4, etc. Or at least have some input convention 
> that allowed it.
> 

unh-hunh.  I found out that those numbers were once considered
important enough to have a special name; they are called aliquot
parts, which I think is a really cool-sounding, and otherwise
obsolete, word. :)

> 
> Remember that the requirement is only that I be able to handle the amounts.
> 

Um, don't you mean the program be able to handle the amounts?

> Most banking applications are defined in terms of the character fields of the 
> I/O record. They rarely use binary because the I/O conversion dominates the 
> math.

Isn't this more of a historical consideration?  Since the S/370
family, at least, conversion has been relatively cheap.  However, the
accounting/bookkeeping expectation of decimal arithmetic remains.

-- 
Randolph Fritz
Eugene, Oregon, USA

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

what do we want to graph?

[Robert Graham Merkel]

OK, now that guppi is starting to move along, we might like to start
thinking about what kinds of graphs we want.  Again, I've dissected
Quicken's reporting capabilities, and am presenting a list of reports
that we might consider implementing ourselves.

Quicken's charting features are basically noninteractive.  Its chart
has a toolbar with a customize button up top, which brings up a dialog
box.  All the graphs are rendered in fake-3D, but all the graphs are
either bar, stacked bar, line or pie graphs.  Simple stuff, but nice
and clear.  The good news is that for a home-finance package this
level of graphical capability is apparently state-of-the-art.

If we want eye candy, if guppi ends up supporting true 3D graphing we could
use some of those :)

Income and Expense graphs:

Quicken supports two sorts of these - bar graphs by period, and a pie
chart summarizing either income sources and expenses by category.  It
normally displays the two simultaneously, but there is no great
benefit from it IMHO.  You can select which categories and accounts
are included.

I think we can do better - I think we could have the option to have
stacked bars so that major subgroups (categories by a meta tag, for
instance) could be viewed in the barchart.  Additionally, we could
should be able to display multiple pie charts for regular time
intervals.  As well, when selecting by account, we should be able to
specify a depth to which accounts are done individually - below that,
they should be consolidated for presentation.  However, it would be cool if 
we could expand or collapse account groups from the graph display.

Budget graphs:

This of course depends on how the budgeting system develops (what are
your plans here, Dave?)

However, Quicken's idea is simply to present income (categorized) 
over the budget period vs. actual, and a third bar showing the dollar difference, 
and a similar graph for expenses.

There are a couple of issues (which really also apply to the budget
report too) - what do we do when the budget is specified for a
different time scale to the report?  My view would be to simply
rescale the budget figure.  Similarly, what do we do for subaccounts
and parent accounts for budgeting?  For flexibility, higher-level
accounts should be allowed to contain overall budget figures, and by
default budget graphs should be displayed down to the level at which
they are specified.  If people expand further, you simply divide the
budget figure by the number of categories as a "guess" result, and
indicate that it's not a specified figure by using a different colour.
Of course, budget views should also be able to be consolidated by
fields other than "account".  Above and below budget figures should be
able to be presented as percentage figures, as well as by absolute
values.

Another view that might be useful is two pie charts which show the
budgeted and actual proportions of income/expenses.

Net worth graph:

The only way that a graph can show anything useful about net worth is
to show its growth (hopefully) over time.  So I would propose a bar -
or more likely a line graph which shows assets, liabilities, and net
worth over a period.  We could just take data points at discrete
intervals, but there isn't any reason why we couldn't (optionally) use 
more intervals and (optionally) some averaging and smoothing techniques.


Portfolio Balance:

This is a simple pie chart showing where investments are concentrated.
We obviously want something like this.  We would want to be able to
subdivide by investment type (stocks/mutual funds/property/cash etc.),
as well as being able to subdivide further (ie be able to distinguish
by meta tag as well), and also display weightings by individual
stock/fund etc.

Also useful would be a sequence of pie charts showing how weightings
have changed over time.

Investment performance:

Again, Quicken displays two graphs simultaneously here, and I'm not
sure of the usefulness of it.  They have a stacked bar graph showing
the value of various asset classes in your portfolio on a monthly
basis, and a bar graph showing the internal rate of return for each
security, with a line showing the average IRR.

I've already had one suggestion of an additional piece of investment
analysis from Bob Stanfield (see a previous mail), but I'd like more
suggestions on this!

In summary, there's nothing here that we can't easily duplicate - and
indeed, the account hierachy we have, and the more flexible
information we will have with the new engine and file format, we
should be able to improve on this set considerably.  From my
perspective, the major challenge I think we face is designing some
options to be able to select which accounts to include, and whether
they should be consolidated - another version of the same issue as
report design.  I guess I'll have to spend some time
playing with the Gtk+ tree widget, and see what I can come up with.

What else do people want from graphs in gnucash?

-