Re: what do we want to graph?

[Robert Graham Merkel]

Bob Stanfield writes:

 > 
 > > 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.
 > >
 >  
 >  There are two standards the 50 and 200 day moving average. Is there a reason
 > why we couldn't make that a user option?
 > 
None at all.


 > > 
 > > 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.
 > > 
 >  I find I like line graphs whenever there is historical data.
 > This should be user optional.

OK.

 >  
 > > 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.
 > 
 >  Again I use line graphs. When comparing a stock(s) and an index
 > I normalize by the initial prices. This is useful to see how a General 
 > Motors follows swings in the price of crude oil, for example! There are
 > few of us old dinosaurs who like information. If I want art, I'll go to a 
 > museum.
 
Believe me, I want our graphs to be informative.  If "pretty" and
"informative" clash, I'd go for "informative" every time.  Where
practical, we should provide choice.  And most of the time, there is
no reason for there to be a clash between attractive and functional.  

I don't know whether you got my mail before about your statistical
stock comparison - you mentioned two statistics called the "Beta" and
the "covarience".  Could you provide a pointer to how to calculate
these, and explain what they mean and how you use them?



Robert Merkel  [EMAIL PROTECTED]






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

Re: denominators

[Hendrik Boom]

> 
> Unfortunately, it is sometimes difficult to distinguish humor from lack of 
> understanding.
> 

There may be good reason for this difficulty.  I suspect humour may
have eveolved as a social mechanism by which those who do not understand
can express same without embarassment.

I suspect this thread has now wandered completely off topic.

-- hendrik.


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

Re: Edited fields in a transaction

[Dave Peticolas]

Terry Boldt writes:
> 
> I won'tt belabor this any more in case it really is a bug and has been
> corrected.

It really is a bug, though one that I think has been corrected.
At least, I cannot duplicate it and I'm sure we would be seeing
more bug reports if it was in the current stable version.

GnuCash does not save old and new versions of a transaction in the
database, so this is really a GUI bug.


> I am using 1.3.100 running under Mandrake 7.01 (Air). I am waiting for the 1.
> series to update - I live dangerously :-)

If you want to live really dangerously, you could always use CVS and
have the most up to date version. If you want to stick with numbered
releases, I plan on releasing 1.5.0 shortly after I release 1.4.2
sometime this weekend.

thanks,
dave

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

Edited fields in a transaction

[Terry Boldt]

I have been experiencing something that I would call a bug - but then maybe it
isn't. :-)

If I edit a field in an old transaction - it hasn't been reconciled yet, but
that's not the problem. As long as the transaction being edited/changed is the
"current" transaction everything shows okay. As soon as I "record" the
transaction and make another transaction the "current" transaction, the edited
fields revert to their previous contents. If I click onto the transaction again
to make the transaction "current" the changes magically re-appear, but ONLY
while the transaction is the current transaction. Otherwise the original
un-edited contents are displayed. 

This is annoying to say the least. Especially when I "duplicate" a transaction
and then edit the fields. The date and money fields retain the "new" values,
but all the other fields always revert to their original contents whenever the
transaction is not the "current" transaction. This becomes even more annoying,
because I am then never sure just what the transaction really is.

This behaviour is displayed across invocations of gnucash. If I save and exit
and then invoke gnucash, the same behaviour is displayed on the transactions
edited in the previous invocation.

Is gnucash saving both the un-edited and edited contents of fields in a
transaction?? Why?? Do some auditors want both contents?? For changed
transactions this may make sense. But if I duplicate a transaction and then
change fields, I really don't want the old contents since they don't really
reflect what the new, duplicated transaction is for. If duplicated transactions
can only display the original contents of the fields (except when the
transaction is the "current" transaction) then duplicating a transaction has
very limited value (for me at least). 

I won'tt belabor this any more in case it really is a bug and has been
corrected.

I am using 1.3.100 running under Mandrake 7.01 (Air). I am waiting for the 1.5
series to update - I live dangerously :-)

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

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

