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

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

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 th

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 e

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

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. > > Remembe

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000, Randolph Fritz wrote: > 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 busi

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 actu

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000, Hendrik Boom wrote: > > I don't think there is one; the _arguable_ counterexample would be the > > situation where a market changes "denominations," but that may also be > > argued to redenominate the commodity, which means it's not really the > > same commodity anymore... > >

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000, Jon Trowbridge wrote: > Well, for what it is worth, holding shares in Red Hat means that you > *own* a (probably very small) percentage of Red Hat, and your rights > and obligations flow from that ownership. > > If you hold futures contracts, you own *nothing*. Instead, you

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000, John Hasler wrote: > Buddha Buck writes: > > Are "1/100 Dollars" and "1/64 Dollars" considered the same "commodity" or > > different "commodities"? > > Your broker may quote you prices in "1/64 Dollars" but he will always bill > you in "1/100 Dollars". You will never have to

Re: RFC : Correcting some problems in rounding/number handling

On Fri, Jul 07, 2000 at 02:40:29PM -0500, Richard Wackerbarth wrote: > On Fri, 07 Jul 2000, Jon Trowbridge wrote: > > Remember, "margin" in futures trading means something totally > > different than "margin" in stock trading. Futures margin is a > > performance bond, meant to guarantee that you w

RE: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000, Buddha Buck wrote: > I am concerned about "commodities" that differ by simple scaling factors. > > Are "1/100 Dollars" and "1/64 Dollars" considered the same "commodity" or > different "commodities"? Should they be comparable? Should they use the > same dispatched printing r

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000, Jon Trowbridge wrote: > I think that the differences are substantial. > > A futures contract is just that; a contract. It has no intrinsic > value outside of the gain or loss the execution of that contract might > expose you to. > > > I typically pay off the margin and actua

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000, Randolph Fritz wrote: > 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 quantit

Re: RFC : Correcting some problems in rounding/number handling

On Fri, Jul 07, 2000 at 01:03:10PM -0500, Richard Wackerbarth wrote: > On Fri, 07 Jul 2000, Jon Trowbridge wrote: > > > Of course, with futures the value of the instrument doesn't change per > > se; > > I think that the "value" does change. The "amount" remains constant, but the > exchange rate

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 hal

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth writes: > But they were inventoried in a common unit if they are in the same > inventory. You would not have both 3 1/8 bushels and 4.02 bushels on the > same ledger. I've never had to inventory anything using other than decimal fractions, and never to more than two decimal p

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000, Jon Trowbridge wrote: > This is correct. One CBOT Soybean futures contract is for 5, > bushels of beans, but the price is quoted by the bushel, in eighths of > a cent. Of course there are no actual soybeans involved. You are really just trading pieces of paper :-) > O

Re: RFC : Correcting some problems in rounding/number handling

