Re: Log File behaviour
Richard Wackerbarth writes: On Thu, 15 Jun 2000, Dave Peticolas wrote: Now, those .xac files - are they the previous data file, or are they written in parallel with the main file? (Or copied after the main file is written?) They are written immediately after the main file is written. So, if I have (only) a main file and start to edit it, are you saying that at the end, I have two copies of the modified file and NO copies of the original Yes, that's right. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Log File behaviour
On Fri, 16 Jun 2000, Dave Peticolas wrote: Richard Wackerbarth writes: On Thu, 15 Jun 2000, Dave Peticolas wrote: Now, those .xac files - are they the previous data file, or are they written in parallel with the main file? (Or copied after the main file is written?) They are written immediately after the main file is written. So, if I have (only) a main file and start to edit it, are you saying that at the end, I have two copies of the modified file and NO copies of the original Yes, that's right. I could recommend another strategy :-) -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Log File behaviour
Richard Wackerbarth writes: On Fri, 16 Jun 2000, Dave Peticolas wrote: Richard Wackerbarth writes: On Thu, 15 Jun 2000, Dave Peticolas wrote: Now, those .xac files - are they the previous data file, or are they written in parallel with the main file? (Or copied after the main file is written?) They are written immediately after the main file is written. So, if I have (only) a main file and start to edit it, are you saying that at the end, I have two copies of the modified file and NO copies of the original Yes, that's right. I could recommend another strategy :-) Yes, we might want to think about just copying the original to the backup file, rather than making a trail of 'save histories'. OTOH, when we move to using sleepycat db, as it seems we probably will, there may be an even better solution using that tool. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency - was: non-functional 'if clause
On Thu, 15 Jun 2000, Hendrik Boom wrote: Each currency has its own "primitive" amount and all transactions are conducted in terms of that unit. Prices are often expressed to a higher precision or as a rational fraction of that unit. This suggests that we should be storing integers that indicate how many of the primitive amount are to be used. For US$ this would be an exact count of pennies. I believe that this is the correct approach. The range of integers must be greater than 32-bits, because that would limit amounts to about #40,000,000.00. You are correct. 32 bits are inadequate. It would be sufficient for MY personal accounts :-( but not those of Mr. Gates. So the obvious type is int64 Or we can "roll our own" with a money struct. In cases like this, C++ does have its advantages over C. But we can work around it. Thus, for display purposes, we may have to know the primitive amount for each currency as well as the format to be used. Correct. I've always been doubtful about the use of floating point by gnucash. Likewise. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Log File behaviour
On Fri, 16 Jun 2000, Dave Peticolas wrote: Richard Wackerbarth writes: I could recommend another strategy :-) Yes, we might want to think about just copying the original to the backup file, rather than making a trail of 'save histories'. You can have both by having a trail of backups. OTOH, when we move to using sleepycat db, as it seems we probably will, there may be an even better solution using that tool. I don't think that gnucash should dictate a single strategy. The strategy is a function of the storage mechanism and we should remain neutral. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Thu, 15 Jun 2000, Ben Stanley wrote: (The C++ bit is nice here because overflow checking can be incorporated into the number class.) It also makes it easy to handle currency problems by subclassing "beans" and hiding the particulars of "counting" (adding) them. However, I realise that you guys like C and want to keep it that way. Careful who you snare in your "guilt by association". The project was started in C and AFAICT stuck there by inertia and the bias of some of those who are running things. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, 16 Jun 2000, Dave Peticolas wrote: Richard Wackerbarth writes: Each currency has its own "primitive" amount and all transactions are conducted in terms of that unit. This suggests that we should be storing integers I don't think this is very practical. There are well over 100 currencies in circulation and keeping track of them is not a small task. Also, it's not just a matter of gathering the information once, because, as someone has already pointed out, the 'primitive' amount of a currency can change. Yes, but not very often. In a practical sense, you set up the currencies that you use and forget the rest. Furthermore, gnucash also should be able to track mutual fund shares, precious metal quantities, and anything else of financial value that users might wish, in whatever accuracy they want. Agreed. Stock in XYZ Corp is just another currency. And to complicate things, it trades in different units in different places. If the use of floating points becomes an issue, As far as I am concerned, it IS an issue. I think a better solution would be to use an arbitrary precision library. We would still get absolute accuracy, but we would dispense with the need to track 'primitive units' for every currency/whatever that people might wish to count. When transactions occur, they are rounded. In general, the roundoff error accumulates to an amount which exceeds the displayed precision. We need to model the actual behavior rather than approximating it. This can only be done by knowing the rounding precision of each transaction. Therefore, we must track the 'primitive units'. If I cannot convince the gnucash folks of this, I'll have to advocate agnu-er-cash project since a project based on "floating point is good enough" will never "get it right". -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Richard Wackerbarth writes: When transactions occur, they are rounded. In general, the roundoff error accumulates to an amount which exceeds the displayed precision. We need to model the actual behavior rather than approximating it. This can only be done by knowing the rounding precision of each transaction. Therefore, we must track the 'primitive units'. Could you give a concrete example of this for the purposes of discussion? thanks, dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
You are correct. 32 bits are inadequate. It would be sufficient for MY personal accounts :-( but not those of Mr. Gates. Mr Gates is unlikely to use gnucash on Linux. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Richard Wackerbarth writes: When transactions occur, they are rounded. In general, the roundoff error accumulates to an amount which exceeds the displayed precision. We need to model the actual behavior rather than approximating it. This can only be done by knowing the rounding precision of each transaction. Therefore, we must track the 'primitive units'. Could you give a concrete example of this for the purposes of discussion? I buy peaches at 3/$1. If I buy them one at a time, each transaction is rounded, and I get 1 peach for $0.33. After three such transactions, I've spent $0.99 for 3 peaches. The rounding error accumulated in my favor. I buy apples at 3/$2. If I buy them one at a time, each transaction is rounded, and I get 1 peach for $0.67. After three transactions, I've spent $2.01 for 3 apples. The rounding error accumulated in my grocer's favor. Or, for a more GnuCash-ish example... I have a couple of outstanding student loans, which I am dilligently paying back. Every month, I make a student loan payment of a fixed amount, on a fixed date, etc. This is the perfect scenario for the (as I understand it) not-yet-completed scheduled recurring transaction functions of GnuCash. But the transactions are not perfectly identical. This months payment of $p is going to pay interest at an annual rate of r, and the rest is going to principle. So what I'd really like to happen is for each recurring transaction to have a Journal Entry like so: x/14/00 Student Loan Payment Checking account$p Interest on Loans $B*r/12 Stafford Loan Balance $p-$B*r/12 where $B is the previous balance on the student loan. The problem comes with the computation of $B*r/12, since this is unlikely to come out to an integral number of cents. If $B is $20,000, r is 8%, then this works out to $B*r/12 = $133.33, which gets rounded (in real life) to simply $133.33. Which means that if my loan payment was (say) $250, then I'd pay $116.67 towards the principle. I'd want GnuCash to record that as interest of $133.33, principle of $116.67, since that is what my creditor will record it as. If GnuCash recorded the balances internally as FP numbers, then the amounts wouldn't get rounded off. The difference would be small, true, but over time could result in the GnuCash computed values differing from the "real" values significantly, where a cent may be considered "significant". (BTW, is the recurring transaction system going to be able to handle transactions like that? That seems like a fairly common type of recurring transaction.) thanks, dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED] -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, 16 Jun 2000, Dave Peticolas wrote: Richard Wackerbarth writes: When transactions occur, they are rounded. In general, the roundoff error accumulates to an amount which exceeds the displayed precision. We need to model the actual behavior rather than approximating it. This can only be done by knowing the rounding precision of each transaction. Therefore, we must track the 'primitive units'. Could you give a concrete example of this for the purposes of discussion? Assume the case where an item is priced at 3 for $2. For this discussion, the price NEVER changes. Purchase one item. and another and a third Total cost = 3* $0.67 = $2.01 Now purchase 3 at once. Cost = $2.00 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, 16 Jun 2000, Buddha Buck wrote: Could you give a concrete example of this for the purposes of discussion? I buy peaches at 3/$1 ... I buy apples at 3/$2 ... Or, for a more GnuCash-ish example... I have a couple of outstanding student loans ... Thanks, your description is certainly better than mine was. And if you don't believe these are real problems, I encountered them some thirty years ago when I (actually my client) bought some 20,000 such loans for $139,000,000.00 Keeping those books REQUIRED both more than 32 bits precision and counting pennies on each individual transaction. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency - was: non-functional 'if clause
On Fri, 16 Jun 2000 03:33:34 EST, the world broke into rejoicing as
Richard Wackerbarth [EMAIL PROTECTED] said:
On Thu, 15 Jun 2000, Hendrik Boom wrote:
Each currency has its own "primitive" amount and all transactions are
conducted in terms of that unit. Prices are often expressed to a higher
precision or as a rational fraction of that unit.
This suggests that we should be storing integers that indicate
how many of the primitive amount are to be used. For US$ this would
be an exact count of pennies.
I believe that this is the correct approach.
I'd tend to agree.
The range of integers must be greater than 32-bits, because
that would limit amounts to about #40,000,000.00.
You are correct. 32 bits are inadequate. It would be sufficient for MY
personal accounts :-(
but not those of Mr. Gates.
So the obvious type is int64
Or we can "roll our own" with a money struct.
In cases like this, C++ does have its advantages over C. But we can work
around it.
I'd favor something like:
struct {
long long amount;
short mantissa;
char currency[4];
} money;
which would provide a reasonably efficient representation; we'd get
something a bit more portable via:
struct {
gint64 amount;
gint16 mantissa;
char currency[4];
} money;
Note that the CORBA C mapping takes
fixed10,2 money;
and generates:
typedef struct
{
CORBA_unsigned_short _digits;
CORBA_short _scale;
CORBA_char _value[6]; /* 6 = ceiling((10+2)/2) */
} CORBA_fixed_10_2;
which is treated as BCD. [I remember the Z80 having BCD
instructions...]
C++ doesn't pack "fixed" values; it seems to be "one digit, one byte."
The main merit of C++ here is that you'd be able to define overloaded
operations for +, -, *, /, which allow you to at least _consider_ having:
total_money = v1_money + v2_money;
I'm not sure it generalizes much better than that...
Guile would probably cope with this better still; I expect we could
build GOOPS classes and structures that would work out _quite_ well.
(set! total (money+ value1 value2 value3 value4))
Thus, for display
purposes, we may have to know the primitive amount for each currency as
well as the format to be used.
Correct.
I've always been doubtful about the use of floating point by gnucash.
Likewise.
Ditto...
--
[EMAIL PROTECTED] - http://www.ntlug.org/~cbbrowne/linux.html
"I worry that the person who thought up Muzak may be thinking up
something else." -- Lily Tomlin
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Quicken98(Mac) - gnucash import balance errors
-BEGIN PGP SIGNED MESSAGE- I'm still seeing this problem, but it has moved. Yesterday's CVS corrected the problem with one closed bank account, but another closed account now has a non-zero balance. I'll have to poke at the data to see what seems to be the problem. Further, our checking account show a -29,384.10 balance. I'm certainly happy that's an error! roland - -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhDUnix Software Solutions [EMAIL PROTECTED] 76-15 113th Street, Apt 3B [EMAIL PROTECTED] Forest Hills, NY 11375 -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQCVAwUBOUonu+oW38lmvDvNAQETWgQAiNaB0+ffwkuQfsvPt/yG2X8Wit0aakkS ya33y9mhmfRdblhRM1sGOhEGFfFiv83lNKSop0HT7PUN2+OeaVHTmk7/pFea0hhU HNxtrfCPcgWyjGJQO8mTG84CRzj8wMkGdIpq8y1n7RIBR/fxGW/4YnFlq+Oticb5 2Tvn0amvqUA= =vs2u -END PGP SIGNATURE- -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Invoicing Software
Dynacom Technologies introduces today the new Dynacom Invoicing 2000 which is specially designed for small business, who may need just the invoicing and accounts receivable modules for starting, new company. The suggested retail price of this new software is $39.95. Here are briefly described, some of the many features found in the new Dynacom Invoicing 2000, most requested by users who have had experience with the other fine accounting software from Dynacom Technologies during the past ten years and who have contributed to improve Dynacom products. Some of the features found in Invoicing 2000 - Interface with Accounts Receivable and inventory database - Allows entering and placing orders and print revised list - Orders can be invoiced on entry (simple invoicing) or held as credited orders that will be invoiced later (double invoicing) - Automatically updates inventory(in Inventory management), allowing order entry and invoicing - Allows printing back orders (B/O) by customer or by item and a packing slip - Allows quotations and could convert them to invoices - Automatically feeds the Accounts receivable and Inventory control modules with invoicing information - Allows deferred invoice printing and keeps a history of all customer invoices Some of the features found in the Accounts Receivable module: - Unlimited number of customers and inventory items with a search for customers with help of windows - Prints the aging report or statements on a pre-printed form - Allows directly displaying a receivable account - Allows thoroughly checking integrated sales statistics by customer - Can be upgraded and integrated to Dynacom Accounting Basic or advanced Edition or use stand-alone For more Information : Paul Trudeau E-Mail : [EMAIL PROTECTED] USA : 1-800-748-2268 Ext : 205 Canada : 1-800-565-2266 Ext: 205 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Buddha Buck writes: If GnuCash recorded the balances internally as FP numbers, then the amounts wouldn't get rounded off. The difference would be small, true, but over time could result in the GnuCash computed values differing from the "real" values significantly, where a cent may be considered "significant". Ok, you've convinced me of the need to track 'smallest denominational units', but not why we need to use integers rather than FP numbers. You can round FP numbers, too. Why couldn't we just round the FP amounts to the appropriate precision when needed? If you're worried about the loss of accuracy, you should provide a realistic example where the precision of 64-bit floating points is insufficient. And if you're really worried about that kind of accuracy, I think arbitrary precision would be required. You will lose accuracy in intermediate calculations doing division and multiplication of the integermantissa structs/classes as well. (BTW, is the recurring transaction system going to be able to handle transactions like that? That seems like a fairly common type of recurring transaction.) I don't see why it couldn't, I mean, it hasn't been started yet, so it's all up in the air. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, 16 Jun 2000, Dave Peticolas wrote: Ok, you've convinced me of the need to track 'smallest denominational units', but not why we need to use integers rather than FP numbers. You can round FP numbers, too. Why couldn't we just round the FP amounts to the appropriate precision when needed? If you're worried about the loss of accuracy, you should provide a realistic example where the precision of 64-bit floating points is insufficient. I don't have a problem with 64 bit FP precision. However, I worry that you don't gain anything by using FP. And you do run the risk of forgetting to process the values as money rather than true reals. In that respect, having a struct type which does not allow the "+" operator would help make sure that you didn't inadvertently overload the simple arithmatic operators. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Richard Wackerbarth writes: On Fri, 16 Jun 2000, Dave Peticolas wrote: Ok, you've convinced me of the need to track 'smallest denominational units', but not why we need to use integers rather than FP numbers. You can round FP numbers, too. Why couldn't we just round the FP amounts to the appropriate precision when needed? If you're worried about the loss of accuracy, you should provide a realistic example where the precision of 64-bit floating points is insufficient. I don't have a problem with 64 bit FP precision. However, I worry that you don't gain anything by using FP. And you do run the risk of forgetting to process the values as money rather than true reals. The reason why I like doubles is that a huge amount of work has gone into making the IEEE floating point specification "correct". These quantities are used ubiquitously and are scrutinized by many people. I have great confidence that the calculations are being done correctly. OTOH, if we roll our own numerical library, I will have much less confidence. It's not that I think we are bad developers, it's just that the problem is quite complicated. It took a long time to get IEEE floating point correct, and there were some extremely smart people involved. For that reason, if we decide to drop doubles, I would rather use a library like gmp which has already been written/debugged rather than start from scratch. We've got too many other things to do. In that respect, having a struct type which does not allow the "+" operator would help make sure that you didn't inadvertently overload the simple arithmatic operators. I agree. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency - was: non-functional 'if clause
Ben Stanley wrote: Hendrik Boom wrote: I've always been doubtful about the use of floating point by gnucash. The problem with floating point types is that they only provide an approximation to what you want. [ snipped ] 1/2 = 0.5 0.1, so we have 0 * 2^-1. 1/4 = 0.25 0.1, so we have 0 * 2^-2. 1/8 = 0.125 0.1, so we have 0 * 2^-3. [ snipped ] results.) However, in a financial application, we need to reliably track every last cent (or penny, or yen, or whatever). Thus, I feel that the double type is eminently unsuitable. What's the solution to this problem? I will first mention a historical solution - this probably bears little relevance to what we should do, but anyway... I seem to remember that the 6502 microprocessor, which was used in the C64, had a BCD flag. When it was enabled, it entered a special mode, where all math operations assumed that each byte held 2 decimal digits, ... [ snipped ] Alternately, integers have no rounding error. However, they are susceptible to overflow. Their range is ... PL/I tried to do EVERYTHING that had been done before. Even the subset used on CP/M boxes (ie, S-100) had integers, floating point, and BCD (Binary-Coded-Decimal). The subset left out Complex :-(( "money" problems could be worked in BCD, even if they were part of an engineering calculation that was mostly floating point. Financial presentations meant to rank wished-for projects can be done in floating point, even the net-present-worth stuff, because the overall approximation is good enough. Monthly credit card interest charges may have internal rounding, but the month end is rounded to $0.01. Corporate Accounting departments are leary of engineers who make shortcut (but useful :-) math routines for keeping track of money!! Stanley Long, PE Consulting Electrical Engineer Anchorage, Alaska -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, 16 Jun 2000, Dave Peticolas wrote: Richard Wackerbarth writes: On Fri, 16 Jun 2000, Dave Peticolas wrote: Ok, you've convinced me of the need to track 'smallest denominational units', but not why we need to use integers rather than FP numbers. You can round FP numbers, too. Why couldn't we just round the FP amounts to the appropriate precision when needed? If you're worried about the loss of accuracy, you should provide a realistic example where the precision of 64-bit floating points is insufficient. I don't have a problem with 64 bit FP precision. However, I worry that you don't gain anything by using FP. And you do run the risk of forgetting to process the values as money rather than true reals. The reason why I like doubles is that a huge amount of work has gone into making the IEEE floating point specification "correct". These quantities are used ubiquitously and are scrutinized by many people. I have great confidence that the calculations are being done correctly. OTOH, if we roll our own numerical library, I will have much less confidence. It's not that I think we are bad developers, it's just that the problem is quite complicated. It took a long time to get IEEE floating point correct, and there were some extremely smart people involved. Unlike FP, Scaled integer arithmetic is easy. The main thing that we do is addition. And that is the easiest to do. Actually, the hard part is getting the rounding done in the right places. A good FP package won't help there at all. For that reason, if we decide to drop doubles, I would rather use a library like gmp which has already been written/debugged rather than start from scratch. We've got too many other things to do. I have no problem using gmp when Int64 is not available. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Richard Wackerbarth writes: On Fri, 16 Jun 2000, Dave Peticolas wrote: Richard Wackerbarth writes: On Fri, 16 Jun 2000, Dave Peticolas wrote: Ok, you've convinced me of the need to track 'smallest denominational units', but not why we need to use integers rather than FP numbers. You can round FP numbers, too. Why couldn't we just round the FP amounts to the appropriate precision when needed? If you're worried about the loss of accuracy, you should provide a realistic example where the precision of 64-bit floating points is insufficient. I don't have a problem with 64 bit FP precision. However, I worry that you don't gain anything by using FP. And you do run the risk of forgetting to process the values as money rather than true reals. The reason why I like doubles is that a huge amount of work has gone into making the IEEE floating point specification "correct". These quantities are used ubiquitously and are scrutinized by many people. I have great confidence that the calculations are being done correctly. OTOH, if we roll our own numerical library, I will have much less confidence. It's not that I think we are bad developers, it's just that the problem is quite complicated. It took a long time to get IEEE floating point correct, and there were some extremely smart people involved. Unlike FP, Scaled integer arithmetic is easy. The main thing that we do is addition. And that is the easiest to do. Actually, the hard part is getting the rounding done in the right places. A good FP package won't help there at all. Addition may be the main thing thing, but it's not the only thing. Even if you only do a multiplication/division/etc. once in a while, you've still got to do it correctly. For that reason, if we decide to drop doubles, I would rather use a library like gmp which has already been written/debugged rather than start from scratch. We've got too many other things to do. I have no problem using gmp when Int64 is not available. If we're going to use gmp sometimes, we should use it all the time. Mixing two libraries is just silly. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Buddha Buck [EMAIL PROTECTED] writes: I buy peaches at 3/$1. If I buy them one at a time, each transaction is rounded, and I get 1 peach for $0.33. After three such transactions, I've spent $0.99 for 3 peaches. The rounding error accumulated in my favor. But when is this acutally a problem in gnucash? So far, from everything everyone's said. I can't see one place where switching to some home-grown fixed point solution for the actual representation has *any* advantage over sticking with 64-bit floating point. The *only* practical difference I can see would be wrt performance, and that's just not relevant these days. People are spending plenty of time making sure that floating point processors are more than fast enough for our purposes. The issue of when we need to round our values, and to what extent is AFAICT a *completely* separable issue from whether or not we represent them as floating point internally. I'm sure that IEEE 64-bit floats have far more than enough accuracy to handle any currencies we're going to run across -- as far as currency-range values are concerned, the IEEE-64 representation of 1.3 *is* exactly 1/3 because the lossage is so far out to the right that you'll never see it, and even if someone can prove me wrong there, then I maintain that the right solution would just be to see about switching to an arbitrary precision library, and then we'd still need to ask the same questions about when and what to round. So yes there may be times we need to round, but that's not related to whether or not we use doubles as the underlying representation, and I suspect that most often the "rounding" will be done by hand because you'll be entering the values yourself. If the groccery sells apples 3/dollar and you buy two, you'll get charged $0.67, and that's what you'll enter into gnucash. IMO -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, Jun 16, 2000 at 01:44:01PM -0700, Dave Peticolas wrote: The reason why I like doubles is that a huge amount of work has gone into making the IEEE floating point specification "correct". These quantities are used ubiquitously and are scrutinized by many people. I have great confidence that the calculations are being done correctly. OTOH, if we roll our own numerical library, I will have much less confidence. It's not that I think we are bad developers, it's just that the problem is quite complicated. It took a long time to get IEEE floating point correct, and there were some extremely smart people involved. For that reason, if we decide to drop doubles, I would rather use a library like gmp which has already been written/debugged rather than start from scratch. We've got too many other things to do. Let me point out that, so far as I know, no responsible accountant would recommend uncorrected binary floating-point arithmetic for bookkeeping, though it is used in economic modelling. A system where 1% of $10 is not 10 cents is not acceptable for bookkeeping! Interval arithmetic http://www.cs.utep.edu/interval-comp/main.html would--I think--solve this problem, but the standard for bookkeeping is IBM's decimal arithmetic. A proposed version for Java, including a detailed discussion and code can be seen at http://www2.hursley.ibm.com/decimal/. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, Jun 16, 2000 at 04:27:32PM -0500, Rob Browning wrote: But when is this acutally a problem in gnucash? Every time interest is computed. The issue of when we need to round our values, and to what extent is AFAICT a *completely* separable issue from whether or not we represent them as floating point internally. I'm sure that IEEE 64-bit floats have far more than enough accuracy to handle any currencies we're going to run across -- as far as currency-range values are concerned, the IEEE-64 representation of 1.3 *is* exactly 1/3 because the lossage is so far out to the right that you'll never see it, and even if someone can prove me wrong there, then I maintain that the right solution would just be to see about switching to an arbitrary precision library, and then we'd still need to ask the same questions about when and what to round. There are already accounting standards in this area--they all start with fixed-point decimal. One of your accounting experts can probably speak to this in more details. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
To whom do I address a spam complaint?
I just got some spam sent through gnu-cash mailing list. To whom do I send a complaint, so the mailing list will tighten up procedures to prevent recurrance? First few headers were: Return-Path: [EMAIL PROTECTED] Received: from mail.gnucash.org (IDENT:[EMAIL PROTECTED] [63.228.66.33]) by hiway1.exit109.com (8.9.3/8.9.3) with SMTP id NAA25746 for [EMAIL PROTECTED]; Fri, 16 Jun 2000 13:13:45 -0400 (EDT) (envelope-from [EMAIL PROTECTED]) Received: (qmail 23008 invoked by alias); 16 Jun 2000 17:13:51 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 23003 invoked from network); 16 Jun 2000 17:13:50 - Delivered-To: [EMAIL PROTECTED] Message-ID: B11EFA2325DED3119E98C74C854E0C8F4F@SERVICESRV From: Paul Trudeau [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" [EMAIL PROTECTED] Subject: Invoicing Software Date: Fri, 16 Jun 2000 13:03:19 -0400 -- Jean-David Beyer .~. Shrewsbury, New Jersey /V\ Registered Linux User 85642. /( )\ Registered Machine73926. ^^-^^ -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: To whom do I address a spam complaint?
Jean-David Beyer writes: I just got some spam sent through gnu-cash mailing list. To whom do I send a complaint, so the mailing list will tighten up procedures to prevent recurrance? They're all on this list, so consider them complained to :) I got it too -- it looks like it came from the old xaccountant bugs list. I think Linas Vepstas [EMAIL PROTECTED] maintains that now. I'm sure he will take steps to rectify things. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, 16 Jun 2000, Rob Browning wrote: So far, from everything everyone's said. I can't see one place where switching to some home-grown fixed point solution for the actual representation has *any* advantage over sticking with 64-bit floating point. The issue of when we need to round our values, and to what extent is AFAICT a *completely* separable issue from whether or not we represent them as floating point internally. So yes there may be times we need to round, but that's not related to whether or not we use doubles as the underlying representation, I agree that the underlying representation is not the problem. The problem is that people are bypassing the class wrapper and doing operations directly on these values. It is this misuse which is the problem. For example, if I add up a series of 10,000 transactions, I must convert the intermediate results back to "exact" money so that the error does not accumulate. I suspect that most often the "rounding" will be done by hand because you'll be entering the values yourself. If the groccery sells apples 3/dollar and you buy two, you'll get charged $0.67, and that's what you'll enter into gnucash. Well, gnucash is already messing up my brokerage account because of its mishandling of shares, prices, and amounts Remember that accounting is a COUNTING and counting is done in integers -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Rob Browning said... Buddha Buck [EMAIL PROTECTED] writes: I buy peaches at 3/$1. If I buy them one at a time, each transaction is rounded, and I get 1 peach for $0.33. After three such transactions, I've spent $0.99 for 3 peaches. The rounding error accumulated in my favor. But when is this acutally a problem in gnucash? This isn't... After all, as you say below, I'd enter 0.33 for each peach, based on my receipt, and all is well. But I did give another example, which you don't make reference to, which deals -specifically- to gnucash. So far, from everything everyone's said. I can't see one place where switching to some home-grown fixed point solution for the actual representation has *any* advantage over sticking with 64-bit floating point. The *only* practical difference I can see would be wrt performance, and that's just not relevant these days. People are spending plenty of time making sure that floating point processors are more than fast enough for our purposes. The main reason I have for integer/fixed point over floating point is because the domain of the problem is fixed point arithmetic, not floating point. You are a scheme programmer, right? I maintain that IEEE floating point is optimised for inexact real computations. As such, it is an ideal represenation of Scheme inexact real classes. On the otherhand, I also think that accounting, by it's nature, is -exact-. As such, using an inexact type when a suitable exact type exists (or can be made to exist) is not useful. Consider this: The -vast- majority of operations on currency done in accounting are addition, with subtraction being a close second. We never multiply currencies by currencies. When we do multiply currencies by scalers, we -always- immediately round, so that we maintain the same number of decimal places. And we also compare currency values -- if for no other reason than to assure that the books balance.We do that commonly by adding everything up and comparing to 0. As a counterpoint, addition and subtraction is one of the weaknesses of floatingpoint numbers, whereas they are an optimised representation for multiplication/division. And another traditional weakness is in floating point equality comparisons. And comparisons with 0 are particularly prone. The issue of when we need to round our values, and to what extent is AFAICT a *completely* separable issue from whether or not we represent them as floating point internally. I'm sure that IEEE 64-bit floats have far more than enough accuracy to handle any currencies we're going to run across -- as far as currency-range values are concerned, the IEEE-64 representation of 1.3 *is* exactly 1/3 because the lossage is so far out to the right that you'll never see it, and even if someone can prove me wrong there, then I maintain that the right solution would just be to see about switching to an arbitrary precision library, and then we'd still need to ask the same questions about when and what to round. IEEE does have sufficient precision such that if rounding is done -consistantly-, everytime and -when- a currency value gets multiplied by an arbitrary double, we will likely never run into an error after rounding, even given the inherent problems with floating point addition and subtraction. Except possibly with comparisons -- Sure, both $175.53/7 and $526.59/21 will both round to something that will display as $25.07, but are those two values internally equal? So yes there may be times we need to round, but that's not related to whether or not we use doubles as the underlying representation, and I suspect that most often the "rounding" will be done by hand because you'll be entering the values yourself. If the groccery sells apples 3/dollar and you buy two, you'll get charged $0.67, and that's what you'll enter into gnucash. What about the recurring transaction I mentioned in my last message? The transaction was a $250 payment on a loan, automatically split between interest (computed as a percentage of the outstanding principle) and the principle (computed as $250-interest)? IMO IMO, as well... -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED] -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, 16 Jun 2000, you wrote: Richard Wackerbarth writes: On Fri, 16 Jun 2000, Dave Peticolas wrote: Richard Wackerbarth writes: On Fri, 16 Jun 2000, Dave Peticolas wrote: Ok, you've convinced me of the need to track 'smallest denominational units', but not why we need to use integers rather than FP numbers. You can round FP numbers, too. Why couldn't we just round the FP amounts to the appropriate precision when needed? If you're worried about the loss of accuracy, you should provide a realistic example where the precision of 64-bit floating points is insufficient. I don't have a problem with 64 bit FP precision. However, I worry that you don't gain anything by using FP. And you do run the risk of forgetting to process the values as money rather than true reals. The reason why I like doubles is that a huge amount of work has gone into making the IEEE floating point specification "correct". These quantities are used ubiquitously and are scrutinized by many people. I have great confidence that the calculations are being done correctly. OTOH, if we roll our own numerical library, I will have much less confidence. It's not that I think we are bad developers, it's just that the problem is quite complicated. It took a long time to get IEEE floating point correct, and there were some extremely smart people involved. Unlike FP, Scaled integer arithmetic is easy. The main thing that we do is addition. And that is the easiest to do. Actually, the hard part is getting the rounding done in the right places. A good FP package won't help there at all. Addition may be the main thing thing, but it's not the only thing. Even if you only do a multiplication/division/etc. once in a while, you've still got to do it correctly. For that reason, if we decide to drop doubles, I would rather use a library like gmp which has already been written/debugged rather than start from scratch. We've got too many other things to do. I have no problem using gmp when Int64 is not available. If we're going to use gmp sometimes, we should use it all the time. Mixing two libraries is just silly. dave -- This may not be a big deal for the total gnucash package - but using scaled integer arthimetic for the financial calculator and amortization schedule computations I am finalizing and getting ready to send to Dave is done totally in double. All of the calculations can probably be done in scaled integers, but the complexity will go up several orders of magnitude. log and exp functions are used and would have to be rewritten to use scaled integers. I don't know about gmp - does it contain log and exp functions. Also rewriting for scaled integers in the calculation of interest from the other valiables. I haven't looked closely, but from the top of my head, rewriting the Newton apprixmation starting point alone would not be trivial and would introduce much source for error. As long as doubles can be used - I think that staying with them would be the best for the calculator at least - unless someone very familiar with scaler integer arthimetic would volunteer to rewrite from the present source. Also, I would willing to bet that for some of the computations which are iterative in nature, the time delay introduction would be significant. Of course we can rely on faster H/W to alleviate the problem :-). Of course, the calculator could remain in FP and appropriate translations done on its input/output. Just my two cents worth. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, 16 Jun 2000, Terry Boldt wrote: This may not be a big deal for the total gnucash package - but using scaled integer arthimetic or the financial calculator and amortization schedule computations I am finalizing and getting ready to send to Dave is done totally in double. Typically, the calculations of compounded interest, etc. are done in FP and then multiplier by the money to yield a monetary answer. However, in computing an amortization schedule, the periodic interest is computed and converted to money. Then the actual amount of principal and resulting balance are computed (in money) to begin the next cycle. As a result, there will be a slightly different final payment to correct for the accumulated compounded rounding errors. Just my two cents worth. Did you mean 1.993 cents? -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
OT (was: denominating currency)
On Fri, Jun 16, 2000 at 08:14:41PM -0500, Richard Wackerbarth wrote: Did you mean 1.993 cents? I am Pentium of Borg. Division is futile! You will be approximated! :) -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Fri, 16 Jun 2000, Dave Peticolas wrote: Terry Boldt writes: using scaled integer arithmetic log and exp functions are used and would have to be rewritten to use scaled integers. No, the only operations that you do on money are Add money to money Subtract money from money Multiply money by a scalar and convert the result to money The only log functions that I see in the financial computations are to compute the scalar factor which is multiplied by the principal. I don't know about gmp - does it contain log and exp functions. It doesn't matter. The scalar factors would be computed in FP. Any refinement thereto can only be done by trial and error. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Richard Wackerbarth wrote: On Fri, 16 Jun 2000, Rob Browning wrote: So far, from everything everyone's said. I can't see one place where switching to some home-grown fixed point solution for the actual representation has *any* advantage over sticking with 64-bit floating point. The issue of when we need to round our values, and to what extent is AFAICT a *completely* separable issue from whether or not we represent them as floating point internally. So yes there may be times we need to round, but that's not related to whether or not we use doubles as the underlying representation, I agree that the underlying representation is not the problem. The problem is that people are bypassing the class wrapper and doing operations directly on these values. It is this misuse which is the problem. For example, if I add up a series of 10,000 transactions, I must convert the intermediate results back to "exact" money so that the error does not accumulate. I suspect that most often the "rounding" will be done by hand because you'll be entering the values yourself. If the groccery sells apples 3/dollar and you buy two, you'll get charged $0.67, and that's what you'll enter into gnucash. Well, gnucash is already messing up my brokerage account because of its mishandling of shares, prices, and amounts Remember that accounting is a COUNTING and counting is done in integers When bankers first used mainframes, some slick programmers established "hidden accounts" which received the tinsy fractional part of the interest, the part lost when rounding DOWN to integer pennies ... It wasn't much, but as it happen at the end of every day, on every savings account ... they made money for themselves. A case of one procedure for me, another for all the rest of you. :-) Another test: Try to verify the finance charges on your credit card statement(s). See if they all come up with exactly the same result for a data-set of scattered daily purchases ?? -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Quicken98(Mac) - gnucash import balance errors
-BEGIN PGP SIGNED MESSAGE- "Roland" == Roland Roberts [EMAIL PROTECTED] writes: Roland I'm still seeing this problem, but it has moved. Roland Yesterday's CVS corrected the problem with one closed bank Roland account, but another closed account now has a non-zero Roland balance. Well, the good news is that this is a Quicken error :-/ We've had a few Mac crashes in the past month that corrupted Quicken files which is supposedly recovered. However, since the account with the bogus balance was a closed account (hidden in Quicken), we never noticed the problem. Gnucash is reporting exactly what Quicken exported here. When I feel ambitious, I'll go pull a backup off tape to see if I can fix the account roland - -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhDUnix Software Solutions [EMAIL PROTECTED] 76-15 113th Street, Apt 3B [EMAIL PROTECTED] Forest Hills, NY 11375 -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQCVAwUBOUrjeOoW38lmvDvNAQHpzwP+PORtp8vMzxhgO23KRsLW1QrMeA53jrMi 40vGCjvZ8DxIXgGr1vUFfXh0pO/OmqM318yZ8Q8R8SQy2YzuE/oNyohdef1ybmAe 595Lwwq2euk6r188j68fkY9MWtSs87uCZdtrtb19Y0L20BMxYNHIyP0RCdA5VQoJ GaazaTg88EU= =S5kD -END PGP SIGNATURE- -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Needs of a currency arithmetic class (with proposed implementation)
Can someone tell me if I am missing anything here?
Needs of a currency class for GnuCash:
==
Assumption: Unless otherwise specified, all currencies are the same
denomination (all dollars, all lira, all pounds sterling, etc)
We must be able to add two monetary values with commutivity/associativit
y
We must be able to subtract two monetary values
We must be able to multiply a monetary value with an arbitrary real.
We do not need to be able to multiply two monetary values (i.e., square
dollars are meaningless).
We must be able to handle a large range of values precisely, ranging
from
$0.01 to $20,000,000,000,000.00 or more. For practicality, there must
be a maximum value, but at that maximum value, it -must- maintain
cent-level precision (or pence-level, or yen-level, or whatever the
minimum granularity for that denomination is).
The details of the denomination (such as precision, display
characteristics,
etc) can be kept separate from the actual values, because the
denomination
can be determined from context if needed (such as stored as part of the
account structure, etc).
Conversions between two different denominations will be done explicitly,
and the denomination-specific info and exchange rates can be specified
to any conversion routine.
===
I propose the following simple class for currency calculations:
class Currency {
g_int64 value;
public:
Currency(g_int64 v) { value = v};
Currency add(const Currency addend)
{ return new Currency( value + addend.value)};
Currency sub(const Currency subend)
{ return new Currency( value - subend.value)};
Currency mul(const double multend)
{ return new Currency( (g_int64) ((double)value*multend + 0.5))};
int comp (const Currency compend)
{ if (value compend.value) return -1;
if (value compend.value) return 1;
return 0;
}
}
inline Currency operator+ (const Currency addor,const Currency addend)
{ return addor.add(addend) };
inline Currency operator- (const Currency subor,const Currency subend)
{ return subor.sub(subend) };
inline Currency operator* (const Currency mulor,const double mulend)
{ return mulor.mul(mulend) };
inline Currency operator* (const double mulend,const Currency mulor)
{ return mulor.mul(mulend) };
inline int operator (const Currency compor, const Currency compend)
{ return compor.comp(compend) 0; };
etc...
I'll admit, I haven't written much C++ in a while and this is being
written off the cuff into a mail client, but I think I have the basics
down to add the functionality we want.
Please note: As long as we don't do any multiplication, this will
allow us to properly handle dollar values as large as
$92,233,720,368,547,758.07 without loss of precision. Assuming I have
the mantissa right, IEEE 64-bit FP will start to mess up around
$22,517,998,136,852.48 (+/- a factor of two or so). While $22 trillion
is probably "sufficient" for most purposes, it's nice to know that we
can go as high as $92 quadrillion if we need to...
So, what are the objections to this approach?
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
Needs of a currency arithmetic class (with proposed implementation)
Buddha Buck writes: So, what are the objections to this approach? 1) As to your specific implementation, it's in C++. I'm don't want to start a C/C++ flamewar here, but it's a major policy decision to introduce C++ into the GnuCash engine code, and C++ has several issues that make it a problem: a) The rest of the engine code is in C, as is most of the GUI code. Calling C++ code from C, while possible, is a pain, and you lose many of the benefits of the object-based features C++ provides. b) We don't currently have the ability to conveniently wrap C++ classes and make them available in guile. However, the concept of a Currency data type does have quite a lot of merit. I can think of *several* areas in the reports code that I'll have to check for rounding errors, and a currency data type is probably the appropriate vehicle for enforcing correct rounding practice. -- Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