[Richard Wackerbarth]

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 back. Each policy owner got shares
> based on their policy. I got a whopping 16.xxx shares. They gave everybody
> the option of immediately selling through them. I have kept the shares,
> i.e., an entry in their books, just for the heck of it. Selling 16.xxx
> shares just wasn't worth the time and effort to return a stamped,
> self-addressed envelop. Every year I get a dividend of 0. cents (thats
> the number of decimal places they carry in their correspondence and I
> assume their books). So every year they buy me another 0.xxx shares. I now
> have the grand total of 33.166 shares (they split two for 1).
>
> I find it amusing (that's the main reason I haven't bothered trying to
> sell) to every year get this statement with a dividend of so many cents
> carried out to the fourth decimal point. That's 1/10,000 of a cent - they
> really do keep track of it that close (I'm assuming - otherwise they are
> wasting a lot of paper and postage telling their shareholders they do).
>
> So in order for gnucash to keep track of this stock for me, it would have
> to keep track of stock to within 1/1,000 of a stock unit and money (US) to
> within 1/10,000 of a cent. If that isn't reasonable I can understand - I'll
> just keep letting the insurance company keep it on their books and track it
> for me :-)

There is certainly no problem to keeping track of those 1/1000th shares.
By your above statement, you now have 33,166 of them.

As for the cash side, it gets more complicated. What does the 1099-DIV report?
Since the stock cannot EXACTLY cost the amount of the dividend, what do they 
do with the residual? If they discard it after computing the number of 
thousandth-shares, I would ignore the supposed precision and simply record 
the cents.

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

Re: what do we want to graph?

[Dave Peticolas]

Robert Graham Merkel writes:
> Budget graphs:
> 
> This of course depends on how the budgeting system develops (what are
> your plans here, Dave?)

The budgeting system is actually Bryan Larsen's work, and I think he
wants to continue working there. I presume we will have graphs of the
information that comes up in the different budget reports now. In my
Quicken days, I liked historical bar graphs with side-by-side columns
showing what I budgeted and what I spent, with the ability to click
on a column to get another graph with broken-down details.

dave


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

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

[Terry Boldt]

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 back. Each policy owner got shares based on
their policy. I got a whopping 16.xxx shares. They gave everybody the option of
immediately selling through them. I have kept the shares, i.e., an entry in
their books, just for the heck of it. Selling 16.xxx shares just wasn't worth
the time and effort to return a stamped, self-addressed envelop. Every year I
get a dividend of 0. cents (thats the number of decimal places they carry
in their correspondence and I assume their books). So every year they buy me
another 0.xxx shares. I now have the grand total of 33.166 shares (they split
two for 1). 

I find it amusing (that's the main reason I haven't bothered trying to sell) to
every year get this statement with a dividend of so many cents carried out to
the fourth decimal point. That's 1/10,000 of a cent - they really do keep track
of it that close (I'm assuming - otherwise they are wasting a lot of paper and
postage telling their shareholders they do).

So in order for gnucash to keep track of this stock for me, it would have to
keep track of stock to within 1/1,000 of a stock unit and money (US) to within
1/10,000 of a cent. If that isn't reasonable I can understand - I'll just keep
letting the insurance company keep it on their books and track it for me :-)

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

Re: [Bug report] Tab at auto completed Description crashes

[Dave Peticolas]

 writes:
>/usr/local/share/gnucash/scm/engine-interface.scm:241:11: In expression (p
> ointer-token-null? split): 
>/usr/local/share/gnucash/scm/engine-interface.scm:241:11: Unbound variable
> : pointer-token-null?
> 
> Does anybody have a patch for this one?  It is *most* annoying to lose
> all ones entries when this happens.

Yes, apply that attached to c-interface.scm

thanks,
dave