On Fri, Jul 07, 2000 at 11:56:33AM -0500, Richard Wackerbarth wrote: > On Fri, 07 Jul 2000, John Hasler wrote: > > Richard Wackerbarth writes: > > > Besides, "milk" and "sugar" are poor examples. They are seldom sold by > > > the gallon (pound) but rather by the "container". > > > > Actually, milk

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000, John Hasler wrote: > Richard Wackerbarth writes: > > Besides, "milk" and "sugar" are poor examples. They are seldom sold by > > the gallon (pound) but rather by the "container". > > Actually, milk is sold by the hundredweight (my neighbors are presently > complaining about the

Re: RFC : Correcting some problems in rounding/number handling

Buddha Buck writes: > Are "1/100 Dollars" and "1/64 Dollars" considered the same "commodity" or > different "commodities"? Your broker may quote you prices in "1/64 Dollars" but he will always bill you in "1/100 Dollars". You will never have to record a transaction in "1/64 Dollars". -- John Ha

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth writes: > Besides, "milk" and "sugar" are poor examples. They are seldom sold by > the gallon (pound) but rather by the "container". Actually, milk is sold by the hundredweight (my neighbors are presently complaining about the price). Not sure about sugar. > There is certain

Re: RFC : Correcting some problems in rounding/number handling

> > I don't think there is one; the _arguable_ counterexample would be the > situation where a market changes "denominations," but that may also be > argued to redenominate the commodity, which means it's not really the > same commodity anymore... > -- When I owe someone 12 1/2 shares of some se

Re: RFC : Correcting some problems in rounding/number handling

On Thu, Jul 06, 2000 at 09:51:39PM -0500, Christopher Browne wrote: > So I disagree with Jon, in that the "great pain and suffering" is > a _given_, and equally affects _both_ schemes. This is (basically) correct: the BG system works well (IMHO) for things like decimalizations of markets, but doe

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000, 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

RE: RFC : Correcting some problems in rounding/number handling

Just replying to one point here... > (note: my use of the word "commodity" as a more > generic term than "currency" or "stocks" or "inventory" seeks to be > more inclusive than any of them), I see no problem in keeping > some of the > "factors" in places that will need to be accessed separately f

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 07 Jul 2000 01:11:20 EST, the world broke into rejoicing as Richard Wackerbarth <[EMAIL PROTECTED]> said: > On Thu, 06 Jul 2000, Christopher Browne wrote: > > On 06 Jul 2000 09:10:23 EST, the world broke into rejoicing as > > > > Bill Gribble <[EMAIL PROTECTED]> said: > > > Richard Wacke

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,

Re: RFC : Correcting some problems in rounding/number handling

Christopher Browne writes: > > By the way, it is _well_ worth taking a look at the GnuE docs; > > > This page indicates: > > "Amounts of money will not be stored as decimal(9,2) because there are > some coutnries (e.g. -in the middle e

Re: RFC : Correcting some problems in rounding/number handling

On Thu, 06 Jul 2000, Christopher Browne wrote: > On 06 Jul 2000 09:10:23 EST, the world broke into rejoicing as > > Bill Gribble <[EMAIL PROTECTED]> said: > > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > > I agree that rather than describing the properties of a currency for > > > the "deno

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 poin

Re: RFC : Correcting some problems in rounding/number handling

On 06 Jul 2000 09:10:23 EST, the world broke into rejoicing as Bill Gribble <[EMAIL PROTECTED]> said: > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > I agree that rather than describing the properties of a currency for the > > "denominator" of an amount, we should simply reference the curr

Re: RFC : Correcting some problems in rounding/number handling

On Thu, 06 Jul 2000 12:56:07 MST, the world broke into rejoicing as Dylan Paul Thurston <[EMAIL PROTECTED]> said: > On Thu, Jul 06, 2000 at 12:04:30PM -0500, Jon Trowbridge wrote: > > For example, certain UK Govt Bonds have decimalized recently. They > > were previously quoted in 32nds, and are

Re: RFC : Correcting some problems in rounding/number handling

On Thu, 06 Jul 2000, you wrote: > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > For example, if the sales tax rate is 8 3/4 % (0.0875) we can > > represent that as 37/400 or as 875/1. When we apply that to a > > purchase of $1 (100/100) we get an answer of 37/400 and not 9/100 > > which

Re: RFC : Correcting some problems in rounding/number handling

On Thu, Jul 06, 2000 at 12:04:30PM -0500, Jon Trowbridge wrote: > For example, certain UK Govt Bonds have decimalized recently. They > were previously quoted in 32nds, and are now quoted in 100ths. This > is particularly annoying, since you can't convert old prices to new > without loss of preci

Re: RFC : Correcting some problems in rounding/number handling

On Thu, 06 Jul 2000, Jon Trowbridge wrote: > On Thu, Jul 06, 2000 at 12:33:04PM -0500, Richard Wackerbarth wrote: > (2) That representing the prices of financial instruments is a > different matter that representing quantities of currency for > accounting purposes, and thus these kinds of

RE: RFC : Correcting some problems in rounding/number handling

Jon Trowbridge said: > I mentioned this issue before, but I'll mention it again: > > I'd like to use whatever library comes out of this for storing > historical price data for various financial instruments. Certain > of these have changed "denominator" over time. > > For example, certain UK G

Re: RFC : Correcting some problems in rounding/number handling

On Thu, Jul 06, 2000 at 12:33:04PM -0500, Richard Wackerbarth wrote: > > The difference is in the storage. > > You propose to store > (numerator, denominator==f(currency), currency) > for each entry > and hope that someone enforces the == relation. > > I, on the other hand would store only > (n

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth <[EMAIL PROTECTED]> writes: > For example, if the sales tax rate is 8 3/4 % (0.0875) we can > represent that as 37/400 or as 875/1. When we apply that to a > purchase of $1 (100/100) we get an answer of 37/400 and not 9/100 > which is what is actually collected. That's onl

Re: RFC : Correcting some problems in rounding/number handling

On Thu, 06 Jul 2000, Shimpei Yamashita wrote: > > 2) If you assume that all of the denominators for a given currency are > > the same, you have not really gained anything by storing them repeatedly. > > And you have introduced an additional possibility of error trying to > > enforce the assertion

Re: RFC : Correcting some problems in rounding/number handling

On Thu, 06 Jul 2000, Bill Gribble wrote: > Buddha Buck <[EMAIL PROTECTED]> writes: > > So, why the argument? > > It's a high-priority goal of mine to make the result of this process > be a straightforward, testable, stand-alone mathematical library for > dealing with financial numbers that other p

Re: RFC : Correcting some problems in rounding/number handling

On Thu, Jul 06, 2000 at 10:47:17AM -0500, Richard Wackerbarth wrote: > On Thu, 06 Jul 2000, Shimpei Yamashita wrote: > > On Wed, Jul 05, 2000 at 09:10:12PM -0500, Christopher Browne wrote: > > > I would anticipate that having the basic representation be via > > > rational numbers (e.g. - numerator

Re: RFC : Correcting some problems in rounding/number handling

Buddha Buck <[EMAIL PROTECTED]> writes: > So, why the argument? It's a high-priority goal of mine to make the result of this process be a straightforward, testable, stand-alone mathematical library for dealing with financial numbers that other people can use in their own applications. I have rec

RE: RFC : Correcting some problems in rounding/number handling

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 06, 2000 10:10 AM > To: Richard Wackerbarth > Cc: Christopher Browne; [EMAIL PROTECTED] > Subject: Re: RFC : Correcting some problems in > rounding/number han

Re: RFC : Correcting some problems in rounding/number handling

On Thu, 06 Jul 2000, Shimpei Yamashita wrote: > On Wed, Jul 05, 2000 at 09:10:12PM -0500, Christopher Browne wrote: > > I would anticipate that having the basic representation be via > > rational numbers (e.g. - numerator + denominator in each entry) will > > _prevent_ using an SQL DBMS, because S

Re: RFC : Correcting some problems in rounding/number handling

On Wed, Jul 05, 2000 at 09:10:12PM -0500, Christopher Browne wrote: > > I would anticipate that having the basic representation be via > rational numbers (e.g. - numerator + denominator in each entry) will > _prevent_ using an SQL DBMS, because SQL DBMSes generally do not > contemplate that repr

Re: RFC : Correcting some problems in rounding/number handling

On Thu, 06 Jul 2000, Bill Gribble wrote: > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > I agree that rather than describing the properties of a currency for the > > "denominator" of an amount, we should simply reference the currency. The > > properties of it are common to all instances of a

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth <[EMAIL PROTECTED]> writes: > I think that we are saying the same thing. You and I are both of the > (learned) opinion that they will ultimately be different. However, > we acknowledge that, if it works better, we would consider folding > them into one unified structure. Richa

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth <[EMAIL PROTECTED]> writes: > First we are dealing only in integers that we sum. Even multiprecision > integer arithmatic is much faster than "rational" summation. Anything that can be summed in a financial database will have to have the same denominator. We don't have to do

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth <[EMAIL PROTECTED]> writes: > I agree that rather than describing the properties of a currency for the > "denominator" of an amount, we should simply reference the currency. The > properties of it are common to all instances of amounts denominated in that > currency. Further

Re: RFC : Correcting some problems in rounding/number handling

Christopher Browne <[EMAIL PROTECTED]> writes: > This generality interferes with the possibility of having an SQL > engine do the calculation for you, via: > select sum( value ) from txntable where currency = "USD" >and date = something; I'm not SQL-literate, but it seems pretty clear that

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 05 Jul 2000, Christopher Browne wrote: > > I agree that rather than describing the properties of a currency for the > > "denominator" of an amount, we should simply reference the currency. The > > properties of it are common to all instances of amounts denominated in > > that currency. Fu

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 05 Jul 2000 22:18:44 EST, the world broke into rejoicing as Richard Wackerbarth <[EMAIL PROTECTED]> said: > On Wed, 05 Jul 2000, Christopher Browne wrote: > > > b) One that is strongly tied to the "commodity." > > > > Thus, you have: > > > > struct gnc_commodity_value { > >gint64 qua

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 05 Jul 2000, Christopher Browne wrote: > b) One that is strongly tied to the "commodity." > > Thus, you have: > > struct gnc_commodity_value { >gint64 quantity; >creference commodity_id; > }; > > along with > > struct commodity_info { >creference commodity_id; >char commod

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 05 Jul 2000, Christopher Browne wrote: > > I disagree. "Prices" are NOT in the same unit space as countable items. > > To FORCE them there places unreasonable constraints on the way we > > represent and handle them. > > I agree with you on this; "Prices" are different particularly since t

Re: RFC : Correcting some problems in rounding/number handling

On 05 Jul 2000 15:36:27 EST, the world broke into rejoicing as Rob Browning <[EMAIL PROTECTED]> said: > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > > Personally, I think that this is one weakness in the present > > approach to report generation. I would prefer to see an > > implementatio

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 05 Jul 2000 12:01:57 EST, the world broke into rejoicing as Richard Wackerbarth <[EMAIL PROTECTED]> said: > On Wed, 05 Jul 2000, Bill Gribble wrote: > > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > > No it is not. That is adding "apples" and "oranges". > > > > No, it isn't. Adding

Re: RFC : Correcting some problems in rounding/number handling

On 05 Jul 2000 10:48:18 EST, the world broke into rejoicing as Bill Gribble <[EMAIL PROTECTED]> said: > Christopher Browne <[EMAIL PROTECTED]> writes: > > Come on, people. The issue is _not_ what "object system" is being > > used, or what language is being used, but rather _what the numeric > >

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 05 Jul 2000, Rob Browning wrote: > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > Personally, I think that this is one weakness in the present > > approach to report generation. I would prefer to see an > > implementation that does the calculations in the engine (as directed > > by th

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth <[EMAIL PROTECTED]> writes: > Personally, I think that this is one weakness in the present > approach to report generation. I would prefer to see an > implementation that does the calculations in the engine (as directed > by the report generator) and only does the displaying i

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 05 Jul 2000, Bill Gribble wrote: > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > No it is not. That is adding "apples" and "oranges". > > No, it isn't. Adding one "apple" to one "orange" is adding apples to > oranges. Adding 1.01 to 1.001 is adding a number in hundredths to a > num

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth <[EMAIL PROTECTED]> writes: > No it is not. That is adding "apples" and "oranges". No, it isn't. Adding one "apple" to one "orange" is adding apples to oranges. Adding 1.01 to 1.001 is adding a number in hundredths to a number in thousandths, and there's nothing sacrilegious

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 05 Jul 2000, Bill Gribble wrote: > At the top level, I think the first thing to nail down is a numeric > representation rather than a monetary-value representation. There > needs to be a layer that enforces restrictions such as "can't add > dollars to pounds", but I believe that we must

Re: RFC : Correcting some problems in rounding/number handling

Christopher Browne <[EMAIL PROTECTED]> writes: > Come on, people. The issue is _not_ what "object system" is being > used, or what language is being used, but rather _what the numeric > representation should be_. I think most of your comments here are right on point. However, I disagree with yo

Re: RFC : Correcting some problems in rounding/number handling

> Well, floating point is definitely NOT the proper solution for US dollars > (or any other currency of which I am aware -- anybody know a currency > still in use that isn't decimal? The UK abandoned the "shillings & > pence" in the '60's). I believe some former British colonies still use pounds

Re: RFC : Correcting some problems in rounding/number handling

> On Fri, Jun 30, 2000 at 01:39:07PM -0500, Bill Gribble wrote: > > Clark Jones <[EMAIL PROTECTED]> writes: > > > in stockmarket quotations, e.g., nonsense like "73 213/256". However, > > > the SEC has told the U.S. stock markets "thou shalt decimalize", and though > > > Partially true, but stoc

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth wrot > I think that the "pricing" module ( 1 = $0.20, ... , 6 = $1.00, ... 13 = > $1.99) is beyond the scope of Gnucash. However, we probably be prepared to do > the "cost of goods" calculation that goes with the sale. This is an example of how a database-backended client/ser

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 30 Jun 2000, Clark Jones wrote: > The "business oriented" languages usually do it with "binary > coded decimal", rather than scaled integers. BCD is a big "win" if you are mostly doing I/O rather than computation. For example, in the typical customer billing, you may have to output virtua

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth wrote: > > On Fri, 30 Jun 2000, Clark Jones wrote: > > > Well, floating point is definitely NOT the proper solution for US dollars > On this, I think we finally agree. :-) > > One could use multiprecision integer and represent > > US dollars in "cents", but that becomes a r

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 30 Jun 2000, Christopher Browne wrote: > Come on, people. The issue is _not_ what "object system" is being > used, or what language is being used, but rather _what the numeric > representation should be_. To a large extent, I agree. > C and C++ have the _same_ basic sets of basic data

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 30 Jun 2000 07:13:03 MST, the world broke into rejoicing as Randolph Fritz <[EMAIL PROTECTED]> said: > 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 ab

Re: RFC : Correcting some problems in rounding/number handling

On Fri, Jun 30, 2000 at 01:39:07PM -0500, Bill Gribble wrote: > Clark Jones <[EMAIL PROTECTED]> writes: > > in stockmarket quotations, e.g., nonsense like "73 213/256". However, > > the SEC has told the U.S. stock markets "thou shalt decimalize", and though > Partially true, but stock prices are

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 30 Jun 2000, Clark Jones wrote: > Well, floating point is definitely NOT the proper solution for US dollars On this, I think we finally agree. > One could use multiprecision integer and represent > US dollars in "cents", but that becomes a real pain in the tush, and so > is not a proper

Re: RFC : Correcting some problems in rounding/number handling

Clark Jones <[EMAIL PROTECTED]> writes: > Well, floating point is definitely NOT the proper solution for US dollars That's not what we are talking about. We know that floating point is a bad solution. The point I was trying to raise was that "fixed point" implies decimal fractions, but there ar

Re: RFC : Correcting some problems in rounding/number handling

Bill Gribble writes: > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > Personally, I think that this is one weakness in the present approach to > > report generation. I would prefer to see an implementation that does the > > calculations in the engine (as directed by the report generator

Re: RFC : Correcting some problems in rounding/number handling

Bill Gribble wrote: [...] > Please be careful about use of the term "fixpoint". It implies that > the smallest-countable-unit is related to the unity-unit by a > power-of-ten relationship. That's true for US Dollars, but it's not > something we can assume for other currencies or for other numeri

Re: RFC : Correcting some problems in rounding/number handling

Robert Graham Merkel <[EMAIL PROTECTED]> writes: > It's a good thought, and the use of C++ operator overloading is > convenient for this kind of thing, but there is a rather large > problem. C++ operator overloading is almost never the right thing to do, IMO. The operators already have meanings

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth <[EMAIL PROTECTED]> writes: > Personally, I think that this is one weakness in the present approach to > report generation. I would prefer to see an implementation that does the > calculations in the engine (as directed by the report generator) and only > does the displaying

Re: RFC : Correcting some problems in rounding/number handling

> Clark Jones writes: > > > A thought has occurred to me: A possible solution would be to "migrate" > > to C++ (not a humongous project, since a quick look through a "tar -tvzf" > > of a source-tarball reveals that it's mostly in C) and then use C++'s > > ability to "overload" the normal ope

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

Re: RFC : Correcting some problems in rounding/number handling

On Fri, 30 Jun 2000, 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)" You are correct. However Robert was pointing out that you do n

Re: RFC : Correcting some problems in rounding/number handling

Hello Robert, >>> Robert Graham Merkel <[EMAIL PROTECTED]> 30.06.00 09:31:59 >>> 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

Re: RFC : Correcting some problems in rounding/number handling

Clark Jones writes: > A thought has occurred to me: A possible solution would be to "migrate" > to C++ (not a humongous project, since a quick look through a "tar -tvzf" > of a source-tarball reveals that it's mostly in C) and then use C++'s > ability to "overload" the normal operators to, i

Re: RFC : Correcting some problems in rounding/number handling

In the message below, Bill Gribble points out some "intrinsic" problems with how GnuCash deals with currency amounts. It has been pointed out by some others (as well as myself) that at least some "commercial" systems (notably in COBOL) use "fixed point" representations. My very limited experienc

Re: RFC : Correcting some problems in rounding/number handling

> After discussion with some of the other developers, it is becoming > clear that most if not all of the problems people are having with > rounding and fractional cents are because, in fact, gnucash does not > know that there is a minimimum quantum of transactions for certain > types of accounts.

Re: RFC : Correcting some problems in rounding/number handling

On Wed, Jun 21, 2000 at 01:08:50PM -0500, Bill Gribble wrote: > Now you tell me about the limits on resolution of the number > of shares in a mutual fund account. My mutual funds report price to 2, 3, or 4 decimal places, and number of units to 3 or 4 decimal places. -- Gnucash Developer's List

Re: RFC : Correcting some problems in rounding/number handling

>From my experience, the typical math app was written in Fortran because COBOL wasn't nearly as good at math. In any case, that rounding scheme wasn't thought up by the writers for the Superman movie. That was a trick done in the late 70's and yes, it was actually done. I think the guy got caug

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 -- G

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 21 Jun 2000, Christopher Browne wrote: > > 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. > > I'm quite disappointed in the tho

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 21 Jun 2000, Christopher Browne wrote: > Although that's only half the story; the other half is that you > do have another amount that needs to be tracked, namely the cost. Right. You must track both the number of units AND their actual cost. > It is pretty useless on an ongoing basis, w

Re: RFC : Correcting some problems in rounding/number handling

Christopher Browne writes: > On Wed, 21 Jun 2000 14:16:58 MST, the world broke into rejoicing as > Randolph Fritz <[EMAIL PROTECTED]> said: > > On Wed, Jun 21, 2000 at 01:08:50PM -0500, Bill Gribble wrote: > > > I believe, historically at least, banks have used "mils," or $0.001. > > They m

Re: RFC : Correcting some problems in rounding/number handling

In one message or another, Christopher Browne said something like this: >The "stealing the pennies" idea was entertaining enough when >presented by Richard Pryor in one of the worse of the Superman >movies, but keep in mind that this _was_ a "bad Superman movie." it was more recently presented i

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 21 Jun 2000 14:16:58 MST, the world broke into rejoicing as Randolph Fritz <[EMAIL PROTECTED]> said: > 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

Re: RFC : Correcting some problems in rounding/number handling

On 21 Jun 2000 13:08:50 EST, the world broke into rejoicing as Bill Gribble <[EMAIL PROTECTED]> said: > > Alternative 3 is to just accept the transaction. It is an artifact > > of gnucash that things must balance to floating point accuracy. The > > reality is that the accountants consider it bala

Re: RFC : Correcting some problems in rounding/number handling

On 21 Jun 2000 10:46:42 EST, the world broke into rejoicing as Bill Gribble <[EMAIL PROTECTED]> said: > After discussion with some of the other developers, it is becoming > clear that most if not all of the problems people are having with > rounding and fractional cents are because, in fact, gnuc

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 transact

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 21 Jun 2000, Bill Gribble wrote: > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > As far as I know, EVERY account has a minimum transaction unit. > > Actually, that's the question. If every account has a minimum > transaction unit, we need to enumerate what they are for every type of

Re: RFC : Correcting some problems in rounding/number handling

Richard Wackerbarth <[EMAIL PROTECTED]> writes: > As far as I know, EVERY account has a minimum transaction unit. 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:

Re: RFC : Correcting some problems in rounding/number handling

On Wed, 21 Jun 2000, Bill Gribble wrote: > After discussion with some of the other developers, it is becoming > clear that most if not all of the problems people are having with > rounding and fractional cents are because, in fact, gnucash does not > know that there is a minimimum quantum of trans

  1   2   >