Re: cvs 2000-05-08
I've been lurking here all of three days :-))) ... but have attempted to install gnuCASH twice in the last six months. Robert Graham Merkel wrote: > > Dave Peticolas writes: > > > > CVS has been updated. > > > > New Stuff: > > > > + Applied Rob Browning's patch to break out g-wrap. > > > >NOTE 1: Before you update, remove src/guile/gnucash.h > >You can also delete lib/g-wrap, lib/g-wrap-install, > >and lib/g-wrap.configure. > > > >NOTE 2: You will need to install the g-wrap module, available at: > > > >ftp://ftp.gnucash.org/pub/g-wrap/g-wrap-0.9.1.tar.gz > > > >You only need g-wrap if you are compling from source. > > I'm building a g-wrap .deb, an experimental one should be available > RSN. > > > Robert Merkel [EMAIL PROTECTED] > >
Re: cvs 2000-05-08
I've been lurking here all of three days :-))) ... but have attempted to install gnuCASH twice in the last six months. It seems my libeguile doesn't get recognized. At Saturday's InstallFest here in Anchorage, there were three networking gurus trying to help me get an install (both rpm and compile). One suggested that my Gnome was incomplete, that maybe a SuSE 6.4 reinstall might be worth more than the upgrade I did last week. Is there a SuSE person here who would contact me off-list so I don't plug up things here? Stanley Long Anchorage, Alaska Robert Graham Merkel wrote: > > Dave Peticolas writes: > > > > CVS has been updated. > > > > New Stuff: > > > > + Applied Rob Browning's patch to break out g-wrap. > > > >NOTE 1: Before you update, remove src/guile/gnucash.h > >You can also delete lib/g-wrap, lib/g-wrap-install, > >and lib/g-wrap.configure. > > > >NOTE 2: You will need to install the g-wrap module, available at: > > > >ftp://ftp.gnucash.org/pub/g-wrap/g-wrap-0.9.1.tar.gz > > > >You only need g-wrap if you are compling from source. > > I'm building a g-wrap .deb, an experimental one should be available > RSN. > > > Robert Merkel [EMAIL PROTECTED] > >
Re: denominating currency - was: non-functional 'if clause
Ben Stanley wrote: > > Hendrik Boom wrote: > > > I've always been doubtful about the use of floating point by gnucash. > > The problem with floating point types is that they only provide an approximation to > what you want. > [ snipped ] > > 1/2 = 0.5 > 0.1, so we have 0 * 2^-1. > 1/4 = 0.25 > 0.1, so we have 0 * 2^-2. > 1/8 = 0.125 > 0.1, so we have 0 * 2^-3. > [ snipped ] > results.) However, in a financial application, we need to reliably track every last > cent (or penny, or yen, or whatever). Thus, I feel that the double type is > eminently unsuitable. > > What's the solution to this problem? > > I will first mention a historical solution - this probably bears little relevance > to what we should do, but anyway... > > I seem to remember that the 6502 microprocessor, which was used in the C64, > had a >BCD flag. When it was enabled, it entered a special mode, where all > math operations assumed that each byte held 2 decimal digits, ... [ snipped ] > > Alternately, integers have no rounding error. However, they are susceptible > to overflow. Their range is ... > PL/I tried to do EVERYTHING that had been done before. Even the subset used on CP/M boxes (ie, S-100) had integers, floating point, and BCD (Binary-Coded-Decimal). The subset left out Complex :-(( "money" problems could be worked in BCD, even if they were part of an engineering calculation that was mostly floating point. Financial presentations meant to rank wished-for projects can be done in floating point, even the net-present-worth stuff, because the overall approximation is good enough. Monthly credit card interest charges may have internal rounding, but the month end is rounded to $0.01. Corporate Accounting departments are leary of engineers who make shortcut (but useful :-) math routines for keeping track of money!! Stanley Long, PE Consulting Electrical Engineer Anchorage, Alaska -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
Richard Wackerbarth wrote: > > On Fri, 16 Jun 2000, Rob Browning wrote: > > > So far, from everything everyone's said. I can't see one place where > > switching to some home-grown fixed point solution for the actual > > representation has *any* advantage over sticking with 64-bit floating > > point. > > > The issue of when we need to round our values, and to what extent is > > AFAICT a *completely* separable issue from whether or not we represent > > them as floating point internally. > > > So yes there may be times we need to round, but that's not related to > > whether or not we use doubles as the underlying representation, > > I agree that the underlying representation is not the problem. > The problem is that people are bypassing the class wrapper and doing > operations directly on these values. It is this misuse which is the problem. > > For example, if I add up a series of 10,000 transactions, I must convert the > intermediate results back to "exact" money so that the error does not > accumulate. > > > I suspect that most often the "rounding" will be done by hand because > > you'll be entering the values yourself. If the groccery sells apples > > 3/dollar and you buy two, you'll get charged $0.67, and that's what > > you'll enter into gnucash. > > Well, gnucash is already messing up my brokerage account because of its > mishandling of shares, prices, and amounts > > Remember that accounting is a COUNTING > and counting is done in integers > When bankers first used mainframes, some slick programmers established "hidden accounts" which received the tinsy fractional part of the interest, the part lost when rounding DOWN to integer pennies ... It wasn't much, but as it happen at the end of every day, on every savings account ... they made money for themselves. A case of one procedure for me, another for all the rest of you. :-) Another test: Try to verify the finance charges on your credit card statement(s). See if they all come up with exactly the same result for a data-set of scattered daily purchases ?? -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Mandrake 7.1 install problems
Dave Peticolas wrote: > > Jeff Lapsley writes: > > Greetings, > > > > First, I apologize in advance if this is covered somewhere... I really did > > diligently try to find this is the archives and elsewhere, and did manage > > to fix part of it. [ snipped ] > > What guile problems did you get compiling from source? Installing from > the rpm is going to be problematic, since there seem to be so many > differences in library versions between RH6.2 and MDK7.1 > > dave > I am an electrical engineer, doing power and lighting designs for building construction. not much of a programmer ;-) Dave, could you (or some of the others) give me pointers to documentation on constructing RPM packages? The RPM manual is not enough ... SuSE presents me with problems that are similar to Jeff's; often my libraries have higher revision numbers than are being requested. I do like the directory of installed packages left by RPM installs, and suspect that I had better bite the bullet and do some serious learning. The Filesystem Hierarchy Standard is printed out as a starter. Off list replies are welcome, especially from those who worry about being redundant. Redundancy is a wonderful teacher! Stanley Long Anchorage, Alaska -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Proposal for modifying gnucash to use exact quantities
Buddha Buck wrote: > > At 09:29 AM 7/25/00 -0500, you wrote: > >Clark Jones <[EMAIL PROTECTED]> writes: > > > I hate to quibble with Gribble :-), but in actuallity the bill establishing > > > the Dollar as the U.S. currency (written by Thomas Jefferson) > > > > defines the "mill" -- which is 1/1000 of a U.S. Dollar -- though > > > the only places where you're likely to run into it is at the gas > > > pump and calculating real estate taxes. > >> [ snip ] > Although the mill is a defined denomination, the US Government has > > never minted or printed any currency in that denomination. The > closest that they have come is the half-cent piece, which technically > was denominated in (fractional) cents, anyway. > >From sometime during World War II, Washington State had a 3-1/3% sales tax. The state stamped aluminum "tax tokens" about the diameter of a quarter ( yep, :-)) but thinner. They had a hole in the center, so kids in the 50's would thread them on strings. Yes, grocers collected and distributed the 1/3 cent pieces with each transaction. > > But pricing is weird anyway. Jon Trowbridge (sp?) has already pointed out > that some markets report prices in units of 1/8 cent/bushel. > > >b.g. > > ___ > gnucash-devel mailing list > [EMAIL PROTECTED] > http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: QIF importer in 1.4.7 fails to detect duplicate transactions
- one Anchorage vote to keep QIF importer discussions on list :-) Dave Peticolas wrote: > > Derek Atkins writes: > > Should we take this to private mail and stop deluging the list? > > ... I'm finding the discussion very > informative. This is a devel list after all, so I think it's fine. > > dave > ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: GnuCash Concept Guide
Bengt Thuree wrote: On Fr, 2006-04-07, 17:14, David Grant skrev: On April 6, 2006 11:59 pm, Bengt Thuree wrote: On Fr, 2006-04-07, 14:10, David Grant skrev: On April 6, 2006 08:40 pm, Chris Shoemaker wrote: If not, I think the advantage of wider editing of the docs out-weighs the disadvantage of having to manually reformat them for offline use. Good point, [ snipped a bit ] gentoo-wiki.org has done in only a short time to image what gnucash's docs could look like. Ok, I converted (very quickly) the Overview chapter, [snipped some more] But do not know how to fix so chapters/section numbers are ok over files? /Bengt Could Docvert offer something here? http://holloway.co.nz/docvert/ " This web service software takes multiple word processor files (typically .doc) and converts them to Oasis OpenDocument." ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register data entry still broken; detailed keypress steps
Christian Stimming wrote: Hi all, Chris started the honorable effort to eventually fix http://bugzilla.gnome.org/show_bug.cgi?id=327780 . This is great. However, it also means that since r13844 the normal data entry in the register is broken in many view styles. I thought I'd give an as clear description as possible about what I observe here -- this is mostly for Chris, I guess. Here's what I did: Open the account register with the preference view style "basic ledger" so that it is in "basic ledger" mode. I click in the date cell of the bottom-most transaction line, the empty line. I select a date with '+' and '-'. Then I press to have the cursor in the description cell. I enter the first letters of a previous transaction, until the quickfill quickly fills :-) the rest of the transaction. I press to accept the quickfill. The cursor is now in the amount cell (here: "Spend" because of Cash register). I enter "2" as the amount. Now I can do many different things. Let's number the possibilities: #1: I press (the normal "Return" key, not the keypad one). From the data entry person's view, this was a good thing in past versions; key in the initial digits and enter. This was a loop for skipping the entry of decimal separator and two zero key presses. Only a second "enter" key press committed the line. Thanks you all for your work. Stanley, mostly just lurking, but I just completed entry of a past year as a start and a system verification for a sole proprietor consulting business coordinated with personal household records. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