Index: c-interface.scm
===
RCS file: /home/cvs/cvsroot/gnucash/src/scm/c-interface.scm,v
retrieving revision 1.9
retrieving revision 1.9.2.1
diff -u -u -r1.9 -r1.9.2.1
--- c-interface.scm 2000/05/11 09:00:12 1.9
+++ c-interface.scm 2000/07/04 23:25:11 1.9.2.1
@@ -17,6 +17,12 @@
 
 (require 'hash-table)
 
+
+;; Provides pointer-token-null? if needed (g-wrap >= 0.9.4 doesn't provide)
+(if (not (defined? 'pointer-token-null?))
+   (define (pointer-token-null? ptr)
+ (eq? ptr #f)))
+
 (define (gnc:error->string tag args)
   (define (write-error port)
 (if (and (list? args) (not (null? args)))



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

Re: Question/problem with import of QIF file

[Christopher Molnar]

Let me know if I can help track the problem down in any way.

(/me sitting here wathing the computer compiling updated KDE2 packages
for Mandrake)

-Chris

On Sat, 8 Jul 2000, Richard Wackerbarth wrote:

> On Sat, 08 Jul 2000, Christopher Molnar wrote:
> > Thanks to Richard and Bill who got back to me.
> >
> > -Chris
> 
> Well, it is clearly not something the YOU are doing wrong. Except for the 
> "funky" dates (which Bill's code fixes appropriately), the input file looks 
> fine and I get the same behavior that you observed.
> 
> I see what it is doing but I don't yet see how your input data differs from 
> mine.
> 
> I'm shoveling away at it to discover the difference.
> 
> --
> 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: Question/problem with import of QIF file

[Richard Wackerbarth]

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 Windows 98 system.
>
> -Chris

Well, it is clearly not something the YOU are doing wrong. Except for the 
"funky" dates (which Bill's code fixes appropriately), the input file looks 
fine and I get the same behavior that you observed.

I see what it is doing but I don't yet see how your input data differs from 
mine.

I'm shoveling away at it to discover the difference.

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

Re: what do we want to graph?

[Randolph Fritz]

On Sat, Jul 08, 2000 at 02:40:33PM -0400, Bob Stanfield wrote:
> > 
>   I find I like line graphs whenever there is historical data.
[...]
>  
> 
>   Again I use line graphs. When comparing a stock(s) and an index
[...]

A lot of the fancier graphs in Quicken and Excel are presentation
graphics, and are confusing to read.  May I suggest a reading of
Tufte's *Visual Display of Quantitative Information* and its sequels?

-- 
Randolph Fritz
Eugene, Oregon, USA

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

[Bug report] Tab at auto completed Description crashes

[flonesaw]

Running

Linux kernel 2.2.13  (SuSE 6.3, but custom compiled)
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
shlibs 2.1.2

xf86/xdevel 3.3.5-28 (SuSE RPM) - Millenium II PCI driver
enlightenment 0.16.0-3 (SuSE RPM)
gnlibs 1.0.53 (SuSE RPM)
imlib/imlibd 1.9.7-3 (SuSE RPM)
guile 1.3.4-3 (SuSE RPM)
slib2c7
eperl 2.2.14-14 (SuSE RPM)
nana 2.4-15 (SuSE RPM)
xhtml/xhtmld 1.1.15-18 (SuSE RPM)
libxml/libxmld 1.8.6-30 (SuSE RPM)
g-wrap 0.9.4 (Compiled from source)
gnucash 1.4.1 (Compiled from source)

The problem is 100% repeatable:

1. Open the check register

2. Go to a new transaction

3. Tab or click over to the Description field

4. Start entering a description which is already someplace in the
   register (so that the automatic completion is activated)

5. Press tab to go to the next field (and presumably accept the
   auto-completed description

6. ***Bingo***  As soon as you touch the Tab key, GnuCash crashes with
   the following error message:

   /usr/local/share/gnucash/scm/engine-interface.scm:241:11: In expression 
(pointer-token-null? split): 
   /usr/local/share/gnucash/scm/engine-interface.scm:241:11: Unbound variable: 
pointer-token-null?

Does anybody have a patch for this one?  It is *most* annoying to lose
all ones entries when this happens.

Thank you very much.


Regards,
Arne Flones
[EMAIL PROTECTED]




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

Re: what do we want to graph?

[Bob Stanfield]

On Sat, 8 Jul 2000, Robert Graham Merkel wrote:

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

> 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.
>
 
There are two standards the 50 and 200 day moving average. Is there a reason
why we couldn't make that a user option?

> 
> 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.
> 
I find I like line graphs whenever there is historical data.
This should be user optional.
 
> 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.

Again I use line graphs. When comparing a stock(s) and an index
I normalize by the initial prices. This is useful to see how a General 
Motors follows swings in the price of crude oil, for example! There are
few of us old dinosaurs who like information. If I want art, I'll go to a 
museum.
> 
> 
> 
> Robert Merkel[EMAIL PROTECTED]
> 
> 
> 
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
> 
> 
> 

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: Question/problem with import of QIF file

[Christopher Molnar]

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 Windows 98 system.

-Chris

On Sat, 8 Jul 2000, Richard Wackerbarth wrote:

> 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
> > positive for deposists. On the import all the numbers where put into the
> > withdrawl column which left me with a very bad -22,000.00 dollars in my
> > checking account.
> >
> > Any ideas?
> 
> 1) If you have any "investment accounts" that throw off interest or similar 
> transactions, please obtain the revised qif-to-gnc.scm file that was placed 
> in the CVS yesterday.
> Version 1.4.2 will be released soon to include this and other recent fixes.
> 
> 2) Can you isolate some transactions which do not appear to be posted 
> correctly and send me a qif file containing them?
> 
> If you need additional help, I'll be happy to assist.
> 
> 


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

Re: Question/problem with import of QIF file

[Richard Wackerbarth]

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). However, I had a problem with the import of a QIF file and am
> wondering if there is a quick fix/patch for this. (I would also like to
> include the patch if possible in an update for the next Mandrake release).
>
> The QIF file contains  negative dollar ammounts for withdwrawls and
> positive for deposists. On the import all the numbers where put into the
> withdrawl column which left me with a very bad -22,000.00 dollars in my
> checking account.
>
> Any ideas?

1) If you have any "investment accounts" that throw off interest or similar 
transactions, please obtain the revised qif-to-gnc.scm file that was placed 
in the CVS yesterday.
Version 1.4.2 will be released soon to include this and other recent fixes.

2) Can you isolate some transactions which do not appear to be posted 
correctly and send me a qif file containing them?

If you need additional help, I'll be happy to assist.

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

Question/problem with import of QIF file

[Christopher Molnar]

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). However, I had a problem with the import of a QIF file and am
wondering if there is a quick fix/patch for this. (I would also like to
include the patch if possible in an update for the next Mandrake release).

The QIF file contains  negative dollar ammounts for withdwrawls and
positive for deposists. On the import all the numbers where put into the
withdrawl column which left me with a very bad -22,000.00 dollars in my
checking account.

Any ideas?

-Chris



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

Re: denominators

[Richard Wackerbarth]

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 legitimately need to change would be the name of
> the currency.
>
> Supposing, for instance, the Fed decides that the US Dollar has inflated
> too much, and that they need to issue "new dollars" in a 1:100 ratio
> for the old ones.  That is, for $100 of "old" currency, or "old"
> balances, you get $1 in the "new, improved" version.
>
> [Admittedly, this particular scenario is vastly unlikely.  Change from
> $USD to the currencies of nations that have suffered from hyperinflation
> such as Israel, Mexico, Germany, and others, or to the not unusual
> scenario of a stock split and the scenario becomes not merely believable,
> but a somewhat common occurance...]
>
> In that case, it is likely that we want to rename all the "old"
> occurances from being "USD" to being "USD.old" or some such thing,
> as _new_ references should reference the commodity as it exists today.

I agree that New Pesos are different from Old Pesos. They MUST be stored in 
the database as different entities.

However, I'm not sure that the correct solution is to change the old 
designation rather than changing the new one.

All historically archived data would have to be changed. This may not be 
possible. However, it is possible to assure that new data is entered in the 
new units.

Now, I will allow that you probably should change the display of the old 
units to conform to current practice.

> > 
...
> > 

> I don't want to touch this one...

Sit down. Have some coffee and Pi.

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

Re: denominators

[Hendrik Boom]

> 
> > > Actually, a problem that none of the proposals in this mailing list
> > > addresses is the possibility that a commodity mught be bought and
> > > sold in units whose conversion factors are irrational.
> > 
> > As I said before, you can have irrational pricing but not irrational prices.
> > The ledgers represent inventories. Inventories can be counted.
> > Prices are exchange ratios. You trade items in one inventory for items in a 
> > different inventory. As such, field theory tells us that we will never have 
> > to deal with values that cannot be mapped onto the rational numbers.
> 
> People do _not_ use irrational numbers; supposing they count in radians,
> the one situation where it might _appear_ to be an exception, they're
> likely basing this on _integer fractions_ of radians, which means that
> the unit of measure is an integer fraction that just happens to get
> multiplied by Pi so as to make it _appear_ irrational.
> 
Good Grief, that irrational number thing was a joke!

> > >  Can you, for example buy angles in degrees and sell them in radians?
> > 
> > 
> > Well, I won't "buy" that angle. 
> > Where did you buy your degree?
> > Radian's already been sold.
> > 

But not marked as such because I was unaware of the HTML  tag. :-(
Or is that a joke, too? :-)

> > 


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

Re: denominators

[Christopher Browne]

On Sat, 08 Jul 2000 10:17:52 EST, the world broke into rejoicing as
Richard Wackerbarth <[EMAIL PROTECTED]>  said:
> 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 multiple of the old one.  Changing a denominator involves
> > retroactively rewrite all existing transactions that involved that
> > denominator.
> 
> 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 legitimately need to change would be the name of
the currency.

Supposing, for instance, the Fed decides that the US Dollar has inflated
too much, and that they need to issue "new dollars" in a 1:100 ratio
for the old ones.  That is, for $100 of "old" currency, or "old"
balances, you get $1 in the "new, improved" version.

[Admittedly, this particular scenario is vastly unlikely.  Change from
$USD to the currencies of nations that have suffered from hyperinflation
such as Israel, Mexico, Germany, and others, or to the not unusual
scenario of a stock split and the scenario becomes not merely believable,
but a somewhat common occurance...]

In that case, it is likely that we want to rename all the "old"
occurances from being "USD" to being "USD.old" or some such thing,
as _new_ references should reference the commodity as it exists today.

> > Actually, a problem that none of the proposals in this mailing list
> > addresses is the possibility that a commodity mught be bought and
> > sold in units whose conversion factors are irrational.
> 
> As I said before, you can have irrational pricing but not irrational prices.
> The ledgers represent inventories. Inventories can be counted.
> Prices are exchange ratios. You trade items in one inventory for items in a 
> different inventory. As such, field theory tells us that we will never have 
> to deal with values that cannot be mapped onto the rational numbers.

People do _not_ use irrational numbers; supposing they count in radians,
the one situation where it might _appear_ to be an exception, they're
likely basing this on _integer fractions_ of radians, which means that
the unit of measure is an integer fraction that just happens to get
multiplied by Pi so as to make it _appear_ irrational.

> >  Can you, for example buy angles in degrees and sell them in radians?
> 
> 
> Well, I won't "buy" that angle. 
> Where did you buy your degree?
> Radian's already been sold.
> 
> 
> For those of you outside the Silicon Hills, Radian Corp was a spinoff of 
> Tracor, Inc. here in Austin. They are a leader in environmental monitoring 
> and similar engineering.

I don't want to touch this one...
--
[EMAIL PROTECTED] - 
"I find it hard to believe a professional programmer could support the
concept of Open Source." -- David J. Owens <[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 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 in fractional shares, thanks to things like stock
> splits and "share-dividends".

OK, guys. Let me try once more.

There is the important matter of UNITS. We are free to "exchange" 
(compatible) units at will. Just because you DISPLAY a result in a particular 
set of units, you cannot infer that that is the set of units in which it is 
measured or counted.

For example, I have an annual report that lists gross sales in thousands of 
dollars. It's still a big number. However, if you go back and look at the 
books, I'm sure that they reported each sale to the penny.

You've hear the expression "six of one; half a dozen of the other".
Whether you have 18 eggs, 3 half-dozen eggs, or 1.5 dozen eggs, you have the 
same number of eggs.

So let's look at your stock split.

Assume that the stock splits "5 for 4" and you started with 10 shares and 
they are selling for $100 per share before the split. Your equity is worth 
$1000. After the split, (ignoring any price change) each new share would be 
worth 4/5 * $100 = $80.
Now, you will have 5/4 * 10 = 12 2/4 shares, still worth the same $1000.
There are two things that could happen. The company might decide that they 
will now count in quarter shares and you now have 50 of those. (You had 40 
before the split and got 10 more in the 5/4 split)

The other possibility is that the company will purchase your fractional share
and you will have 12 shares and $40 cash.

Note that in the first case, the price could be expressed as either $20 per 
quarter share or $80 per share.

> Also, there can be need to deal with things like "4 pounds, 3 and a half
> ounces"...  now, are these avoirdupois pounds (U.S. "standard" for most
> things, 16 ounces to the pound) or troy pounds (used for precious metals,
> 12 ounces to the pound)?

In either case they are some integral number of half ounces. 135 in the first 
case and 103 in the second. However, the latter is also 2060 pennyweight.

> 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., phone calls, wages, room rents, ...

Rooms are usually charged by the day or week. (OK, so you know a place that 
charges by the hour)

The point is that we can count in whatever units we consider appropriate. And 
each class of transactions can count in different denominations of the same 
"currency". 

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

Re: Units

[Richard Wackerbarth]

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., phone calls, wages, room rents, ...
>
> An excellent example of a commodity whose units are changing.
> Remember when phone calls were charged by the minute?
>
> If we use a common unit of nanoseconds, how many bits will be need to
> account for years or centuries?

This is the fallacy of "unification". There is no accounting reason to 
measure time in only one set of units.

Cell phone calls may be MEASURED to the second. But often, they are billed by 
the minute. The accounting transaction records only the CHARGED MINUTE, 
which, on average, is considerably less than 60 seconds.
On the other hand, hotels bill by the day. You don't get billed for 1 day, 
3.000501999 seconds. Or even 1441 minutes.

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

Re: denominators

[Richard Wackerbarth]

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 multiple of the old one.  Changing a denominator involves
> retroactively rewrite all existing transactions that involved that
> denominator.

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.

> Actually, a problem that none of the proposals in this mailing list
> addresses is the possibility that a commodity mught be bought and
> sold in units whose conversion factors are irrational.

As I said before, you can have irrational pricing but not irrational prices.
The ledgers represent inventories. Inventories can be counted.
Prices are exchange ratios. You trade items in one inventory for items in a 
different inventory. As such, field theory tells us that we will never have 
to deal with values that cannot be mapped onto the rational numbers.

>  Can you, for example buy angles in degrees and sell them in radians?


Well, I won't "buy" that angle. 
Where did you buy your degree?
Radian's already been sold.


For those of you outside the Silicon Hills, Radian Corp was a spinoff of 
Tracor, Inc. here in Austin. They are a leader in environmental monitoring 
and similar engineering.

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

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

[Hendrik Boom]

> 
> 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., phone calls, wages, room rents, ...
> 
An excellent example of a commodity whose units are changing.
Remember when phone calls were charged by the minute?

If we use a common unit of nanoseconds, how many bits will be need to
account for years or centuries?

-- hendrik.

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

denominators

[Hendrik Boom]

One of the big issues seems to be whether we have just one denominator
for a commodity, or many.  Examples are being thrown around about
whether there is a quantum unit of a commodity,  whether it changes,
and how often, and whether the quantum unit is so intrinsic to a commodity
that, say,  milk bought by the gallon is a different commodity from
milk bought by the quart.  Indeed, if every transaction involves its
own denominator, independent of any other, using a fixed denominator
would seem to be madness.  It all transactions can be expressed in the
same denominator, which is known a priori, there is no need to store it
with every transaction. The choice of data representation is merely an
optimization issue.

Reality does not seem to be as neat as either of these extremes,
though, and so the optimisation issue may have to resolved by a compromise.

Let each commodity to have its own common denominator, but change this
denominator when new transactions make it necessary.  The new denominator
be a multiple of the old one.  Changing a denominator involves retroactively
rewrite all existing transactions that involved that denominator.

In typical situations the I imagine, the denominator for any commodity
will settle down after a few transactions, after which all remaining
transactions will be expressible in exact multiples of the final
quantum.  Even if an exchange redenominates fron 1/64 to 1/100,
this would only change our common denominator for one of its
commodities from 1/64 to 1/1600.

-

There is one nightmare situation for this approach: a series of
transactions in a commodity whose amounts have relatively prime
denominators.  For example you might buy milk on consecutive days:
1/liter, 1/3 liter, 1/5 liter, 1/7 liter, 1/11 liter, 1/13 liter,
1/17 liter, 1/19 liter, 1/23 liter, 1/29 liter.  The denominator will
skyrocket, and reach the limit of 32 or 64-bit integer representation
rather quickly, after which your grocery-budget accountant will
worry about thee gnucash integer overflow.

Actually, a problem that none of the proposals in this mailing list
addresses is the possibility that a commodity mught be bought and
sold in units whose conversion factors are irrational.  Can you, for
example buy angles in degrees and sell them in radians?  Now the accountant
can no longer  remain silent.  He formally accuses you of being a
mathematician. :-)

-- hendrik.

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

ADMIN: gnucash.org moving ; list will be flaky.

[Bill Gribble]

Jeremy Collins, who has kindly hosted gnucash.org for some time, is no
longer able to host the site.  At one point, it looked like there
would be a "grace period" of several weeks to make the transition to a
new host.  However, circumstances beyond our control (and Jeremy's)
have made it imperative to move gnucash.org immediately.

As a TEMPORARY measure, just to keep the mailing lists and web site
going for the next little while, we are pointing gnucash.org to our
machines at Gnumatic.  We realize the potential conflict of interest
in having the community's mailing list and web site hosted by a
corporate developer of gnucash, and we don't want to ruffle anybody's
feathers.  However, the short-term problem is fairly acute and we need
to keep the lists and the gnucash.org website up.

In any case, we are scrambling to set the mailing list and web site up
here and hopefully the DNS changes will get made real soon now.  There
WILL be problems, I'm sure.  Please be patient and direct non-flame
problem reports to me ([EMAIL PROTECTED]), Rob Browning
([EMAIL PROTECTED]) and/or Dave Peticolas ([EMAIL PROTECTED]).  Rob and
I will be in Toronto all next week, but we should be able to read
email and we'll certainly be trying to make sure the site is up.

Thanks again to Jeremy for administering the site and lists for so
long.  His work has made a big difference in the public perception of
the project and has made it possible for the community to stay in
touch.

Bill Gribble



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

cvs 2000-07-08

[Dave Peticolas]

Both Branches:

 + Bill Gribble's qif import patch.

 + Yannick Le Ny's translator README.


Development Branch:

 + Bill Gribble's big patch which:

1. Switches the html windows over to using the gtkhtml widget.
   You need the gnome-print libraries (including the development
   package) for this.

   The easiest way to get all the needed libraries other than
   gtkhtml would be to upgrade to helix code's desktop. If you
   do this, make sure to instal the development packages as well.

   You also need to install the latest gtkhtml version. This
   package is not yet available on many systems (it is still
   in development). The lib directory in CVS now has a snapshot
   of gtkhtml which you can use.

***NOTE: Before installing gtkhtml, read lib/README!

2. g-wraps the query api. This conversion breaks the account
   balance report.

3. Adds key-value pair support to engine structures.

NOTE: 2 & 3 are untested and are mainly to get them into
  CVS for safekeeping.


dave

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

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

[Clark Jones]

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.

Stocks can also be in fractional shares, thanks to things like stock
splits and "share-dividends".

Also, there can be need to deal with things like "4 pounds, 3 and a half
ounces"...  now, are these avoirdupois pounds (U.S. "standard" for most
things, 16 ounces to the pound) or troy pounds (used for precious metals,
12 ounces to the pound)?

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., phone calls, wages, room rents, ...

Clark
-- 
Disclaimer:  The opinions expressed herein are mine and not necessarily
those of anyone else.  (As if anyone else would want them!)

Internet: [EMAIL PROTECTED] RF: KI7TU
ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones

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