Stock sales
I am an accounting newbie and early adopter of gnucash, using it for personal accounting. I've been keeping track of a stock and a mutual fund with gnucash, and yesterday I sold some of the stock. Problem is, I can't find a way to record a sale! I have tried entering a negative buy and gnucash won't take it. Am I missing something? By the way, I also can't quite figure out how to account for capital gains; are those supposed to go in that suggested income account associated with the security account? -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Stock sales
On Thu, Apr 20, 2000 at 12:08:30PM -0500, Bill Gribble wrote: > > What does your register display for the stock account look like? If > the account is of type "stock" or "mutual", you should have a "Bought" > and a "Sold" column in the register. If you enter a number in the > Bought column it's a buy, in the "Sold" column it's a sell. > > If your register display doesn't show both columns, what version of > gnucash are you using? > Only a "bought" column; gnucash gnome version, 1.3.5, recently built for the .rpm source. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Stock portfolio accounting, splits, etc.
On Tue, Apr 25, 2000 at 01:13:03PM -0500, Matt Sisk wrote: > > So I had to dredge up or infer the split information from other sources, > since it was not immediately clear whether a particular buy or sell > order occurred on a (very) volatile day or whether there were subsequent > splits. I actually made some satisfactory progress on an algorithm to > automatically figure out the split ratio based on the high/low for that > date and the apparent discrepancy. This was not perfect however; I found > numerous examples that required explicit split records due to excessive > volatility. > M...when I did this job I simply went to the firm's web site and looked it up on their investor relations page. I would think that one could do that with most major firms these days; if not, a phone call would suffice. I would also think that the better on-line investment services would have this information...somewere. It occurs to me that there may not be, really, that many web stock information services. I suspect many brokerage houses are simply reselling services; this is definitely the case with my current broker, Deutsch Bank Alex Brown, whose on-line service is provided by Reuters. Maybe it would be possible to indentify the majors and support them...and then again, maybe not. > One can argue that retroactively reconstructing portfolio performance is > a waste of energy; from a practical standpoint this is correct. However, > a picture is worth a thousand words, and people like to look at > performance graphs. This is a feature -- *especially* if they are > porting their information from another financial package into something > such as gnucash. It would be nice to automate, however I think errors would would probably provoke howls of annoyance. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: 1.3.5 X memory leak?
On Tue, Apr 25, 2000 at 08:13:47PM -0500, [EMAIL PROTECTED] wrote: > You said you lost 1meg per transaction? I have an account with 3K > transactions in it, and when I open it, my x server doesn't grow > (although rss increases 12kb) > > ps aux > root 21957 1.5 16.2 27848 15452 ? S Apr 15 227:48 /etc/X11/X :0 > root 21957 1.5 16.2 27848 15464 ? S Apr 15 228:22 /etc/X11/X :0 > > also note: I burned over half a minute cpu time for this demo. I'm not > sure where to go next. > It seems to me I heard about a problem involving gnome/gtk/gdk and lots of X server memory a long time ago...maybe it was theme related? It would probably be worth querying the server resources to find out just where the memory is going. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Order of transactions
Is there any way to control the order of transactions within a day? With my check register, I get situations where gnucash sometimes posts large withdrawals before deposits, resulting in apparent negative checking balances. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Order of transactions
On Tue, May 02, 2000 at 06:16:34AM -0500, Richard Wackerbarth wrote: > > However, I don't think there is any satisfactory solution that will please > everyone. > For that reason, I think it would probably be best to make it possible for the user to determine the order. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Order of transactions
On Tue, May 02, 2000 at 08:51:17PM -0500, John Hasler wrote: > > >From an accounting viewpoint, the order of entries which all carry the same > date is irrelevant in any circumstance in which a gnucash is likely to find > herself. > Well, my specific problem is that I maintain both a paper and electronic check register. Without control over the order of entries I essentially have to reconcile the two registers. :( Now, maybe this isn't relevant to someone standing in an "accounting viewpoint," but it is relevant to my day-to-day needs. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Order of transactions
I was just discovering that I cannot control the placement of an "adjust balance" transaction in an account; if there are any other transactions on that day I cannot predict where it will fall or what it will leave the account balance. How is this supposed to be used? -- Randolph Fritz Eugene, Oregon, USA
Re: Order of transactions
[Resent--I misdirected this the first time.] -- Randolph Fritz Eugene, Oregon, USA On Tue, May 02, 2000 at 11:00:05PM -0500, John Hasler wrote: > > But you do have that control, don't you? They should stay in the order you > enter them in unless you give them dates and/or numbers that will cause > them to be sorted differently. > M...the problem is that if I make a mistake it's difficult to correct it. Once I, for instance, enter a large deposit after a large check, the only way to get the check to show up after the deposit is to delete it and re-enter it. It seems very inflexible. > By "irrelevant from an accounting viewpoint" I just meant that you should > be free to enter transactions that all have the same date in any order you > like: it won't affect your taxes or anything. H. -- Randolph Fritz Eugene, Oregon, USA
Re: Getting people to read the docs
On Tue, May 09, 2000 at 12:09:23PM -0400, Jesse D. Sightler wrote: > > That is not likely to work. :-) Help should be context sensitive, > and you should offer a "Wizard" like process for setting up accounts > if you are afraid that people are getting them wrong. > I think it's important to remember that many people do not like to study software manuals or accounting books, and a program which continuously reminds people to do so may be abandonded by these people. Assistants (wizards is a silly name :) are useable, I think. I'm not sure how much context-sensitive help is actually read. :( The Microsoft task-oriented help, in my experience, is sometimes useful, but is probablematic when the exact task one is looking for is not listed. ...perhaps some sort of automatically generated web FAQ? -- Randolph Fritz Eugene, Oregon, USA
Re: on-line banking & qif import
On Tue, May 09, 2000 at 12:50:09AM -0500, Linas Vepstas wrote: > > I was talking to someone about on-line banking & gnucash. I hadn't > thought about ti much, but a large part of on-line banking is > reconciling statements against what the bank has. Now, many 'online > banks' use QIF export as a way of sending statements to users. Sooo > (sound of lightbulb turning on) isn't the right way to import QIF files > is to run them through a reconcile-like dialogue? > > Anyone out there using gnucash and also looking at thier bank-staements > on-line? What do y'all think? > That's exactly what I am currently doing manually, once a week. My Credit Union can provide transaction records in QIF format, but there doesn't seem to be a good way to use them with GnuCash. One of the things I like about this combination of services is the amount of work it saves; errors are caught early, and there is no need to laboriously drag through a month or more of transactions to unsnarl mistakes. -- Randolph Fritz Eugene, Oregon, USA
Re: Getting people to read the docs
On Tue, May 09, 2000 at 06:14:27PM -0500, John Hasler wrote: > Randolph Fritz writes: > > I think it's important to remember that many people do not like to study > > software manuals or accounting books, and a program which continuously > > reminds people to do so may be abandonded by these people. > > No one I know likes to study software manuals or accounting books, but > perhaps it might be better to encourage those who refuse to do so to hire > someone to do their accounting for them. > Well, now you know someone, or at least 1/2 of someone; I like studying new software, if it's interesting and the manuals are reasonably accessible. :) I'll go along with encouragement, however I believe the typical Quicken user is just someone keeping their home accounts, and I doubt they will study accounting to use gnucash; I will not. That said, I will admit that I do not know the intended user group, or how they will respond. For best acceptance, I think some simple user testing is in order. Also, most people prefer to learn a tool by working with it, and if those people are to feel supported, the basic household functions of the tool had probably best be usable without study. This doesn't apply to business users, I would think. -- Randolph Fritz Eugene, Oregon, USA
Re: Customer feedback WAS Re: Database backend -- Was: Remarks on mail
On Thu, May 11, 2000 at 07:38:16AM -0700, Rob Walker wrote: > > yes, the size _has_ grown immensely, but I have just gotten back a > _feeling of control_, which is one of my personal reasons for using > Free software. I can now also use RCS on my files in a way I can read > (vs. rcs on binary files, which is confusing for me to read). > It's becoming customary to compress XML files, often with zlib, so I think size is not a major concern. Of course, you'd have to decompress them to store them with RCS. -- Randolph Fritz Eugene, Oregon, USA
OT: US securities brokerages?
Figured someone here might have a suggestion... I'm finally getting a round tu something I've needed to do for a while. Anyone know a good broker in the USA? Especially one with Pacific Northwest offices? -- Randolph Fritz Eugene, Oregon, USA
Re: gnucash 1.3.7 bugs.
On Mon, May 15, 2000 at 05:56:14PM -0700, Dave Peticolas wrote: > > Hi Jon, here is what happened. We recently discovered that we have > been using the terms 'debit' and 'credit' incorrectly in GnuCash. > In standard accounting practice, a debit is an increase in assets, > such as a deposit to a bank account, and a credit is a decrease in > assets, such as a payment, credit card charge, etc. > > Starting in 1.3.7, we began using the terms according to the sense > above, thus the change in column position of items in the reconcile > window. I apologize for any confusion. > Could someone tell me, please, the historical background of this odd use of language? If it's already been discussed, then please point me to the archives. -- Randolph Fritz Eugene, Oregon, USA
Reflections on reconciliation
I just reconciled my checking account for two weeks yesterday. It's interesting; the register used to be easy and the reconcilation hard. Now, with debit cards, keeping the register is difficult, and with on-demand statemnts, reconcilation is relatively quick and easy. Yesterday, I finished the reconcilation and put my usual note in the electronic register, indicating when I reconciled the account. It occurred to me that having this done automatically as part of the reconciliation process might be a Good Thing. Then it occurred to me that multiple lines might be better; the first indicating the beginning of reconcilation, the intermediate lines indicating the corrections to the register (following the basic principle that a journal is never changed without a record), then a closing line indicating that the account has been reconciled. What do you-all think? -- Randolph Fritz Eugene, Oregon, USA
Re: Reflections on reconciliation
On Wed, May 24, 2000 at 05:31:28AM -0500, Richard Wackerbarth wrote: > > Additions to the account ledger that are discovered during reconciliation are > not a part of the reconciliation itself. As such, they belong in their own > transactions which span multiple accounts. > I'm in agreement, but think that a mark indicating that the errors were discovered during reconcilation would be useful. Hence the idea of bracketing the corrections with indicating transactions. > As for the reconciliation itself, I would add a transaction which > has two entries "Ending Balance" and "Opening Balance". The > reconciliation would pick up the prior Opening Balance, include the > Ending Balance and leave the current Opening Balance for the next > reconciliation. There's already something like this, but it's invisible. -- Randolph Fritz Eugene, Oregon, USA
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]
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: RFC : Correcting some problems in rounding/number handling
On Wed, Jun 21, 2000 at 01:08:50PM -0500, Bill Gribble wrote: > > Actually, that's the question. If every account has a minimum > transaction unit, we need to enumerate what they are for every type of > account that gnucash can deal with. I'll start: I hypothesize that > banks don't do transactions in US Dollars with units smaller than > $0.01. Now you tell me about the limits on resolution of the number > of shares in a mutual fund account. > I believe, historically at least, banks have used "mils," or $0.001. They may use finer divisions now. Currently stock exchanges use sixteenths (or is it eights?), but there is talk of going decimal. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Thu, Jun 22, 2000 at 04:35:56AM -0500, Richard Wackerbarth wrote: > > Or get a computer that knows how to do decimal arithmetic. They used to make > those, you know. > IBM still makes them. I expect your phone bill is printed by one of them. :) -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Requirements for an integer-based value representation
I discussed this with an old banking software consultant I know; a man who worked at some of the big New York banks in the 80s--Citibank, Manufacturers Hanover, Chase. Turns out that they did their customer money computations, including interest computations, in fixed-point decimal, seven digits to the left of the decimal point, and four to the right (COBOL picture 999.). They used 999. for percentages and rounded to two decimals for output. Given inflation, I'd think that an extra digit to the left of the decimal point would probably be a good idea. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, Jun 30, 2000 at 01:19:03PM +0200, Ralf Gorholt wrote: > > perhaps I understand something wrong but I think one of the purposes > of operator overloading in C++ is to be able to write something like > "x = y + z" instead of "gnc_money_plus(x, y, z)", even if the "+" > operator does complex, not necessarily arithmetic operations instead > of just a simple addition. At least I use it that way... > Can't scheme be made to do that? I mean, it knows enough to overload arithmetic operators for integer and floating-point already. Wouldn't this just be another numeric type? -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
In the hope of shedding some light on this problem, I did a bit of research on actual practice, covering several widely-used major systems. Here's what I found out: IBM big iron--s/360/370/380/390, AS/400, COBOL, PL/I, DB2. Fixed-point decimal with a max. of 31 digits. The decimal point may be to the right or left of the significant digits. JavaThe java.math.BigDecimal class; infinite precision fixed-point decimal. One needs to specify the type of rounding for each division; I assume that the intention is that BigDecimal would be subclassed. IBM offers an alternative-- com.ibm.math.BigDecimal--which provides decimal floating point as in REXX. mSQLFloating point, radix and precision unknown. MySQL Fixed-point decimal, precision unknown. Oracle Fixed-point decimal, precision unknown. REXX (IBM interpreter, similar in function to Perl or Python.) Settable-precision floating-point decimal. Comparisons are blurred by a "fuzz." I think all the big banks use the big IBM servers; it seems to me that gnucash could profit by building on the datatypes that they use. R. IBM big iron <http://www-4.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/document.d2w/report?fn=db2v7s0varstrt.htm#Header_124> Java <http://java.sun.com/j2se/1.3/docs/api/java/math/BigDecimal.html> mSQL<http://www.hughes.com.au/library/msql/manual_20/api.html> MySQL <http://www.mysql.com/documentation/mysql/bychapter/manual_Reference.html#Numeric_types> Oracle <http://www.uwp.edu/academic/mis/baldwin/oraddl.htm> REXX <ftp://service.boulder.ibm.com/ps/products/ad/obj-xx/rexxref.pdf> -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, Jul 07, 2000 at 01:11:20AM -0500, Richard Wackerbarth wrote: > > Commodities are counted. That, by definition, means that they are represented > by an integer. If you must use a rational, the denominator is always unity. > Unless they're sold by the foot--like lumber, fabric and wire, the pound--like nails, iron, and sugar, or the gallon--like milk and gasoline. > Remember that we count CENTS and not DOLLARS. The fact that you choose to > represent a large sum of CENTS by the equivalent DOLLAR amount is an artifact > of the display rather than anything intrinsic to the counting process. Well, we may...but banks count hundreths of a cent. I think you are trying to find mathematical perfection in commerce, and I have some doubt of the enterprise. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, Jul 07, 2000 at 07:39:36AM -0500, Richard Wackerbarth wrote: > > That is not COUNTING. That is MEASURING and PRICING. > > And by the time the transaction gets past the cash register, that measure has > been converted to a countable quantity. > hunh? I mean, the last time I bought half a yard of fabric, the cutter wrote half a yard on a slip, computed a price, and I took that to the cash register. > Besides, "milk" and "sugar" are poor examples. They are seldom sold by the > gallon (pound) but rather by the "container". And the price of two > "half-gallon containers of milk" is not the same as that of "one one-gallon > container of milk". Please go to the store and purchase 1/3 gallon of milk > for me. Only at the retail level--gnucash is supposed to work for business, too, no? > > > Not in my bank account. The balance is ALWAYS an exact multiple of one cent. > Even when I earn $1.5748 in interest each month, those fractional cents NEVER > accumulate to give me that additional cent. > According to my banking consultant friend, the major US banks he worked for (Chase, Manufacturers Hanover, Citibank) did all their dollar computations to four decimals of precision and rounded to two for output; he mentioned GM as one of the customers whose accounts this applied to. Has the practice changed, then? > Besides, if you can find a ledger that records hundreths of a cent, then you > simply denominate it in that "smallest countable unit". Perhaps then for money four decimal points of precision (if rounding after every computation is to the nearest 1/10,000th) is sufficient? -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, Jul 07, 2000 at 01:51:35PM -0500, Richard Wackerbarth wrote: > > Right. And the dry goods were either measured in units of (3 inches) or > greater or no effort was made to account for the individual amounts sold. > > Particularly in a business such as dry goods, the amount that you actually > receive does not match the amount for which you were charged. The merchant > has figured this waste into the price he charges. > I just bought some velcro ribbon...trust me, the amount I actually received matches the amount I bought to within at most 1/4". If I was buying wide vellum from an art supply shop, it would be within 1/16". > > For such a merchant, it is far simpler to estimate the amount sold until he > takes a physical inventory of what remains and makes the adjustment necessary > to bring the inventory into balance. > Yes, yes. However the receipt I have, which is the merchants's original transaction document, is written in yards. This merchant is measuring (rational numbers) rather than counting (cardinal numbers), and keeping track of cash at their register. One of the ways in which the widespread availability of computers transforms traditional bookkeeping practice is that jobs which were previously back office are now done in real time at the cash register. This, to me, suggests that gnucash might be more useful to these merchants if it accomodated the way the merchants do business, rather than requiring the merchant to do conversions into a traditional accounting form. I wonder...do you think that the ability to compute an approximate inventory at any time would be of value to, say, a small fabric store? It seems to me it would be helpful in maintaining inventory. > > > > According to my banking consultant friend, the major US banks he > > worked for (Chase, Manufacturers Hanover, Citibank) did all their > > dollar computations > > Computations are intermediate results which are never entered in the ledger. > > > to four decimals of precision and rounded to two for output; > > It is only this rounded result that gets posted to the ledger. > My consultant confirms this. I stand corrected. > > > Perhaps then for money four decimal points of precision (if rounding > > after every computation is to the nearest 1/10,000th) is sufficient? > > We should make no such assumption. > Why not? Seriously, if the big banks do it, does gnucash need to do more? Compute with four decimal places, store two, and stop agonizing over it. > > For example, before decimalization, it would have been 1/240 Pound Sterling. > I think that someone indicated that it is 0.05 Swiss Franc, etc. > H...I wonder how international banks handle the problem. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, Jul 07, 2000 at 05:12:17PM -0500, Richard Wackerbarth wrote: > > But "computing with four decimal places" MAY be harder than doing it more > accurately. The banks are probably doing the calculations in BCD. Although we > can, I don't think that is the likely implementation. > > Remember, if we design things properly, we can change the internal > representation without having any real effect on the bulk of the system. > In bookkeeping practice representation and mensuration are intertwined. Historically, business computing has dealt with this problem by the simple expedient of using BCD, which also has the advantage of being understood by bookkeepers who program in COBOL. In principle this can also be dealt with by sub-classing the rational numbers, however, subclasses proliferate. At the very least one is likely to end up with with a fixed-precision decimal subclass that looks very much like BCD--Java's BigDecimal or SQL's NUMBER, in other words. It's going to take considerable effort to make rounding and overflow work in the way that bookkeepers and customers expect, and I believe that meeting those expectations is important--if nothing else it makes for more accurate and simpler export and import of data. > And gold chain even closer. :) To the gram, I believe. Or even the tenth thereof. > > So what? Each item has its own "smallest unit of measure" and there is some > approximation made when the larger inventory is partitioned into the portion > that you purchased and that which you did not. > > [...] > > Just because we display "1 1/3 yards" doesn't mean that we cannot store the > transaction as "48 inches" > Sure. As long as the merchant sees that they are measuring and rounding. > > See above. Input and Output do not have to be in the same units as storage. > If I were building a cash register for the dry goods store, I would certainly > include keys for 1/2, 1/3, 3/4, etc. Or at least have some input convention > that allowed it. > unh-hunh. I found out that those numbers were once considered important enough to have a special name; they are called aliquot parts, which I think is a really cool-sounding, and otherwise obsolete, word. :) > > Remember that the requirement is only that I be able to handle the amounts. > Um, don't you mean the program be able to handle the amounts? > Most banking applications are defined in terms of the character fields of the > I/O record. They rarely use binary because the I/O conversion dominates the > math. Isn't this more of a historical consideration? Since the S/370 family, at least, conversion has been relatively cheap. However, the accounting/bookkeeping expectation of decimal arithmetic remains. -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
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]
