Re: RFC : Correcting some problems in rounding/number handling
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]
cvs 2000-07-08
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]
ADMIN: gnucash.org moving ; list will be flaky.
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]
denominators
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]
Re: RFC : Correcting some problems in rounding/number handling
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]
Re: denominators
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? humor Well, I won't "buy" that angle. Where did you buy your degree? Radian's already been sold. /humor 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: Units
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: RFC : Correcting some problems in rounding/number handling
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: denominators
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? humor Well, I won't "buy" that angle. Where did you buy your degree? Radian's already been sold. /humor 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] - http://www.ntlug.org/~cbbrowne/ "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: denominators
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? humor Well, I won't "buy" that angle. Where did you buy your degree? Radian's already been sold. /humor But not marked as such because I was unaware of the HTML humor tag. :-( Or is that a joke, too? :-) -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominators
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. humor ... /humor 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]
Question/problem with import of QIF file
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: Question/problem with import of QIF file
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]
Re: Question/problem with import of QIF file
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: what do we want to graph?
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]
[Bug report] Tab at auto completed Description crashes
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?
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]
Re: Question/problem with import of QIF file
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: Question/problem with import of QIF file
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: [Bug report] Tab at auto completed Description crashes
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: RFC : Correcting some problems in rounding/number handling
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: what do we want to graph?
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
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]
Edited fields in a transaction
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: Edited fields in a transaction
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]
Re: denominators
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]
