Re: Needs of a currency arithmetic class (with proposed implementation)
Buddha Buck writes: Can someone tell me if I am missing anything here? 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? We can't assume that every architecture will have a 64-bit integer. For that reason, and for the simple fact that if we are going to go to the trouble of doing this, we might as well go all the way :), I think we should use gmp's multiple precision integers. Then, it will work on all architectures, and we can say that gnucash can support values of arbitrary size. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Needs of a currency arithmetic class (with proposed implementation)
Dave Peticolas writes: Buddha Buck writes: Can someone tell me if I am missing anything here? 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? We can't assume that every architecture will have a 64-bit integer. For that reason, and for the simple fact that if we are going to go to the trouble of doing this, we might as well go all the way :), I think we should use gmp's multiple precision integers. Then, it will work on all architectures, and we can say that gnucash can support values of arbitrary size. Oh yes, and it needs to be in C (I'm assuming your proposal was mainly for pseudo-code purposes). dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Needs of a currency arithmetic class (with proposed implementation)
Dave Peticolas writes: We can't assume that every architecture will have a 64-bit integer. For that reason, and for the simple fact that if we are going to go to the trouble of doing this, we might as well go all the way :), I think we should use gmp's multiple precision integers. Then, it will work on all architectures, and we can say that gnucash can support values of arbitrary size. Oh yes, and it needs to be in C (I'm assuming your proposal was mainly for pseudo-code purposes). It will make the code a little uglier, but no uglier than any fixpoint arithmetic library we build ourselves. Oh, and the other nice thing about GMP is that it's pretty fast. I used it extensively in my honours thesis, and it crunched through several-hundred-bit integer division in quite reasonable time :) -- Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Log File behaviour
On Thu, Jun 15, 2000 at 07:41:29PM -0500, Richard Wackerbarth wrote: 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? Furthermore, while the main file is being written, there is no valid copy of the data? Surely at least the backup files should be written _before_ the main file is modified. --Dylan Thurston [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Needs of a currency arithmetic class (with proposed implementation)
On Fri, 16 Jun 2000 23:01:21 MST, the world broke into rejoicing as
Dave Peticolas [EMAIL PROTECTED] said:
Buddha Buck writes:
Can someone tell me if I am missing anything here?
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?
We can't assume that every architecture will have a 64-bit integer.
For that reason, and for the simple fact that if we are going to go to
the trouble of doing this, we might as well go all the way :), I think
we should use gmp's multiple precision integers. Then, it will work on
all architectures, and we can say that gnucash can support values of
arbitrary size.
_Can't_ we assume 64 bit integers?
a) glib provides gint64. It also offers the option of not supporting
that type, but widely offers it.
b) GCC provides long long. On 32 bit architectures, no less.
c) Even Plan 9, about as different from *BSD, Linux, Solaris, and AIX as
it gets, supports 64 bit integers.
d) How about we do a survey? Put a sample file into the sources that
tests for existence of 64 bit ints. If the survey finds no
64-bit-less platforms, I strongly doubt that many will get _added_.
I would strongly argue _against_ gmp: It means that money values are
no longer of fixed size. Which seems a thorny problem to me; that
means there's _no_ option of putting them into SQL databases, except
via encoding them into VARCHAR fields, and losing all ability for the
DBMS to support calculations. I don't think we should be doing this
_soon_, or necessarily _ever_; just be aware that "going gmp" destroys
the possibility of doing:
select sum(amount) from txntable where account = "Checking Account";
Likely a more practical question: how do we cope with variable size
representation when we decide to add in a CORBA interface? Note that
CORBA provides, as standard, in 2.3:
a) long long, which is the C/C++ 64 bit type, as well as
b) fixed size,scale, a type designed for money.
for instance:
typedef fixed15,2 money;
will provide a fixed-at-compile-time structure thus:
typedef struct
{
CORBA_unsigned_short _digits;
CORBA_short _scale;
CORBA_char _value[8]; /* 8 = ceiling(15/2) */
} CORBA_fixed_15_2;
Note: This code fragment was generated by orbit-idl, so
this functionality is _decidedly_ supported by GNOME-based
apps.
Floating point systems are indeed problematic to "prove right;" you need
Ph.Ds in numerical analysis for that. Verifying that integer-based
schemes calculate right is a much more modest requirement; we can use
Peano axioms and induction to establish the properties we need, and it's
_not_ an incredibly hard thing to verify that the basic operators +, -,
and * work properly, with some well-defined rounding rules.
I think the only reasonable alternatives _are_ "long long" and
some form of "fixedsize,scale". CORBA supports them; DBMSes are
moving to support them; GCC supports them to some extent. gmp is
interesting, but I think it's no alternative to these.
--
[EMAIL PROTECTED] - http://www.hex.net/~cbbrowne/
Rules of the Evil Overlord #154. "I will instruct my Legions of Terror
in proper search techniques. In particular, if they are searching for
escapees and someone shouts, "Quick! They went that way!", they must
first ascertain the identity of this helpful informant before dashing
off in hot pursuit." http://www.eviloverlord.com/
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Needs of a currency arithmetic class
On Sat, 17 Jun 2000, Christopher Browne wrote: _Can't_ we assume 64 bit integers? No, you should assume that there is a struct definition. Period. I would strongly argue _against_ gmp: It means that money values are no longer of fixed size. Although I strongly agree that gmp is of any real value in the implementation, "variable size" is not a real reason because the class should provide the mechanisms to handle ALL allowed operations. Conversion to/from storage formats is a part of that. Floating point systems are indeed problematic to "prove right;" basic operators +, -, and * work properly, with some well-defined rounding rules. gmp is interesting, but I think it's no alternative to these. Further, gmp does nothing to help "prove" the correctness of the monetary calculations. And that is the harder part of "getting it right" At least in theory, the implementation of this class should not be visible to the outside world. If I am in a CORBA world, I might import a different set of definitions from those that I use somewhere else. The gnucash code should not care that I choose BCD, or int64, or FP as long as I get the implementation correct. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Needs of a currency arithmetic class (with proposed implementation)
On Fri, Jun 16, 2000 at 10:56:29PM -0400, Buddha Buck wrote: 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). You need to provide casts to double, long double, or g_int64, at least, because there do exists cases where you want to *divide* currencies with each other, particularly in managerial accounting where you want to find figures like return on equity, return on investment, asset turnover, etc. Either that or you need to be able to divide currencies with each other. 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... Well, 22 trillion Italian lire is "only" about 11 billion (US) dollars (US) the last time I looked, which is probably more than what the entire membership of this mailing list will see in our collective lifetimes, but is not enough if you eventually want gnucash to be taken seriously by mega-corporations like Fiat or the Italian government. Korean won is approximately in that range as well, and Hyundai will probably want their accounting system to count higher than about 20 billion dollars. So that's yet another strike against double--it tops out at values that may possibly become relevant. Of course, it'll be years before gnucash can be taken seriously by Fiat in any case, but you might as well do things right to begin with. So, what are the objections to this approach? Well, for one thing, it's in C++ and gnucash is in C. :-) But I'll let other people play the language advocacy game. It's worth noting, though, that object-oriented programming is possible in C, and one needs to look no further than gtk for an example. So that alone is not a good enough excuse to rewrite gnucash in another language. -- Shimpei Yamashita http://www2.gol.com/users/shimpei/ -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Needs of a currency arithmetic class
On Sat, 17 Jun 2000, Shimpei Yamashita wrote: Well, 22 trillion Italian lire is "only" about 11 billion (US) dollars (US) But what is the smallest amount that accountants use for commerce? IOW, if I sell something for 1/3 million lira, exactly how many will be posted to my banking account. For example, 1/3 million $US would result in $333,333.33 being deposited. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Default actions in non-bank accts
Is there a reason why credit accounts do not have some of the same default actions (or at least a subset) that bank accounts do? i.e: Credit, Online, AutoDebit.. -e -- Ed Porras [EMAIL PROTECTED] http://www.cise.ufl.edu/~ep -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Richard Wackerbarth [EMAIL PROTECTED] writes: 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 Repeating this example doesn't make it any more relevant. This is a straw man. Gnucash isn't responsible for computing how much the store charges you; you enter $2.00, or $2.01, whichever your receipt tells you. Buddha has repeated an example of a repeating transaction with interest computation. Another straw man. It is not gnucash's job to completely and accurately model *any* other financial process. If you mis-calculate an interest payment by a penny, then your repeating transaction will be off by a penny, and you catch it in the reconciliation step. We should do the best job we can, but going from a simple straightforward solution to a complicated one involving arbitrary precision computation to fix this problem is going to need some better support than this to get my vote. My former employer had a rounding issue with my paycheck, which alternated between having twenty-two and twenty-three pennies on the amount. Is gnucash suppsed to know without being told which month will be .22 and which will be .23? No. Repeating transactions are a convenience function. Bill Gribble -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Default actions in non-bank accts
Ed Porras writes: Is there a reason why credit accounts do not have some of the same default actions (or at least a subset) that bank accounts do? i.e: Credit, Online, AutoDebit.. Nope. I'll add some. Off the top of my head, it should also have: Credit, Fee, Int (interest), Online, and ATM. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
On Sat, 17 Jun 2000, Bill Gribble wrote: Repeating this example doesn't make it any more relevant. This is a straw man. Gnucash isn't responsible for computing how much the store charges you; you enter $2.00, or $2.01, whichever your receipt tells you. But every time I make the entry, gnucash is changing the price. THE PRICE DID NOT CHANGE. PERIOD. If you would accept the price as 3 for $2.00 and accept that I purchased 1 and accept that I paid $0.67, When you stand a chance of getting it right. The way that you neither round nor accept imbalance DOES NOT WORK. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Richard Wackerbarth [EMAIL PROTECTED] writes: But every time I make the entry, gnucash is changing the price. Please describe how you made the entry you describe below. I'd like to try to reproduce it myself. If you would accept the price as 3 for $2.00 and accept that I purchased 1 and accept that I paid $0.67, b.g. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
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. :-) I heard of this story, too, back in the 70's. Apparently the programmer inserted this into the program he was writing, and placed the stray pennies into his own account. (The pennies originated from him rounding up on one end of a transaction and down on the other). After a while, the bank wondered where their breakage was. It seems the bank had also been doing this themselves, and now this revenue stream mysteriously disappeared when they automated. They tracked down the code, and found the programmer's bank account number... -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Display order of Deposits vs. Withdrawals in Register window
I just tried out the Gnucash 1.3.99 developers release and I have to say that I was very impressed. Great job all !! However, I have come across a slight issue with regards to how Gnucash displays transactions for deposits and withdrawals. For example, if I make both a deposit and a withdrawal on the same date, the withdrawal transaction is displayed before the deposit transaction. I think that this is not very intuitive because one would expect for deposits to be displayed first (as my bank does). I hope this issue can fixed before the 1.4 release. -- Regards, --- Kevin Reid We captured it so we now control it. --- -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Randolph Fritz [EMAIL PROTECTED] writes: Every time interest is computed. But right now we never compute interest. You *hand enter* the value. However, as I said before. I agree that there are going to be times when we need to round, but that doesn't have anything to do with the underlying representation, as long as that representation has sufficient range and resolution. That's the main thing we should be concerned about, and, as I've mentioned, IMP gmp is the right place to start looking if we decide doubles aren't good enough. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Display order of Deposits vs. Withdrawals in Register window
Kevin Reid writes: I just tried out the Gnucash 1.3.99 developers release and I have to say that I was very impressed. Great job all !! Thank you. However, I have come across a slight issue with regards to how Gnucash displays transactions for deposits and withdrawals. For example, if I make both a deposit and a withdrawal on the same date, the withdrawal transaction is displayed before the deposit transaction. Transactions with the same date are displayed in the order you enter them, unless they have a non-blank 'Num' entry, in which case they are sorted with that. I think that this is not very intuitive because one would expect for deposits to be displayed first (as my bank does). But not all banks do. My bank's statement has deposits in a completely separate section, after the withdrawals. In general, different banks use different orders. You can change the default sorting order, but right now there are only a few choices and the balances still reflect the GnuCash 'canonical' ordering. I hope to make this more flexible in the future. I hope this issue can fixed before the 1.4 release. Sorry, but given that it's being released tomorrow, it's not really a possibility. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Adding Palm Support
Folks, I'm new so please excuse if I've missed something. I was reading the thread regarding Palm support. I use a shareware Palm application called Pocket Money from http://www.catamount.com. It is much more capable than the Palm expense application, and the writer has published the database format. Under Windows Mac there are conduits to Quicken and MyM. At this time there's no easy way to upload the data on Linux - one has to use "backup" in JPilot, for example, and then there's no tool for accessing the data. I wrote to the writer (I can't find his name just now...) regarding Linux/Unix support. He said the reason he published the database format was to support several people who have expressed an interest in building a Linux front end to his software. He hasn't heard back from any of them at this point. Pocket Money is AFAIK the most substantial and useful money management tool on the Palm. It's really quite surprising how well it works. If someone wants to build an interface, it would not be a bad thing to start with the ability to read in PM's database format (called "PM Financial Posting Standard" or PM-FPS by the author) Gary Bickford -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Buddha Buck [EMAIL PROTECTED] writes: 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. Except that there's the practical argument to be made. *If* doubles are for for all intents and purposes accurate enough that we wouldn't ever notice the difference between them and a scaled integer representation, then the current solution using doubles has the *vast* advantage of existence and simplicity, and if doubles really are functionally equivalent, presuming we round at the right times, they also allow more flexibility. If we decide we *need* to represent 1/3, we can (more or less), whereas with the integer representation, we'd be stuck. 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? In the abstract, I understand the point you're making here, and I tend to agree with you, but I'm having a hard time thinking of a time where an equality test like this would be meaningful. That doesn't mean there aren't plenty of times like that, though. 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)? I would maintain that the code doing the "automatic splitting" would be responsible for the rounding, or does that not solve the problem? -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Adding Palm Support
Gary Bickford [EMAIL PROTECTED] writes: At this time there's no easy way to upload the data on Linux - one has to use "backup" in JPilot, for example, and then there's no tool for accessing the data. Are you sure there's no export tool? I used the Newton version of PocketMoney for years and on that version was a simple dump tool that exported your accounts as QIF files (I think he called it "ExCHANGE") In fact that's why I rewrote the gnucash QIF importer originally (to import my personal QIF files exported from PocketMoney). Bill Gribble -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Adding Palm Support
Bill Gribble wrote: Gary Bickford [EMAIL PROTECTED] writes: At this time there's no easy way to upload the data on Linux - one has to use "backup" in JPilot, for example, and then there's no tool for accessing the data. Are you sure there's no export tool? I used the Newton version of PocketMoney for years and on that version was a simple dump tool that exported your accounts as QIF files (I think he called it "ExCHANGE") In fact that's why I rewrote the gnucash QIF importer originally (to import my personal QIF files exported from PocketMoney). Bill Gribble There are conduits (for both MYM and Quicken, I think) for Mac and Windows, but not for Linux. This is "not my area of expertise", but if I understand correctly, there's really two components, syncing the files on the Palm and on the workstation and syncing those files with GNUCash. These could be in one application. I suppose ideally there would be some way to use JPilot or one of the other Linux/Unix pilot programs to talk to both GNUcash and PM. But again this is outside my knowledge. GB -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Dave Peticolas [EMAIL PROTECTED] writes: Terry Boldt writes: 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 totall in double. All of the calculations can probably be done in scaled integers, b 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. Glancing through it's info pages, it doesn't appear to. The power functions are there. See mpz_pow*, and so are the square root functions, but I don't see any logarithms available directly. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Invalid option `-Werror-implicit-function-declaration'
I've just tried compiling the latest CVS version on FreeBSD 3.4 In both configure and compiling, I get the error: cc1: Invalid option `-Werror-implicit-function-declaration' For example, an excerpt from config.log: configure:5461: checking for XpmReadFileToXpmImage in -lXpm configure:5480: gcc -o conftest -O -pipe -Wall -Werror-implicit-function-declaration -I/usr/local/include -I/usr/X11R6/include conftest.c -lXpm -lX11 -L/usr/X11R6/lib -lXext -lXmu -lXt -lX11 -L/usr/local/lib -L/usr/X11R6/lib -lm 15 cc1: Invalid option `-Werror-implicit-function-declaration' Removing it from CFLAGS seems to solve the problem. Matt -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
