[GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hi Everyone,

Oops. I missed two posts from Jim and did not reply to one other. I apologize 
for that. Here is a correction.


On Oct 8 18:28:00 EDT Jim DeLaHunt wrote: 
    >I fear that Bruce McCoy pushed this thread 
    >astray by introducing the phrase "books… 
    >out of balance". This moved the topic from 
    >GnuCash handling of securities transactions 
    >to GnuCash handling of the Trial Balance.
    >That led to discussion of cost of goods sold, 
    >and GnuCash not having support for cost 
    >accounting, and so on.

The cost of goods sold and lack of support for cost accounting, among other 
things, were discussed. 

    >The digression does not strike me as helping Bruce... 

Yes. Yet, could there be a way in which some digressions might help us? By 
noting the topics we are not discussing (at least one of which is mentioned 
below), could that make clearer what we are discussing? Could it help us 
generate an agenda?

One might say, “Within the general topic of ‘Encouraging people to use 
GnuCash,’ how they look at the way GnuCash views security transactions was the 
specific subject for discussion.”


On Oct 8 20:15:05 EDT Jim DeLaHunt wrote: 
    >Many people have told you, Bruce, that the 
    >practical way[*] to read this broker statement 

Jim, in your discussion of “the practical way[*]” you provide a great 
illustration. You are careful to define terms and this is an excellent thing to 
do in presenting a position. It provides clarity to your readers. Thank you for 
providing it.

    >is as:
    >
    >    "_exactly_ 1,377.41 shares, 
    >    price _approximately_ 10.89, amount
    >    _exactly_ $15,000.00"
    >
    >when entering the transaction to GnuCash, 
    >enter exactly 1,377.41 as the number of 
    >shares, exactly 15,000.00 as the amount of 
    >the transaction, and leave the price blank. 
    >GnuCash fills in a price of 1500/137741, 
    >and stores that internally. GnuCash might 
    >display the price as either 10 + 5/137741 
    >or $10.8900, depending on the currency and 
    >the user preferences, 

And John Ralls’ work is a wonder. Its precision is 1/2^64. We all owe him a 
debt of gratitude for his contributions. 

    >but remember that display and internal exact 
    >value need not be the same thing.
    >...
    >I also see an error in failing to use GnuCash 
    >in the way which best fits the provided 
    >information, to record the transaction.

As far as I know, we, in the GnuCash community, all agree that if we enter 
1,377.41 as the number of shares, and 15,000.00 as the amount of the 
transaction, and leave the price blank. GnuCash will fill in a price of 
1500/137741, and store that internally. The precision of the price is 
1/2^64. People familiar with GnuCash expect that. At least I do. That is my 
understanding of how GnuCash works. 

    >I see...a conceptual error by you, in interpreting 
    >a logically inconsistent broker transaction report...

OK. I do make lots of errors. I appreciate our working together to advance the 
development of GnuCash. Thank you. Let’s look at this situation. You expanded 
on the topic in a later post. So, let’s include that as well.


On Oct 25 21:49:36 EDT Jim DeLaHunt wrote: 
    >you are holding fast to assertions which I 
    >think are mistaken, and which lead you to 
    >misunderstanding. Let me highlight a few
    >...
    >On 2023-10-25 17:00, Bruce McCoy via 
    >gnucash-user wrote:
    >> ...In the following, we assume "value/price 
    >>produces an amount representable in the share 
    >>commodity's minimum fraction."
    >>
    >>We also assume that an "exactly precise" number 
    >>has the same precision as the smallest currency 
    >>unit (SCU).
    >
    >these...assumptions are faulty. The 
    >will lead you to misunderstandings 

Jim, we agree that holding fast to assertions which are mistaken leads to 
indefensible conclusions. The same holds true for many assumptions. And you are 
right. Examining both assumptions and assertions are essential.

In discussions such as this, assertions may be things stated positively. “We 
are certain that the sun is shining and there is, now, no shade on the patio.” 
might be an example. Assumptions suppose (or consider) something to be a fact. 
They may be limiting or not.

The first assumption cited is from John Ralls.

On 9 Sep 2023 15:36 John Ralls wrote: 
    >So the claim value = price * shares is logically 
    >correct but depends on price * shares yielding a 
    >legal value in value's currency; the reverse is 
    >true as well: shares = value/price is true only 
    >if value/price produces an amount representable 
    >in the share commodity's minimum fraction.

This assumption is an example of a limiting assumption. Inclusion lets the 
readers know that the discussion is limited to cases in which the condition is 
true. This assumption was added to let John Ralls know that this section would 
be one in which the values 

Re: [GNC] GnuCash_user: rounding errors and significant digits

[R Losey]

And to use a concrete example:

1.4 + 1.4 = 2.8 - the sum rounds to 3.

If you round the addends, you get

1 + 1 = 2


On Fri, Oct 27, 2023 at 12:07 PM Michael or Penny Novack <
stepbystepf...@comcast.net> wrote:

> Beating what should be a dead horse.
>
> Let A, B, and C be rational numbers (ie: expressed in the form X/Y where
> X and Y are integers). Let D be a function that represents the decimal
> equivalent of a rational number to some finite number of decimal places.
>
> A + B = C does NOT imply that D(A) + D(B) = D(C)
>
> In other words, the fact that a set of books is balanced when the
> amounts are represented as rationals does not mean would be balanced
> once these rational numbers are converted to decimals.
>
> By and large, we keep our books as decimals (the books as we see them)
> and entities that require reports from us are going to require values as
> decimal (possibly rounded to some specified whole units of some currency
> << THAT introduces a second level of complexity as it might be required
> that those reports balance >>
>
> Gnucash is not making "errors" in arithmetic. Simply differences
> intrinsic to the operation "round".
>
>
> Michael D Novack
>
>
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


-- 
_
Richard Losey
rlo...@gmail.com
Micah 6:8
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Michael or Penny Novack]

Beating what should be a dead horse.

Let A, B, and C be rational numbers (ie: expressed in the form X/Y where 
X and Y are integers). Let D be a function that represents the decimal 
equivalent of a rational number to some finite number of decimal places.


A + B = C does NOT imply that D(A) + D(B) = D(C)

In other words, the fact that a set of books is balanced when the 
amounts are represented as rationals does not mean would be balanced 
once these rational numbers are converted to decimals.


By and large, we keep our books as decimals (the books as we see them) 
and entities that require reports from us are going to require values as 
decimal (possibly rounded to some specified whole units of some currency 
<< THAT introduces a second level of complexity as it might be required 
that those reports balance >>


Gnucash is not making "errors" in arithmetic. Simply differences 
intrinsic to the operation "round".



Michael D Novack


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Jim,

Thank you for responding. You make valid points.
  
On Wed, Oct 25 at 9:50 PM Jim DeLaHunt wrote and cited: 
    >On 2023-10-25 17:00, Bruce McCoy via gnucash-user wrote:
    > We also assume that an "exactly precise" number has 
    the same precision as the smallest currency unit (SCU).
    >
    >I believe that your definition of "exactly precise" 
    >is different from the plain meaning of the words. 
    >The plain meaning is that an "exactly precise" 
    >representation of a number is a representation 
    >which exactly conveys the true numerical value. 
    >Thus, decimal number "0.3" is an exactly precise 
    >representation of the rational number 3/10

Well said. You saying “decimal number "0.3" is an exactly precise 
representation of the rational number 3/10” is just what I wanted to say. Let 
me try again. Since SCUs have an infinite number of zeros to the right of the 
decimal place, they are exactly precise.

    >but decimal number "0." is not an exactly 
    >precise representation of the rational number 1/3.

Quite. Here ww can note a reference to the elegance of GnuCash’s rational 
number treatment.

    >GnuCash documentation could be improved…
    >the most useful contribution is to formally 
    >propose a change... But, a proposed change 
    >based on a misunderstanding will probably not 
    >succeed.

We agree both that “the most useful contribution is to formally propose a 
change” and that “a proposed change based on a misunderstanding will” fail.  

Submitting these ideas to the gnucash users group for vetting before proposing 
a formal change was the idea. You and the other members of the gnucash users 
group have been very helpful in this discussion by explaining how GnuCash 
works. You have reduced my misunderstandings of GnuCash. You have increased my 
understanding of GnuCash. Thank you. 

    >why do you hold so fast to the conviction 
    >that the price number which the broker 
    >prints on the statement exactly represents 
    >the numerical value which they used in your 
    >transaction?

There are two reasons. First, some newcomers to GnuCash are used to thinking 
that way and they might find it helpful to be informed that GnuCash may not 
follow the conventions with which they are accustomed. One way to do this would 
be to place an explanatory note in the documentation. Second, in 
“Value-of-the-transaction =  Price-per-share * Number-of-shares,” two of the 
terms are in currencies having SCUs and one term is not. Since the SCUs have an 
infinite number of zeros to the right of the decimal place, the remaining term 
can not.

Because you have asked, I have responded to you. The feeling of the community 
at large may be more likely to want to table this discussion. If so, we can do 
that.

Engaging with you has let me become acquainted with a group of informed, 
gracious, and helpful people. It has been an enjoyable experience. Thank you.
  
Bruce



|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Jim DeLaHunt]

Bruce:

Again, I think you are holding fast to assertions which I think are 
mistaken, and which lead you to misunderstanding. Let me highlight a few 
in your most recent message.


On 2023-10-25 17:00, Bruce McCoy via gnucash-user wrote:

...In the following, we assume "value/price produces an amount representable in the 
share commodity's minimum fraction."

We also assume that an "exactly precise" number has the same precision as the 
smallest currency unit (SCU).


I think these are assumptions are faulty. The will lead you to 
misunderstandings in a few paragraphs.


It is not always the case that value/price, where value price are number 
in the smallest currency unit, produce an amount representable in the 
share commodity's minimum fraction.  For instance, suppose you want to 
buy shares of Berkshire Hathaway at market price (171.10 USD just now) 
and you have 1000.00 USD. Your unhelpful broker only lets you buy whole 
shares, so the share commodity's minimum fraction is 1.0:


   value = 1000.00 USD (in smallest currency unit)
   price = 171.10 USD (in smallest currency unit)
   value/price = 1/1711 shares precisely =~ 5.8 shares (approximately)
   value/price is an amount, approx 5.8, which is not representable in
   the share commodity's minimum fraction.

I believe that your definition of "exactly precise" is different from 
the plain meaning of the words. The plain meaning is that an "exactly 
precise" representation of a number is a representation which exactly 
conveys the true numerical value. Thus, decimal number "0.3" is an 
exactly precise representation of the rational number 3/10, but decimal 
number "0." is not an exactly precise representation of the rational 
number 1/3.




...GnuCash treats the smallest currency unit as an exactly precise number[1].
[1] ex. GnuCash Tutorial and Concepts Guide, Figure 9.14. The Price Database 
With The List Of All Known Commodities


I don't think that Figure 9.14 justifies your claim about GnuCash 
behaviour. Your words mean, "GnuCash treats the smallest currency unit" 
as a number with "the same precision as the smallest currency unit 
(SCU)." It is a tautology.


Maybe you see that the AMZN stock Price entries in that Figure as being 
of the form "35.99" and assume that GnuCash is limited to only 
represent prices to two decimal digits of US dollars. But it may well be 
that GnuCash would happily store a price with a greater precision, e.g. 
"3,567.523217", or rational numbers not representable in six digits 
after the decimal, e.g. 99123457/356752 . Figure 9.14 does not show 
you either way. (Narrator: in fact, GnuCash would.)




...
On Sat, Oct 7 at 1:25 PM David Carlson wrote:
     >According to my hp 49g+ scientific graphing calculator,
     >15,000.00 divided by 1,377.41 yields 10.8900037026.
     >I defy anyone to pay that amount per share in U.S. currency.

David Carlson follows the GnuCash example in recognizing that the SCUs are 
exactly precise (Who pays $0.037026?) and only the number-of-shares figure 
can be an approximation.


I believe you are missing David Carlson's point. I believe he was saying 
that the stock broker's price of "10.89" was clearly not the precise 
price paid, so the _price_ was an approximation.




On Sat, Oct 7 at 4:06 PM John Ralls wrote:
     >Jeff did it wrong...because the price per share
     >he paid wasn't 10.89, it was 137741/150.

$10.89 is an exactly precise figure. 150/137741 is a very close 
approximation.


I think this is where your definition of "precise figure" is leading you 
astray. The transaction amount and the number of shares reported by the 
broker had numerical values which exactly matched the broker's 
representations. "$10.89" is the broker's approximate representation of 
the actual numerical value, which is amount/quantity, or 150/137741.




     >It's simpler to enter the amount and value
     >than to enter an exact price.

Dividing the value-of-the-transaction by the amount-of-shares involved yields 
the price-per-share. I am sure you have a good reason for designing GnuCash 
with the convention of calculating price-per-share from the other two 
variables. Could you share how you arrived at this decision?


I think people arrive at this decision because it gives correct results. 
Conversely, treating an approximate representation of a price as exact, 
leads to misunderstanding and to incorrect results.




According to GnuCash SCUs are exactly precise, so the number-of-shares is the 
only number which can be less than exactly precise due to rounding, for 
example, by institutions. Investors, as clearly stated by both Ken and Stan, 
accept the rounded number-of-shares values since they are the number-of-shares 
allotted to them in the transaction.


Your premise is faulty; GnuCash does not insist that smallest currency 
units are "exactly precise" according to your definition.  Your 
conclusion, "the number-of-shares is the only number which can 

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

 Hi Everyone,

On Sun, Oct 8 at 5:31 AM sunfish62 wrote:
    >I'm not sure whose problem is being solved by 
    >this drawn out discussion. 
    >
    >⁣David T.

David, you are right. It is a drawn out discussion. 

On Sat Oct 7 17:27:29 EDT 2023 Maf. King wrote: 
    >going around in circles.

Exactly. Aren't there at least two perspectives?
Observer: 
 Bruce, you are going around in circles. 
 You do not seem to be making much, if any, progress.
Participant:
 I circle around, trying to see it from every angle.
 I do not seem to be making much, if any, progress.

Why are we doing this? We help ourselves, if we make GnuCash easy to understand 
and use. People unfamiliar with GnuCash conventions may find notes on how to 
understand GnuCash helpful. 


Assumptions
===
On Sat, Oct 7 at 4:06 PM John Ralls wrote: 
    > GnuCash has no support for cost accounting


On 2023-09-09 15:36:40 EDT, John Ralls wrote:
    >So the claim value = price * shares is logically 
    >correct but depends on price * shares yielding 
`    >a legal value in value's currency; the reverse 
    >is true as well: shares = value/price is true 
    >only if value/price produces an amount representable 
    >in the share commodity's minimum fraction.

In the following, we assume "value/price produces an amount representable in 
the share commodity's minimum fraction."

We also assume that an "exactly precise" number has the same precision as the 
smallest currency unit (SCU).


Considerations
==
On Sat Oct 7 15:48:25 EDT 2023 John Ralls wrote:
    >GnuCash does **NOT** round prices to two decimals. 
    >Prices are always calculated to the full numeric 
    >precision of 1/2^64. Amounts and values are what 
    >get rounded to the respective commodity/currency's 
    >smallest unit.

John, GnuCash does an excellent job calculating its results. The discussion 
here is mostly meant to be one in which we generate an explanatory note in the 
documentation to help newcomers to understand how to think about the way 
GnuCash may differ from what is familiar to them. Your rational number and your 
full numeric precision calculations are outstanding. You have done yeoman work 
on this project, as for as I am concerned.

GnuCash treats the smallest currency unit as an exactly precise number[1].

On Sat, Oct 7 at 1:25 PM David Carlson wrote: 
    >According to my hp 49g+ scientific graphing calculator, 
    >15,000.00 divided by 1,377.41 yields 10.8900037026.  
    >I defy anyone to pay that amount per share in U.S. currency.

David Carlson follows the GnuCash example in recognizing that the SCUs are 
exactly precise (Who pays $0.037026?) and only the number-of-shares figure 
can be an approximation.

On Sat, Oct 7 at 4:06 PM John Ralls wrote: 
    >Jeff did it wrong...because the price per share 
    >he paid wasn't 10.89, it was 137741/150.

$10.89 is an exactly precise figure. 150/137741 is a very close 
approximation.

    >It's simpler to enter the amount and value 
    >than to enter an exact price.

Dividing the value-of-the-transaction by the amount-of-shares involved yields 
the price-per-share. I am sure you have a good reason for designing GnuCash 
with the convention of calculating price-per-share from the other two 
variables. Could you share how you arrived at this decision?

On 2023-09-09 15:19:53 EDT, Ken Farley wrote:
    >The key equation is AMOUNT = PRICE * SHARES...
    >What I really care about when I get my statements 
    >from investment institutions, or trade 
    >notifications, is the number of SHARES involved
    >and the total cost to me.

On 2023-09-09 15:41:46 EDT, Stan Brown wrote:
    >It is _mathematically_ not possible to have three 
    >decimal numbers A B and C, each rounded to a 
    >desired number of decimal places, fulfill the 
    >equation A * B = C exactly... Number of shares 
    >and total amount must be exact to the generally 
    >accepted numbers of decimal places, or people's 
    >books won't balance.

According to GnuCash SCUs are exactly precise, so the number-of-shares is the 
only number which can be less than exactly precise due to rounding, for 
example, by institutions. Investors, as clearly stated by both Ken and Stan, 
accept the rounded number-of-shares values since they are the number-of-shares 
allotted to them in the transaction.

Evaluation
==
In stock transactions, 
Value-of-the-transaction =  Price-per-share * Number-of-shares.

Financial firms treat SCUs as exactly precise figures, and the 
number-of-shares, when required, as an approximation. GnuCash does treat the 
value-of-the-transaction SCU as an exactly precise figure. 

In its internal calculations, GnuCash differs from financial firms in its 
treatment of the number-of-shares and the price-per-share figures.

First, GnuCash treats the number-of-shares figure, despite its possibly having 
a rounding error, as though it were exactly precise. Second, GnuCash treats 

Re: [GNC] GnuCash_user: rounding errors and significant digits

[David Carlson]

Perhaps the broker overcharged his client.

On Sun, Oct 8, 2023 at 4:44 AM Fred Bone  wrote:

> On 08 October 2023 at 4:13, David Carlson said:
>
> > Because the broker charged 15,000.00 for 1,377.41 shares?
>
> Then the effective price paid per share wasn't the stated 10.89 but
> slightly more (approx 10.890003702601258884)
>
>
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


-- 
David Carlson
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Fred Bone]

On 08 October 2023 at 4:13, David Carlson said:

> Because the broker charged 15,000.00 for 1,377.41 shares?

Then the effective price paid per share wasn't the stated 10.89 but 
slightly more (approx 10.890003702601258884)


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[sunfish62--- via gnucash-user]

FWIW, Jeff reported his problem in 2014, and was happy when Derek advised him 
to enter the number of shares and the total dollar amount of the transaction, 
leaving the price to be calculated. I'm not sure whose problem is being solved 
by this drawn out discussion. 

⁣David T. ​

On Oct 8, 2023, 12:15 PM, at 12:15 PM, David Carlson 
 wrote:
>Because the broker charged 15,000.00 for 1,377.41 shares?
>
>On Sun, Oct 8, 2023, 2:32 AM Fred Bone  wrote:
>
>> On 08 October 2023 at 1:06, Bruce McCoy said:
>>
>> [...]
>>
>> > What I do not yet understand is if GnuCash considers a price per
>share of
>> > 10.89 to be a precise figure, why GnuCash does not calculate
>1,377.41 *
>> > 10.89 = 15,000.00 for Jeff. If GnuCash doesn’t, would we consider
>making
>> > a change to GnuCash to allow it?
>>
>> There is no good reason to think that 1377.41 * 10.89 = 15000, so why
>> would anyone want Gnucash to say it?
>>
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
>___
>gnucash-user mailing list
>gnucash-user@gnucash.org
>To update your subscription preferences or to unsubscribe:
>https://lists.gnucash.org/mailman/listinfo/gnucash-user
>-
>Please remember to CC this list on all your replies.
>You can do this by using Reply-To-List or Reply-All.
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[David Carlson]

Because the broker charged 15,000.00 for 1,377.41 shares?

On Sun, Oct 8, 2023, 2:32 AM Fred Bone  wrote:

> On 08 October 2023 at 1:06, Bruce McCoy said:
>
> [...]
>
> > What I do not yet understand is if GnuCash considers a price per share of
> > 10.89 to be a precise figure, why GnuCash does not calculate 1,377.41 *
> > 10.89 = 15,000.00 for Jeff. If GnuCash doesn’t, would we consider making
> > a change to GnuCash to allow it?
>
> There is no good reason to think that 1377.41 * 10.89 = 15000, so why
> would anyone want Gnucash to say it?
>
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Fred Bone]

On 08 October 2023 at 1:06, Bruce McCoy said:

[...]

> What I do not yet understand is if GnuCash considers a price per share of
> 10.89 to be a precise figure, why GnuCash does not calculate 1,377.41 *
> 10.89 = 15,000.00 for Jeff. If GnuCash doesn’t, would we consider making
> a change to GnuCash to allow it?

There is no good reason to think that 1377.41 * 10.89 = 15000, so why 
would anyone want Gnucash to say it?

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[David Carlson]

What you do not understand is that John Ralls and GnuCash recommend
entering the total amount and the total number of shares and letting
GnuCash calculate the price. THEN there is no error in the account running
balance.  This is not going to change.

On Sat, Oct 7, 2023 at 8:07 PM Bruce McCoy via gnucash-user <
gnucash-user@gnucash.org> wrote:

> Hi Everyone,
>
> On Oct 7, 2023, at 12:39, Bruce McCoy via gnucash-user wrote:
> >If I have missed it, please help me.
>
>
> On Sat Oct 7 15:52:28 EDT 2023 John Ralls wrote:
> >What you missed is my explanation that if
> >user's books are out of balance it's their
> >fault, not GnuCash's. The trial balance
> >report will help them discover the imbalance
> >but it's up to the user to decide whether
> >to spend time tracking it down or to create
> >a simple correcting transaction to fix it.
> >There are no plans to change that.
>
> Thank you for helping me. It is quite possible I missed something in your
> explanation. I do that a lot. It is one reason I appreciate Jim DeLaHunt so
> much.
>
> Let me explain what I think I understand. It was my impression that you
> were saying that when either the “Computing cost of goods sold”
> calculations or the “Average Cost price source” differ from the “the trial
> balance report” calculations the books would be out of balance. I’d agree
> with that and that GnuCash should not make any changes in these cases. If
> the user's books are out of balance it's their fault, not GnuCash's.
>
> What I do not yet understand is if GnuCash considers a price per share of
> 10.89 to be a precise figure, why GnuCash does not calculate 1,377.41 *
> 10.89 = 15,000.00 for Jeff. If GnuCash doesn’t, would we consider making a
> change to GnuCash to allow it?
>
> Best Regards,
> Bruce McCoy
>
>
> |  | Virus-free.www.avast.com |
>
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


-- 
David Carlson
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hi Maf. King,

You get the gold star of the day, for the most humerus response. You deserve it.

For mistyping “agree” and for poor proofreading, I suppose I’d get the reverse. 
I deserve it.

Best Regards,
Bruce


|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hi Adrien,

I do not know what is happening with the spacing. I do not know what my e-mail 
client is. And I do not know how to give you a reasonable answer – just to list 
three things.

Best Regards,
Bruce


|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hi Everyone,

On Oct 7, 2023, at 12:39, Bruce McCoy via gnucash-user wrote:
    >If I have missed it, please help me.


On Sat Oct 7 15:52:28 EDT 2023 John Ralls wrote:
    >What you missed is my explanation that if 
    >user's books are out of balance it's their 
    >fault, not GnuCash's. The trial balance 
    >report will help them discover the imbalance 
    >but it's up to the user to decide whether 
    >to spend time tracking it down or to create 
    >a simple correcting transaction to fix it. 
    >There are no plans to change that.

Thank you for helping me. It is quite possible I missed something in your 
explanation. I do that a lot. It is one reason I appreciate Jim DeLaHunt so 
much.

Let me explain what I think I understand. It was my impression that you were 
saying that when either the “Computing cost of goods sold” calculations or the 
“Average Cost price source” differ from the “the trial balance report” 
calculations the books would be out of balance. I’d agree with that and that 
GnuCash should not make any changes in these cases. If the user's books are out 
of balance it's their fault, not GnuCash's.

What I do not yet understand is if GnuCash considers a price per share of 10.89 
to be a precise figure, why GnuCash does not calculate 1,377.41 * 10.89 = 
15,000.00 for Jeff. If GnuCash doesn’t, would we consider making a change to 
GnuCash to allow it?

Best Regards,
Bruce McCoy


|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Adrien Monteleone]

Bruce,

On a side note, (I think John addressed your immediate concern) what in 
tarnation is your e-mail client?


Not only does it oddly removing spacing between words for your own 
replies, but it seems to now eat spacings between words of other 
people's replies that you QUOTE!!!


Really, what gives? I've never seen such a thing. It is of course no 
serious matter to GnuCash, or this list, but I am genuinely curious! 
(*note, I left more than necessary quoted below as an illustration)


Regards,
Adrien

On 10/7/23 2:39 PM, Bruce McCoy via gnucash-user wrote:


OnSat, Oct 7 at 1:25 PM David Carlson wrote:

  >Howmany times must you bring up the same

  >non-point?




Youare right in that I am addressing a community of people who areinterested in 
and actively developing GnuCash. As a community, youuse GnuCash and tolerate 
some of its shortcomings, while improvingthe program. From that perspective, 
this issue may seem to be anon-point. It certainly is a small point. GnuCash 
has developed a lotsince 2000. As GnuCash continues to develop, the major 
points willhave been all, in general, decided. Until resolved, unresolved 
pointswill remain.




  >Manypeople have explained how arithmetic works,




AndI appreciate their expertise, but that does not address the questionat hand.




  >JohnRalls has explained how GnuCash works.




Johnhas done excellent work in developing GnuCash and has, graciously, ashave 
you all, helped me understand GnuCash better. These are justsigns of how nice 
you all are.




  >Doyou really think you're going to get a

  >differentanswer the N+1st time you post?




IfI have missed it, please help me. I do not remember getting an answerto the 
question “What are the plans to help our users whose booksare out of balance by 
a cent or so?”


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hi Everyone,

On Sat Oct 7 15:48:25 EDT 2023 John Ralls wrote:
    >GnuCash does **NOT** round prices to two decimals. 
    >Prices are always calculated to the full numeric 
    >precision of 1/2^64. Amounts and values are what 
    >get rounded to the respective commodity/currency's 
    >smallest unit. Since 15000 and 137741 have no 
    >common factors GnuCash will represent that as 
    >1500/137741 internally and by default display 
    >it as 10 + 5/137741. 

This is just one more example of the excellent work John has done. Another is 
the outstanding work John did in 2017 developing the rational number portion 
number in the source code in gnc-rational-rounding.hpp, just to cite one 
example. I am also impressed by Jim DeLa Hunt’s expertise in using rational 
numbers.

    >The latter irritates some users so we provide a 
    >preference that will display it as a decimal 
    >with two more fractional digits than the currency's 
    >smallest, so in the case of USD it would display 
    >as $10.8900, 

Thank you for accommodating the GnuCash user. That you do it graciously for 
even the users who are irritated may well be above and beyond the call of duty.

    >but the full fraction is what gets used for any 
    >computations and stored in The pricedb.

This is the excellent precision that GnuCash has. Thank you.

    >
    >Regards,
    >John Ralls

Best Regards,
Bruce McCoy




|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Maf. King]

On Saturday, 7 October 2023 20:03:31 BST Bruce McCoy via gnucash-user wrote:
> Again,we age.

Yes, we do.  
Too quickly to be going around in circles.



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[john]

> On Oct 7, 2023, at 09:54, Bruce McCoy via gnucash-user 
>  wrote:
> The books are out of balance when either the “Computing cost of goods sold” 
> calculations or the “Average Cost price source” differ from the “the trial 
> balance report” calculations. Both of these are more major points. Is our 
> concern here about a relatively major point or about a relatively minor point?

Since you're the only one who's concerned only you can answer that question, 
but you misunderstood "Average Cost price source" with respect to the Trial 
Balance report: Average Cost is one of four price sources available when 
running reports. It's the one that's computed from actual transactions so it's 
the one you *must* use when running the Trial Balance report.

Note as well that GnuCash has no support for cost accounting, so users who need 
to compute CoGS are better served with a proper ERP program like Odoo that does.

> We mentioned that on a certain day, Jeff entered the number of shares he 
> purchased (1,377.41) and the price per share he paid (10.89). GnuCash 
> calculated the Value of the transaction.
> 

Jeff did it wrong. Jeff should enter the number of shares and the amount paid 
and let GnuCash calculate the price, because the price per share he paid wasn't 
10.89, it was 137741/150. 137741 is the product of two primes, 181 and 761, 
so 137741/150 *cannot* be exactly represented as a decimal. It's simpler to 
enter the amount and value than to enter an exact price.

Regards,
John Ralls



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[john]

> On Oct 7, 2023, at 12:39, Bruce McCoy via gnucash-user 
>  wrote:
> 
> 
> IfI have missed it, please help me. I do not remember getting an answerto the 
> question “What are the plans to help our users whose booksare out of balance 
> by a cent or so?”


What you missed is my explanation that if user's books are out of balance it's 
their fault, not GnuCash's. The trial balance report will help them discover 
the imbalance but it's up to the user to decide whether to spend time tracking 
it down or to create a simple correcting transaction to fix it. There are no 
plans to change that.

Regards,
John Ralls

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[john]

GnuCash does **NOT** round prices to two decimals. Prices are always calculated 
to the full numeric precision of 1/2^64. Amounts and values are what get 
rounded to the respective commodity/currency's smallest unit. Since 15000 and 
137741 have no common factors GnuCash will represent that as 1500/137741 
internally and by default display it as 10 + 5/137741. The latter irritates 
some users so we provide a preference that will display it as a decimal with 
two more fractional digits than the currency's smallest, so in the case of USD 
it would display as $10.8900, but the full fraction is what gets used for any 
computations and stored in the pricedb.

Regards,
John Ralls


> On Oct 7, 2023, at 10:25, David Carlson  wrote:
> 
> According to my HP handheld calculator, 15,000.00 divided by 1,377.41
> yields 10.8900.  According to my hp 49g+ scientific graphing calculator,
> 15,000.00 divided by 1,377.41 yields 10.8900037026.  I defy anyone to pay
> that amount per share in U.S. currency.  I am sure the broker's report
> showed $10.89 per share and $15,000.00 total  paid, which is what GnuCash
> would show if the user selected the price to be calculated instead of the
> total amount according to the attached illustration because GnuCash would
> show the price to the nearest cent . If shares were expressed to three
> decimal places as some brokers' statements do, I suspect the missing digit
> would still be zero and the result would not change for this example  .
> Where is the problem?
> 
> On Sat, Oct 7, 2023 at 11:55 AM Bruce McCoy via gnucash-user <
> gnucash-user@gnucash.org> wrote:
> 
>> Hi Everyone,
>> 
>> On Fri, Oct 6 at 1:02 PM John Ralls wrote:
>>> Book out of balance, meaning that the trial balance
>>> report doesn't balance with the Average Cost price
>>> source, nearly always results from not computing
>>> capital gains/losses correctly. Interpret that
>>> broadly:...
>> 
>> The books are out of balance when either the “Computing cost of goods
>> sold” calculations or the “Average Cost price source” differ from the “the
>> trial balance report” calculations. Both of these are more major points. Is
>> our concern here about a relatively major point or about a relatively minor
>> point?
>> 
>>> GnuCash's rounding isn't likely to put books out of
>>> balance because GnuCash forces transactions to be
>>> balance in the transaction currency.
>> 
>> “GnuCash's rounding isn't likely to put books out of balance” is certainly
>> true. GnuCash's routines have a high degree of precision. I’d say John
>> Ralls’ and Jim DeLaHunt’s work on rational numbers is excellent. GnuCash
>> almost always displays an answer correct to two decimals. Can GnuCash ever
>> put the books out of balance?
>> 
>>> GnuCash forces transactions to be
>>> balance in the transaction currency.
>> 
>> In the transaction currency, GnuCash forces transactions to balance with a
>> high degree of precision. This is certainly true. Does GnuCash force
>> transactions, in the transaction currency, to balance in all cases?
>> 
>> In previous posts, we have mentioned Jeff Earickson's experience and
>> comment.
>> 
>> We mentioned that on a certain day, Jeff entered the number of shares he
>> purchased (1,377.41) and the price per share he paid (10.89). GnuCash
>> calculated the Value of the transaction.
>> 
>> Jeff expected the numbers in his transaction line to be as follows:
>> 
>># shares  Price-per-share  Value
>>1,377.4110.89  15,000.00
>> 
>> https://tempsend.com/qekjd has Shares_Price_Value_Calculate_gnu.png.
>> Jeff wanted to see something similar.
>> 
>> The numbers GnuCash calculated were as follows:
>> 
>># shares  Price-per-share  Value
>>1,377.4110.89  14,999.99
>> 
>> Jeff Earickson observed the discrepancy and understood that his books were
>> not in balance due to Ghucash’s calculations. So, Jeff contacted GnuCash.
>> And Mike Novack noticed.
>> 
>> On Sun Feb 23 10:15:34 EST 2014, Mike Novack mentioned Jeff Earickson's
>> comment
>>> "1377.41 x 10.89 = $14,999.99 (one penny off, arrrgh...)"[1].
>> 
>> Jeff seems to want GnuCash to calculate the value of his transaction
>> correctly to, using the convention that ignores the first digit if it is a
>> one, at least 6 significant digits. In this case, GnuCash’s approximations
>> are almost correct.
>> 
>> Jeff wants his transaction line to balance. Jeff states the difference in
>> pennies and also states his reaction to GnuCash’s calculations.
>> 
>> Jeff’s situation is the specific example cited for our discussion of a
>> general situation with GnuCash. This example illustrates the question for
>> consideration.
>> 
>> Our question for discussion is as follows:
>> 
>>> What are the plans to help our users whose
>>> books are out of balance by a cent or so?
>> 
>> 
>> Footnotes:
>> [1]
>> https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053296.html,
>> 
>> 

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hi Everyone,




OnSat, Oct 7 at 1:25 PM David Carlson wrote:

 >Howmany times must you bring up the same 

 >non-point?




Youare right in that I am addressing a community of people who areinterested in 
and actively developing GnuCash. As a community, youuse GnuCash and tolerate 
some of its shortcomings, while improvingthe program. From that perspective, 
this issue may seem to be anon-point. It certainly is a small point. GnuCash 
has developed a lotsince 2000. As GnuCash continues to develop, the major 
points willhave been all, in general, decided. Until resolved, unresolved 
pointswill remain. 




 >Manypeople have explained how arithmetic works,




AndI appreciate their expertise, but that does not address the questionat hand. 




 >JohnRalls has explained how GnuCash works.




Johnhas done excellent work in developing GnuCash and has, graciously, ashave 
you all, helped me understand GnuCash better. These are justsigns of how nice 
you all are.




 >Doyou really think you're going to get a

 >differentanswer the N+1st time you post?




IfI have missed it, please help me. I do not remember getting an answerto the 
question “What are the plans to help our users whose booksare out of balance by 
a cent or so?”

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hi Everyone, 




David,thank you for responding. I appreciate your input.




OnSat, Oct 7 at 1:25 PM David Carlson wrote:

 >Accordingto my HP handheld calculator, 

 >15,000.00divided by 1,377.41 yields 10.8900.   

 >Accordingto my hp 49g+ scientific graphing 

 >calculator,15,000.00 divided by 1,377.41 yields 

 >10.8900037026.




Althoughthose calculators are not available to me, I agree that you are 
quiteright.




 >Idefy anyone to pay that amount per share in 

 >U.S.currency.




Weagree. We have agreement on a critical point.




 >Iam sure the broker's report showed 

 >$10.89per share and $15,000.00 total  paid




Onceagain, we agree.




 >whichis what GnuCash would show if the user 

 >selectedthe price to be calculated instead 

 >ofthe total amount according to the attached 

 >illustration because GnuCashwould show the 

 >priceto the nearest cent




Again,we age.




 >Ifshares were expressed to three decimal places 

 >assome brokers' statements do, I suspect the 

 >missingdigit would still be zero and the 

 >resultwould not change for this example




Onthe Microsoft standard calculator in my windows machine 15,000/10.89= 

1,377.410468319559.David, your supposition is correct. We agree.




 >Whereis the problem?




Accordingto Jeff Earickson, the problem is that his books do not balance. 







Inmy opinion, GnuCash is an excellent program with many experiencedpeople 
interested in it and many experienced developers developingit. I am impressed 
that you are so gracious you will discuss it withme. 




Speakingof $10.8900037026 per share you say, “I defy anyone to pay thatamount 
per share in U.S. currency.” We agree. At one time in thepast, developers of 
GnuCash decided to treat price per share as anapproximation and the number of 
shares traded in a transaction as aprecise number. We agree that no one is 
going to pay$10.890,003,702,6 per share of a stock. You seem to be saying 
that,in this transaction, the purchaser paid $10.890,000,000,0 per shareof the 
stock. If so, that implies that you believe, and we agree, thenumber of shares 
traded might not always be a precise number.




Butregardless of that, the essential issue seems to be, to me, thatGnuCash is 
not yet using numbers with enough significant digits toalways calculate results 
sufficient for our users needs. 




Whatare we going to do for people like Jeff Earickson?

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Stan Brown (using GC 4.14)]

On 2023-10-07 09:54, Bruce McCoy via gnucash-user wrote:
> Our question for discussion is as follows:
> 
>     >What are the plans to help our users whose 
>     >books are out of balance by a cent or so?

In the name of heaven, will you never let it go? How many times must you
bring up the same non-point?

Many people have explained how arithmetic works, and John Ralls has
explained how GnuCash works. Do you really think you're going to get a
different answer the N+1st time you post?

Stan Brown
Tehachapi, CA, USA
https://BrownMath.com/
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[David Carlson]

According to my HP handheld calculator, 15,000.00 divided by 1,377.41
yields 10.8900.  According to my hp 49g+ scientific graphing calculator,
15,000.00 divided by 1,377.41 yields 10.8900037026.  I defy anyone to pay
that amount per share in U.S. currency.  I am sure the broker's report
showed $10.89 per share and $15,000.00 total  paid, which is what GnuCash
would show if the user selected the price to be calculated instead of the
total amount according to the attached illustration because GnuCash would
show the price to the nearest cent . If shares were expressed to three
decimal places as some brokers' statements do, I suspect the missing digit
would still be zero and the result would not change for this example  .
Where is the problem?

On Sat, Oct 7, 2023 at 11:55 AM Bruce McCoy via gnucash-user <
gnucash-user@gnucash.org> wrote:

> Hi Everyone,
>
> On Fri, Oct 6 at 1:02 PM John Ralls wrote:
> >Book out of balance, meaning that the trial balance
> >report doesn't balance with the Average Cost price
> >source, nearly always results from not computing
> >capital gains/losses correctly. Interpret that
> >broadly:...
>
> The books are out of balance when either the “Computing cost of goods
> sold” calculations or the “Average Cost price source” differ from the “the
> trial balance report” calculations. Both of these are more major points. Is
> our concern here about a relatively major point or about a relatively minor
> point?
>
> >GnuCash's rounding isn't likely to put books out of
> >balance because GnuCash forces transactions to be
> >balance in the transaction currency.
>
> “GnuCash's rounding isn't likely to put books out of balance” is certainly
> true. GnuCash's routines have a high degree of precision. I’d say John
> Ralls’ and Jim DeLaHunt’s work on rational numbers is excellent. GnuCash
> almost always displays an answer correct to two decimals. Can GnuCash ever
> put the books out of balance?
>
> >GnuCash forces transactions to be
> >balance in the transaction currency.
>
> In the transaction currency, GnuCash forces transactions to balance with a
> high degree of precision. This is certainly true. Does GnuCash force
> transactions, in the transaction currency, to balance in all cases?
>
> In previous posts, we have mentioned Jeff Earickson's experience and
> comment.
>
> We mentioned that on a certain day, Jeff entered the number of shares he
> purchased (1,377.41) and the price per share he paid (10.89). GnuCash
> calculated the Value of the transaction.
>
> Jeff expected the numbers in his transaction line to be as follows:
>
> # shares  Price-per-share  Value
> 1,377.4110.89  15,000.00
>
>  https://tempsend.com/qekjd has Shares_Price_Value_Calculate_gnu.png.
> Jeff wanted to see something similar.
>
> The numbers GnuCash calculated were as follows:
>
> # shares  Price-per-share  Value
> 1,377.4110.89  14,999.99
>
> Jeff Earickson observed the discrepancy and understood that his books were
> not in balance due to Ghucash’s calculations. So, Jeff contacted GnuCash.
> And Mike Novack noticed.
>
> On Sun Feb 23 10:15:34 EST 2014, Mike Novack mentioned Jeff Earickson's
> comment
> >"1377.41 x 10.89 = $14,999.99 (one penny off, arrrgh...)"[1].
>
> Jeff seems to want GnuCash to calculate the value of his transaction
> correctly to, using the convention that ignores the first digit if it is a
> one, at least 6 significant digits. In this case, GnuCash’s approximations
> are almost correct.
>
> Jeff wants his transaction line to balance. Jeff states the difference in
> pennies and also states his reaction to GnuCash’s calculations.
>
> Jeff’s situation is the specific example cited for our discussion of a
> general situation with GnuCash. This example illustrates the question for
> consideration.
>
> Our question for discussion is as follows:
>
> >What are the plans to help our users whose
> >books are out of balance by a cent or so?
>
>
> Footnotes:
>  [1]
> https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053296.html,
>
> https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053299.html
> .
>
>
>
> |  | Virus-free.www.avast.com |
>
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


-- 
David Carlson
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hi Everyone,

On Fri, Oct 6 at 1:02 PM John Ralls wrote:
    >Book out of balance, meaning that the trial balance
    >report doesn't balance with the Average Cost price
    >source, nearly always results from not computing
    >capital gains/losses correctly. Interpret that
    >broadly:...

The books are out of balance when either the “Computing cost of goods sold” 
calculations or the “Average Cost price source” differ from the “the trial 
balance report” calculations. Both of these are more major points. Is our 
concern here about a relatively major point or about a relatively minor point?

    >GnuCash's rounding isn't likely to put books out of
    >balance because GnuCash forces transactions to be
    >balance in the transaction currency.

“GnuCash's rounding isn't likely to put books out of balance” is certainly 
true. GnuCash's routines have a high degree of precision. I’d say John Ralls’ 
and Jim DeLaHunt’s work on rational numbers is excellent. GnuCash almost always 
displays an answer correct to two decimals. Can GnuCash ever put the books out 
of balance?

    >GnuCash forces transactions to be
    >balance in the transaction currency.

In the transaction currency, GnuCash forces transactions to balance with a high 
degree of precision. This is certainly true. Does GnuCash force transactions, 
in the transaction currency, to balance in all cases?

In previous posts, we have mentioned Jeff Earickson's experience and comment.

We mentioned that on a certain day, Jeff entered the number of shares he 
purchased (1,377.41) and the price per share he paid (10.89). GnuCash 
calculated the Value of the transaction.

Jeff expected the numbers in his transaction line to be as follows:

    # shares  Price-per-share  Value
    1,377.41    10.89  15,000.00

 https://tempsend.com/qekjd has Shares_Price_Value_Calculate_gnu.png. Jeff 
wanted to see something similar.

The numbers GnuCash calculated were as follows:

    # shares  Price-per-share  Value
    1,377.41    10.89  14,999.99

Jeff Earickson observed the discrepancy and understood that his books were not 
in balance due to Ghucash’s calculations. So, Jeff contacted GnuCash. And Mike 
Novack noticed.

On Sun Feb 23 10:15:34 EST 2014, Mike Novack mentioned Jeff Earickson's comment
    >"1377.41 x 10.89 = $14,999.99 (one penny off, arrrgh...)"[1]. 

Jeff seems to want GnuCash to calculate the value of his transaction correctly 
to, using the convention that ignores the first digit if it is a one, at least 
6 significant digits. In this case, GnuCash’s approximations are almost correct.

Jeff wants his transaction line to balance. Jeff states the difference in 
pennies and also states his reaction to GnuCash’s calculations.

Jeff’s situation is the specific example cited for our discussion of a general 
situation with GnuCash. This example illustrates the question for consideration.

Our question for discussion is as follows:

    >What are the plans to help our users whose 
    >books are out of balance by a cent or so?


Footnotes: 
 [1] 
https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053296.html, 
https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053299.html.



|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[John Ralls]

> On Oct 6, 2023, at 9:39 AM, Bruce McCoy via gnucash-user 
>  wrote:
> 
> Hi Everyone,
> On Tue, Sep 26 at 12:50 PM John Ralls wrote:>GnuCash uses a pair of 
> stack-allocated 128-bit integers (see. . . 
> 
> Thanks. Well done.
> 
> 
> What are the plans to help our users whose books are out of balance by a cent 
> or so?

GnuCash's rounding isn't likely to put books out of balance because GnuCash 
forces transactions to be balance in the transaction currency. Book out of 
balance, meaning that the trial balance report doesn't balance with the Average 
Cost price source, nearly always results from not computing capital 
gains/losses correctly. Interpret that broadly: Computing cost of goods sold is 
the same calculation by a different name and often crossing more transaction 
steps. GnuCash automates only the simplest case via the lot scrubber so it's 
pretty much up to the user to be meticulous when creating those 
splits/transactions.

Regards,
John Ralls

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hi Everyone,
On Tue, Sep 26 at 12:50 PM John Ralls wrote:    >GnuCash uses a pair of 
stack-allocated 128-bit integers (see. . . 

Thanks. Well done.


What are the plans to help our users whose books are out of balance by a cent 
or so?

Best Regards,
Bruce


|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hi,

 

On9/25/2023 9:50 PM, Adrien Monteleone wrote:
    >you likely can't send zip files through this >mailman instance.



OK.I wondered about that. Thanks.



    >postthem on a hosting site and simply >paste the links in 
another reply.
  


OK.230925__to_Jim_DeLaHunt_gnucash-users.zip is just the post of Sept 25with 
graphics. It is at https://tempsend.com/juqkx



 >textspacing

Thankyou for telling me. Using a mono-spaced font corrected the situation.




OnTue, Sep 26 at 9:16 AM Michael Novack wrote:
    >Whenperforming arithmetic operations with >EXACT values we can 
expect to    >getthe same final result regardless of the >order in 
which the operationsare performed >(as long as a legal order).    >
    >Whenperforming arithmetic operations with >ROUNDED values we 
can NOT expectto get the >same final result.



Wellsaid. That is the point which was to be made. Changing the order 
ofrounding, as you said, can change the rounded results. Also, I havefaced 
similar government forms, as you have. I am glad to know youwere successful in 
completing them.

 

BestRegards.

Bruce



|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Tom Browder]

On Tue, Sep 26, 2023 at 11:50 john  wrote
…

Thanks, John—nice work!

-Tom
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[john]

> On Sep 26, 2023, at 08:31, Tom Browder  wrote:
> 
> On Mon, Sep 25, 2023 at 20:07 Bruce McCoy via gnucash-user <
> gnucash-user@gnucash.org> wrote:
> ...discussion of GnuCash's handling of numbers...
> 
> Does GnuCash use the Gnu Multiple Precision Arithmetic (GMP) library?

No. Like all infinite precision numerical methods it allocates from the heap 
and that makes it too slow. GnuCash uses a pair of stack-allocated 128-bit 
integers (see 
https://github.com/Gnucash/gnucash/blob/stable/libgnucash/engine/gnc-int128.hpp)
 to compose rational numbers 
(https://github.com/Gnucash/gnucash/blob/stable/libgnucash/engine/gnc-rational.hpp)
 for computation that's reduced to int64_t-based rationals 
(https://github.com/Gnucash/gnucash/blob/stable/libgnucash/engine/gnc-numeric.hpp)
 for presentation and storage. Intermediate results are reduced to help prevent 
overflows and a variety of rounding techniques are implemented in 
https://github.com/Gnucash/gnucash/blob/stable/libgnucash/engine/gnc-rational-rounding.hpp.

Regards,
John Ralls

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Tom Browder]

On Mon, Sep 25, 2023 at 20:07 Bruce McCoy via gnucash-user <
gnucash-user@gnucash.org> wrote:
 ...discussion of GnuCash's handling of numbers...

Does GnuCash use the Gnu Multiple Precision Arithmetic (GMP) library?

-Tom
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Michael or Penny Novack]

On 9/25/2023 9:50 PM, Adrien Monteleone wrote:
It still did not come through as you likely can't send zip files 
through this mailman instance.


What exactly are you sending, just images? Attach them individually, 
or else post them on a hosting site and simply paste the links in 
another reply. 



But perhaps more basic, necessary is an understanding of what is meant 
by "rounding errors".


When performing arithmetic operations with EXACT values we can expect to 
get the same final result regardless of the order in which the 
operations are performed (as long as a legal order).


When performing arithmetic operations with ROUNDED values we can NOT 
expect to get the same final result. By which I mean that in general the 
final result will depend on the order of operations, where rounding 
takes place, and on the "location" of rounding (how many decimal places, 
how many significant digits retained, etc.).


For example  A x (B - C) can be quite different from (A x B) - (A x 
C) if A is large and B and C close in size. Even when all we are doing 
is adding, the final result of Rounded A + Rounded B + Rounded C + 
 + Rounded X + Rounded Y can be quite different from Rounded ( A 
+ B + C + . + X + Y) if that is large number of terms.


So . when you say "error" you SHOULD mean "given a specified order 
and points of rounding". But if you are talking about differences caused 
by different order of operations and points of rounding you should be 
using some other term than "error". It is quite valid to argue in favor 
of a different order of operations or points of rounding but not to call 
some other order or points of rounding WRONG. Not unless a claimed value 
of "fuzz" is not being met.


And I am unaware of gnucash promising some maximum value of "fuzz"

LOL --- I have filled out many government filings where a specified 
(final) point of rounding was required. For example, "file amounts in 
whole dollars". But since that report might also require showing 
individual amounts and subtotals of various of them in addition to final 
totals, everything in whole dollars, and in balance, a certain amount of 
juggling can be required. Requires fudging some of the amounts up or 
down a bit instead of using the "correct" rounded amount. USUALLY, with 
careful choice of which amounts, can be done by the substitution of 
"floor" for "rounded" for just a couple amounts. The "sport" is figuring 
out the minimum amount of fudging required.



Michael D Novack

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Adrien Monteleone]

It still did not come through as you likely can't send zip files through 
this mailman instance.


What exactly are you sending, just images? Attach them individually, or 
else post them on a hosting site and simply paste the links in another 
reply.


---
And it seems at least in this last message, you figured out whatever 
weird text spacing issue you were having...


Regards,
Adrien

On 9/25/23 8:24 PM, Bruce McCoy via gnucash-user wrote:

Since this is a relatively long post, there are summaries at each end. The first section runs 
through "Old Business." The second section starts with "New Business."
The third section is just the attachment. To see the illustrations, please 
unzip the attachment,if present. SpamAssassin blocked the attachment.I do not 
know how to get the attachment to you. I am sorry.


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

 Hi everybody,

Since this is a relatively long post, there are summaries at each end. The 
first section runs through "Old Business." The second section starts with "New 
Business." 
The third section is just the attachment. To see the illustrations, please 
unzip the attachment,if present. SpamAssassin blocked the attachment.I do not 
know how to get the attachment to you. I am sorry.


Cordially,

Bruce


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hieverybody,


Sincethis is a relatively long post, there are summaries at each end. Thefirst 
section runs through "Old Business." The secondsection starts with "New 
Business." The third section isjust the attachment. To see the illustrations, 
please unzip theattachment,if present.




Cordially,

Bruce


New Business



The rational fraction you enter asinput is perfectly correct. Every 
approximation introduces an error.In GnuCash's case, John says, "GnuCash's 
number system usesrational numbers represented as the ratio of two 64-bit 
integers;that allows a lot of precision but not infinite precision. Prices 
maybe rounded to be representable. That's unlikely to have a materialeffect on 
any calculation, unlike the rounding of quantities..."So, John says at least 
two things. GnuCash approximates rationalnumbers and GnuCash's approximation is 
not of infinite precision, butpretty close, compared to the other 
approximations GnuCash uses inits internal calculations for quantities.







The following section addressesfour areas. Each area will tend to be addressed 
in the order in whichit is mentioned in your post.

1. The rational fraction you enteras input is exactly correct.

2. TerryBoldt's asserts thatin processing the input data approximations may be 
used. Is Terry'sassertion supported or not?

3. If approximations are not used,GnuCash needs no changes in precision. If 
approximations are used, arelatively simple change could be implemented to 
balance one's books.

4. I appreciate the care each ofyou has taken in reading and responding to 
these posts.




On 2023-09-14 20:43:29EDT, JimDeLaHunt via gnucash-user wrote:

 >Wait,you skipped a step. You have still not demonstrated that the 

 >currentimplementation is wrong. I believe that for securities 

 >transaction,GnuCash gives a result which is both correct (satisfies the 

 >equationrelating price, quantity, and amount) and precisely accurate 

 >(givesthe require numbers with zero difference from the true result). 




Jeff Earickson noticed that GnuCashis occasionally not precise enough. He wants 
his books to balance,but they don't.




Terrysays that on the occasions in which the computer is unable tocalculate 
exactly correctly, he was forced to use an approximation.Once upon a time, it 
was common to say, "Garbage in; garbageout." This phrase recognized that if one 
entered nonsense datainto a computer it would produce, as a rule, nonsense on 
output. Ofcourse, what we all hope is that if we enter exactly correct data, 
asdone in this specific case, the computer will output data that isalso 
correct. If this were not to be the case, can we imagine ourfeelings?




IfGnuCash is no longer using an approximation, then it is quitepossible that 
GnuCash gives a result which is both correct andprecisely accurate?" If GnuCash 
is still using an approximation,could it be that "GnuCash gives a result which 
appears to beboth correct (almost all the time) and (very close to 
being)precisely accurate?"




IfTerry's approximation, or a similar one, is still present in GnuCash.Would 
one implication be that, on occasion, a user would find thatGnuCash has output 
a result that is only very close to being exactlycorrect?




 >Anyother arithmetic library dropped into GnuCash would give exactly the 

 >sameresult.




(Aside: Frankly, I'd like this tobe the case. If GnuCash were exactly precise, 
then we would not haveto be concerned about any imprecision in it.)




GnuCash is among the programs thatneeds high precision in their calculations. 
Other programmers havedeveloped approximations of greater precision to provide 
theprecision needed for their calculations. For financial applications,decimal 
libraries have been developed. Development occurred between2000, when Terry 
wrote GnuCash, and 2003; development has onlyaccelerated in the two decades 
since.




Could we ask, "If Terry'sapproximations are always precise enough, why did so 
many people doso much work to improve their precision and why did they also 
gothrough the additional effort to develop decimal libraries?" Ifwe did, one 
might suppose that either they wasted their time andeffort or they had good 
reasons to do the work.




Gnucash appears to be, to me, anexcellent program. I am impressed by all the 
fine work that has beenand is being done on it. And I would like to use it.




GnuCash almost always calculatesfinancial information to the precision required 
for work at hand. Inmy understanding of it, the incremental change under 
consideration isthe difference between "excellent" and "perfect."For our 
financial calculations precision, I'd say GnuCash isapproximately one smidgen 
away from being perfectly suitable.




Of course, there are things I donot know about the proposed revision. Will the 
programmers find itmore feasible to just increase the precision of the 
calculations wenow have, will they be able to utilize the decimal 
arithmeticlibraries easily? 

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Hieverybody,




Congratulationson releasing GnuCash 5.4. You are doing excellent work. Thank 
you somuch.




Sincethis is a relatively long post, there are summaries at each end. Thefirst 
section runs through "Old Business." The secondsection starts with "New 
Business." The third section isjust the attachment. To see the illustrations, 
please unzip theattachment,if present.




Cordially,

Bruce







ExecutiveSummary

=

$Value= $Price-per-share * #Shares is the equation for discussion. 

Tobalance our books, we want that equation to be as precise aspossible.

Sincecomputers calculate on base 2, they can not natively do decimalarithmetic.

Althoughwe may expect exact precision, computers must use approximations.

Inorder of simplicity and correctness, 3 solutions to increaseprecision are:

 1)Manual correction

 2)Approximations of greater precision, and

 3)Decimal arithmetic.







Jim,




You are right. Twice I did notanswer one of your questions. I apologize. I'll 
respond to it first,as it is an "Old Business:"item.




As a newcomer to GnuCash, one ofthe problems that I have is that I do not know 
a lot of things whichyou experienced people take for granted. For example, 
until a fewdays ago, I missed the contributions Ken Farley, John Ralls, and 
StanBrown made on Saturday, September 9th. Had I known how to communicateon 
GnuCash better, I would have responded more promptly. I apologizefor my error 
and will respond to you under Old Business. Thank youfor helping me understand 
how GnuCash works.




Another thing that I have notfigured out is how to maintain spaces separating 
words when I post onGnuCash. I'll try a mono-spaced font to see if that helps. 
If it doesnot help, I'd appreciate your suggestions. 




On Sun Feb 23 10:15:34 EST 2014,Mike Novack mentioned Jeff Earickson's comment 
"1377.41 x 10.89= $14,999.99 (one penny off, arrrgh...)"[1].Jeff seems to want 
GnuCash to calculate the value of his accountcorrectly. What evaluation will we 
place on Jeff's feelings?




What is our position? Are we goingto say, "We want GnuCash to be as imprecise 
as it is currently?"Or are we going to say, "We want GnuCash to be as precise 
ascurrent practices allow?" Will we, if it is possible, accept thechallenge of 
making VALUE more accurate?




Wait, is it possible for VALUE tobe more precise? A rational number, say 1/3, 
is exactly precise. Whenwe enter the rational number into a computer, our 
initial, workingassumption is usually that the machine will accurately compute 
aprecisely correct answer. Is this initial assumption correct orfalse?




"0" or "1" arethe values our computers have to store data. Computers therefore 
mustdo arithmetic using a base of 2. Decimal arithmetic (base 10) isnatively 
impossible for them. Our computers are forced to approximatemany of the values 
we give them. 




If the approximations are notprecise enough, we (GnuCash users) will, on 
occasion, notice theerrors the computer is making. Our current example person 
is JeffEarickson. This thread is to help Jeff and the other people usingGnuCash 
to get more precise results so that their books balance "tothe penny."




Old Business



1. Jim DeLaHunt

---

On 2023-09-09 13:05, Jim DeLaHuntwrote:

 > This would be a greatopportunity for you to answerthe questionI
 repeated to you last message:




I certainly agree. That was mymistake.




 > But I see you skipped over itagain.




I certainly did. Thank you forgiving me another chance.

 >1. if your brokerage reports a transaction in terms of price,currency 
 > received and paid, and shares received andissued, which are logically 
 > inconsistent, how should youinterpret that information? This is a 
 > step you have totake before entering the transaction into your 
 >bookkeeping.

Iagree, "If a brokerage reports a logically inconsistenttransaction, before 
entering that transaction into a ledger, oneshould carefully interpret the 
inconsistency." What is themagnitude of the inconsistencies under discussion?




TerryBoldt wrote "The division operation is done in 'double' since Ido not 
think that anybody really wants (9 / 2) to equal 4 instead of4.5 for financial 
operations." FederatedHermes (FH) has not sentme something similar to "You sent 
us a purchase order of $9.00to buy a stock now priced at $2.00/share, so we 
increased yourholdings by 4 shares (1 significant figure). We are not charging 
youany commission. You get no change." Had that type of notice beensent, I'd 
change brokers.




Terrymentions the term "double." My current understanding of theterm is 
"double" is an abbreviated reference to "doubleprecision" calculation and 
"double" offers moreprecision then "single precision" calculation. When 
Terrywrites "since I do not think that anybody really wants (9 / 2)to equal 4 
instead of 4.5 for financial operations," he is, ineffect, saying that, when 
dividing, the computer is not always usingthe 

Re: [GNC] gnucash_user: rounding errors and significant digits

[Jim DeLaHunt]

Bruce:

On 2023-09-14 14:51, Bruce McCoy via gnucash-user wrote:

...Whatare some of the options available to GnuCash programmers today toimprove 
precision? Here is one group
[Long list of arithmetic libraries elided]
Wait, you skipped a step. You have still not demonstrated that the 
current implementation is wrong. I believe that for securities 
transaction, GnuCash gives a result which is both correct (satisfies the 
equation relating price, quantity, and amount) and precisely accurate 
(gives the require numbers with zero difference from the true result).  
Any other arithmetic library dropped into GnuCash would give exactly the 
same result.

Whatcan we do while awaiting a, say, decimal arithmetic or arbitraryprecision 
arithmetic software or some other excellent solution? Ifthe GnuCash community 
would like to have Gnucash software match thestatements from the investment 
firms calculating their holdings orthe members' own records, ...


This would be a great opportunity for you to answer the question I 
repeated to you last message:


On 2023-09-09 13:05, Jim DeLaHunt wrote:

1. if your brokerage reports a transaction in terms of price, currency 
received and paid, and shares received and issued, which are logically 
inconsistent, how should you interpret that information? This is a 
step you have to take before entering the transaction into your 
bookkeeping.


But I see you skipped over it again.


Currently,given the cost of the transaction and the number of shares 
traded,GnuCash calculates the price per share. On occasion, the 
Gnucashcalculation results are unexpected. In our example at hand, ... if we 
could allow the user to enter $15.00, we wouldhave a solution, albeit a manual 
one.


Ah, maybe now we are getting somewhere.

GnuCash does allow you to enter the exact value of $15.00 for the 
transaction amount. You do not need to enter a price. Have you tried 
this in the GnuCash UI?


When you try to enter the example transaction at hand (broker sells 
2.396 of shares to pay a fee of $15.00), you are probably using the 
stock transaction register. The Tutorial and Guide[1], section 9.7. 
Selling Shares [2], explains this UI. Specifically, see Figure 9.21. 
"Selling Shares for Gain Where the Sale and Gain are Recorded in 
Separate Transactions, in Transaction Journal View"[3].


(These numbers in square brackets are footnootes to URLs. I put the full 
URLs at the bottom of the message to make this part easier to read.)


The second transaction if Figure 9.21 is similar to what you would enter.
1. The line with account "Assets:Bank ABC" has 0 in the Buy column, or 
you leave it out entirely. The example transaction at hand does not 
touch the cash account associated with this brokerage.
2. The line with account "Expenses:Commission:AMZN" would instead have 
the expense account you use to track the fee which your brokerage is 
charging, and has the value 15.00 in the Buy column.
3. The line with account "Assets:Brokerage Account:Stock:AMZN" is the 
one with the UI which matters here. When you enter the transaction, type 
"-2.396" in the Shares column, leave the Price column empty, and type 
"15.00" in the Sell column.


When you save the transaction, GnuCash will fill in the price for you. 
What I see it fill in is, "6 + 156/599". This is equal to the rational 
number 3750/599. We saw this number before, as the price which exactly 
relates 2.396 shares to the $15.00 transaction amount.


This UI is also explained in the Tutorial and Guide, section 9.5 Buying 
Shares[4]. It says there,


…On the first split line, enter *|100|* in *Shares*, delete the (unit) 
*Price* (it will be calculated when you *Tab* out of the split) and 
enter *|2000|* in the *Buy* column.


Note

It is also possible to use *|GnuCash|* to calculate *Shares* or *Buy* 
from the other 2 columns. But to avoid rounding errors, it is better 
to automatically calculate *Price*.


Have you tried entering this stock transaction without entering the 
price, and letting GnuCash calculate it for you?



...GnuCashcalculates $value = $price/share * #shares
Well, GnuCash will calculate whichever single value of these three that 
you do not enter, as long as you provide the other two. The recommended 
way to do it is to enter #shares and $value, and let GnuCash calculate 
$price/share .

...A screen showing thosethree results in data-entry fields instead of 
read-only fields wouldallow the user to change the aberrant result, which could 
be saved


The stock transaction register provides exactly these data-entry fields. 
They are not read-only. Do you see, in your copy of GnuCash, something 
similar to the UI depicted in Figure 9.21?


Also, have you read through all of Section 9 of the Tutorial and 
Concepts Guide?  Have you made a simple book for learning purposes, with 
made-up data, and followed along with the examples in the Guide?  If 
not, I highly recommend it to you. It is an excellent way to learn 

Re: [GNC] gnucash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Jim,

 

Whatare some of the options available to GnuCash programmers today toimprove 
precision? Here is one group.




Decimal-FloatingArithmetic 

GeneralDecimal Arithmetic 

 http://speleotrove.com/decimal 

 http://speleotrove.com/decimal/#decNumber

 http://speleotrove.com/decimal/#links

 http://speleotrove.com/decimal/#implement

ThedecNumber Library Version 3.68 

 https://speleotrove.com/decimal/decnumber.html

decimal— Decimal fixed point and floating point arithmetic 

 https://speleotrove.com/decimal/decarith.html



C++libraries Decimal-Arithmetic

GMP 

 https://gmplib.org/

GNUMPFR Library 

 https://www.mpfr.org/

 https://www.mpfr.org/ports.html

 https://github.com/microsoft/vcpkg.git (Windows)

mpdecimal

 https://www.bytereef.org/mpdecimal/




Java

ClassBigInteger 

 https://docs.oracle.com/javase/8/docs/api/java/math/BigInteger.html

Usesof Class java.math.BigDecimal 

 https://docs.oracle.com/javase/8/docs/api/java/math/class-use/BigDecimal.html




Python Decimal-Arithmetic

15.Floating Point Arithmetic: Issues and Limitations  python

 https://docs.python.org/3/tutorial/floatingpoint.html

cdecimal- Python module (2.7 – 3.2) 

 https://www.bytereef.org/mpdecimal/doc/cdecimal/index.html




DecimalArithmetic Functions 

 
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/automat/decimal-arithmetic-functions?redirectedfrom=MSDN




Listof arbitrary-precision arithmetic software 

 https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software




IEEE754-2008 revision 

 IEEE 754-2008 revision - Wikipedia


| 
| 
|  | 
IEEE 754-2008 revision - Wikipedia

IEEE 754-2008 (previously known as IEEE 754r) is a revision of the IEEE 754 
standard for floating-point arithmet...
 |

 |

 |







 




Justto name two that probably everyone in this area knows, the GNUMultiple 
Precision Arithmetic Library version 6.3.0 and the MPFRMultiple Precision 
Floating Point Reliable Library were released in2023. I have no idea which of 
all these resources would be preferredby the understaffed and overworked 
GnuCash programmers.

 

Whatcan we do while awaiting a, say, decimal arithmetic or arbitraryprecision 
arithmetic software or some other excellent solution? Ifthe GnuCash community 
would like to have Gnucash software match thestatements from the investment 
firms calculating their holdings orthe members' own records, we could consider 
making a suggestion whichwould be relatively easy to code. 

 

Currently,given the cost of the transaction and the number of shares 
traded,GnuCash calculates the price per share. On occasion, the 
Gnucashcalculation results are unexpected. In our example at hand, you 
find"Logically, $value = $price/share * #shares, and this should beprecise 
equality. But is possible for a brokerage statement to reportvalues which do 
not have precise equality. It sounds like FederatedHermes reported $15.00 = 
$6.26 * 2.396, but the actual $value of this$price and #shares is $14.99896, a 
difference of $0.00104."

 

Inthis example, if we could allow the user to enter $15.00, we wouldhave a 
solution, albeit a manual one.




GnuCashcalculates $value = $price/share * #shares. A screen showing thosethree 
results in data-entry fields instead of read-only fields wouldallow the user to 
change the aberrant result, which could be saved. The computer could be 
instructed to not re-calculate these threevalues again, until, say, the user 
changed one of them to null orzero. Such a process is relatively simple to 
program. It wouldserve the purpose until a perfect solution was developed.

 

Isthe GnuCash community be interested in having the values in GnuCashand the 
brokerage statements be identical? 

Ifyou are a member of the GnuCash community, here is an invitation toexpress 
yourself concerning this topic. Feel free to comment




BestRegards,

Bruce









|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Jim DeLaHunt]

Hello again, Bruce!

I can point out a logic error in your argument here.

On 2023-09-13 17:28, Bruce McCoy via gnucash-user wrote:

...Yousay that 3750/599 is "the more accurate." How precise isit? Let's see.

2.396shares * (3750/599) $/share = 2.396 shares 
*6.260434056761268781302170283806343906510851419
3171953255425709515859766277128547579298831385642737 $/share
= $15.
06837852.
So, thefraction is accurate to 51 significant digits


By converting the rational number (3750/599) into a decimal number 
6.260434..., you introduce a numerical error. The decimal number,


    6.26043405676126878130 2170283806343906510 8514193171953255425 
709515859766277128 547579298831385642737


is equal to the rational number,

    626043405676126878130 2170283806343906510 8514193171953255425 
709515859766277128 547579298831385642737 / 1  
000 000 00 
0


This is a fraction in reduced form, since the numerator does not have 2 
or 5 as factors. (This is easy to tell by inspection, because integers 
with 2 as a factor have an even number as the final digit, and integers 
with 5 as a factor have 0 or 5 as the final digit.)


The above fraction does not have the same numerical value as the price I 
think is correct to use for your example transaction,


    3750/599

The inaccurate decimal number you use as the price leads to an 
inaccurate value for the resulting dollar amount. You show this 
inaccuracy in the result.


So, rather than changing the numerical value of the price before 
multiplying it by the number of shares, how about using that exact value?


2.396 = (2396/1000)  by the definition of decimal number notation

2.396 shares * (3750/599) $/share = (2396/1000)*(3750/599) = 
((4*599)/1000)*(3750/599)

    = ((4*1)/1000)*(3750/1) = (4*3750)/1000 = 15000/1000 = 15.00... $

Thus, when GnuCash derives the price from the number of shares and the 
transaction amount, and stores it as a rational number, it ensures that 
our basic relationship,


    $value = $price/share * #shares

is precisely satisfied.

You ask,


In September of 2003, we have a lot better options than Terry did in2000. What 
are some of the ones we prefer?
By my calendar, this is September of 2023 not 2003, and we have even 
better options available now than we did in 2003. However, the option 
GnuCash uses now seems to give correct, exactly precise answers. Why change?


By the way, you did not respond to my question,

On 2023-09-09 13:05, Jim DeLaHunt wrote:
1. if your brokerage reports a transaction in terms of price, currency 
received and paid, and shares received and issued, which are logically 
inconsistent, how should you interpret that information? This is a 
step you have to take before entering the transaction into your 
bookkeeping.


I think that your answer to this question might really help you get to 
the bottom of what is driving you in this thread.


Best regards,
    —Jim DeLaHunt


On 2023-09-13 17:28, Bruce McCoy via gnucash-user wrote:

Jim,

  


Inyour response of Mon, Aug 21, 2023 at 5:00 PM via GnuCash-user yousaid:




  "Logically,$value = $price/share * #shares, and this should be 
preciseequality."

  


  GnuCash“stores the price as a rational number, a ratio between numeratorand 
denominator,”




  "price= 15000/2396 = 3750/599 $/share...the more accurate 3750/599."

  


Let'ssee what GnuCash, excellent program that it is, does with the exact(price 
per share) fraction it was given to use. If GnuCash does thecalculation 
correctly, then

$value= $price/share * #shares will be a precise equality. If GnuCashdoes the 
calculation incorrectly, then

$value= $price/share * #shares will not be a precise equality.




Yousay that 3750/599 is "the more accurate." How precise isit? Let's see.

  


2.396shares * (3750/599) $/share = 2.396 shares 
*6.260434056761268781302170283806343906510851419

3171953255425709515859766277128547579298831385642737 $/share = 
$15.

06837852. 
So, thefraction is accurate to 51 significant digits. With 51 
significantdigits, one would be precise 
to$23,456,789,012,345,678,901,234,567,890,123,456,789,012,345,678,901.23.Even 
if you had only 17 significant digits, you could have aprecision up to 
$123,456,789,012,345.67. Ifyou asked me, even if I reached 100, my portfolio 
would never comeclose to even the much more modest, second estimate.)




Onmy Windows 10 machine, GnuCash shows 6 + 156/599 = 6.260434057$/share (10 
significant digits). In a spreadsheet preferencessetting, we see about the same 
number of significant digits. In thisexample, GnuCash is losing 41 significant 
digits. Why?

  


Inexpression-parser.c, we find that on Wednesday June 21 2000 TerryBoldt informs us 
"The division operation is done in 

Re: [GNC] GnuCash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Jim,

 

Inyour response of Mon, Aug 21, 2023 at 5:00 PM via GnuCash-user yousaid:




 "Logically,$value = $price/share * #shares, and this should be 
preciseequality."

 

 GnuCash“stores the price as a rational number, a ratio between numeratorand 
denominator,”




 "price= 15000/2396 = 3750/599 $/share...the more accurate 3750/599."

 

Let'ssee what GnuCash, excellent program that it is, does with the exact(price 
per share) fraction it was given to use. If GnuCash does thecalculation 
correctly, then 

$value= $price/share * #shares will be a precise equality. If GnuCashdoes the 
calculation incorrectly, then 

$value= $price/share * #shares will not be a precise equality. 




Yousay that 3750/599 is "the more accurate." How precise isit? Let's see.

 

2.396shares * (3750/599) $/share = 2.396 shares 
*6.260434056761268781302170283806343906510851419

3171953255425709515859766277128547579298831385642737 $/share = 
$15.

06837852. 
So, thefraction is accurate to 51 significant digits. With 51 
significantdigits, one would be precise 
to$23,456,789,012,345,678,901,234,567,890,123,456,789,012,345,678,901.23.Even 
if you had only 17 significant digits, you could have aprecision up to 
$123,456,789,012,345.67. Ifyou asked me, even if I reached 100, my portfolio 
would never comeclose to even the much more modest, second estimate.)




Onmy Windows 10 machine, GnuCash shows 6 + 156/599 = 6.260434057$/share (10 
significant digits). In a spreadsheet preferencessetting, we see about the same 
number of significant digits. In thisexample, GnuCash is losing 41 significant 
digits. Why?

 

Inexpression-parser.c, we find that on Wednesday June 21 2000 TerryBoldt 
informs us "The division operation is done in 'double'since I do not think that 
anybody really wants (9 / 2) to equal 4instead of 4.5 for financial operations."

Scanningthe source for "long double" returned nothing. 

 

Onx86, Double is 53bit mantissa or 16 round safe digits. Long Double"tends to 
be the 80-bit extended format: 64bits of mantissa,15bits of exponent, probably 
going to be around 18 round safedigits."(1) So, I suppose we lost a lot of 
significant digitshere in GnuCash. If this is not the case, please help. If 
this isthe case, we need more precision in GnuCash. 




InSeptember of 2003, we have a lot better options than Terry did in2000. What 
are some of the ones we prefer?

 

BestRegards,

Bruce







(1) 
https://stackoverflow.com/questions/476212/what-is-the-precision-of-long-double-in-c



|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] gnucash_user: rounding errors and significant digits

[Jim DeLaHunt]

Hello, Bruce:

I would like to reply to a few places in your detailed message where I 
think I can clarify the argument.



On 2023-09-09 10:59, Bruce McCoy via gnucash-user wrote:

     "he actual $value of this $price and #shares is $14.99896, a difference of 
$0.00104."

At the moment, using these figures, GnuCash is (14.99896/15.000) * 100 = 
99.9930666... % correct


I think you left out part of my statement, and so made an incorrect 
conclusion. I wrote:


On 2023-08-21 14:00, Jim DeLaHunt wrote:
Logically, $value = $price/share * #shares, and this should be precise 
equality. But is possible for a brokerage statement to report values 
which do not have precise equality. It sounds like Federated Hermes 
reported $15.00 = $6.26 * 2.396, but the actual $value of this $price 
and #shares is $14.99896, a difference of $0.00104.


You say that GnuCash is the entity which is "99.9930666... % 
correct". I argued that it was Federated Hermes which was 
"99.9930666... % correct.  Before you worry about GnuCash's 
handling of securities transactions, you should decide how you are going 
to interpret the error of 0.0069...% in the brokerage statement's 
numbers.


You continue,

On 2023-09-09 10:59, Bruce McCoy via gnucash-user wrote:

For the moment, let's discuss a  minor point.
   
     "GnuCash takes the position that price is approximate and transient, but currency received and paid, and     shares received and issued, are exact and persistent. Thus a GnuCash securities transaction stores the number     of shares and the currency value of the transaction, and derives the price as $value/#shares..."


In this minor point, the viewpoint that the smallest units of currency are considered exact both by 
governments and their financial companies will be investigated.  One conclusion will be that GnuCash should 
consider "price" and "currency received" as exact figures.  A second is that GnuCash 
should consider "shares received and issued" as an approximation, although it is not always true


I believe you misunderstood my statement, in the quotation. I made no 
comment about "the smallest units of currency". I said that "GnuCash 
takes the position that... currency received and paid, and shares 
received and issued, are exact and persistent." That is true regardless 
of what the smallest unit of currency is.


You conclude, 'GnuCash should consider "price"... as exact figures.' No, 
I said something quite different: "GnuCash takes the position that price 
is approximate and transient...".


You conclude, 'GnuCash should consider "shares received and issued" as 
an approximation, although it is not always true' No, I said 
something quite different: "GnuCash takes the position that... shares 
received and issued, are exact and persistent" — not an approximation.


You give an example:

On 2023-09-09 10:59, Bruce McCoy via gnucash-user wrote:

...If someone were to ask us whether the way GnuCash treats the currency pricing is either 
"approximate and transient" in the case of $6.26 per share or "exact and 
persistent"  in the case of the $15.00 annual account fee, what could our answer be?   Buying 
one share will cost 626 pennies.  The annual fee is 1,500 pennies.  Other than the quantity of 
them, what is the essential difference in the pennies used to purchase a share and the pennies used 
to pay the fee?


Our answer to your first question should be, "approximate and 
transient". Buying one share costs (the currency value of the 
transaction) divided by (the number of shares received and issued).  
Thus, buying one share in this transaction costs 3750/599 $/share. The 
brokerage statement's printed price of $6.26 per share is an 
approximation of the actual price which the brokerage charged you. Our 
answer to your second question should be, that you are using one word, 
"pennies", to describe two different quantities — price, and currency 
paid — and thus obscuring the essential difference that the first 
quantity is by design derived from the second quantity.


Now on to the logical leap you make later in your message:

On 2023-09-09 10:59, Bruce McCoy via gnucash-user wrote:

...We could say "GnuCash takes the position that price is approximate and transient, 
but currency received and paid, and shares received and issued, are exact and 
persistent."  Essentially that is how we have always considered the matter.
   
Is "We have always done it this way." a compelling response? ...


Yes, I think the first quote is an accurate statement of GnuCash's 
design for recording securities transactions. The second statement, 
"that is how we have always considered the matter", is a claim about 
history. I don't know if it is true. Maybe GnuCash had a different 
design in the past. I don't know.


But your next sentence frames "we have always done it this way" as a 
supposed _justification_ for GnuCash's current design. I did not say 

Re: [GNC] gnucash_user: rounding errors and significant digits

[Stan Brown (using GC 4.14)]

On 2023-09-09 12:19, Ken Farley wrote:
> I really don't see what is so difficult to understand about this.
> 
> The key equation is AMOUNT = PRICE * SHARES
> 
> Gnucash works under the philosophy that two of those terms must be
> maintained precisely:
> 
> AMOUNT - the total cost of the transaction. What you ultimately paid in
> the currency of your particular account.
> 
> SHARES - how many units of the security were sold/bought.
> 
> The PRICE, the amount paid per SHARE for this one transaction, is
> calculated using the other two. It's more an informative value than
> anything else.
> 
> What I really care about when I get my statements from investment
> institutions, or trade notifications, is the number of SHARES involved
> and the total cost to me. It truly does not matter as far as maintaining
> a good set of books for my finances, what the exact to-the-20th-decimal
> PRICE was. I just want the SHARES and my current cash balance to be in
> agreement when compared to a financial institution's statement.

Well said, Ken!  I was working on a message that would make those
points, but I'm glad I read yours before I posted mine.

I'll just add one point, for the people who are asking for a change to
GC in this area: you're asking the impossible. It is _mathematically_
not possible to have three decimal numbers A B and C, each rounded to a
desired number of decimal places, fulfill the equation A * B = C
exactly. For some particular numbers A and B, to some suitable number of
decimal places, it will indeed work out, but the general case is
mathematically impossible.

GnuCash has no choice but to consider one of the three quantities to be
only approximate, and I agree with you that share price is the right one
for that role. Number of shares and total amount must be exact to the
generally accepted numbers of decimal places, or people's books won't
balance.

Stan Brown
Tehachapi, CA, USA
https://BrownMath.com
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] gnucash_user: rounding errors and significant digits

[john]

Bruce,

I don't know who this "Jim" is, their replies are not making it to the list. 
Unfortunately their understanding of GnuCash's handling of amount, value, and 
price is flawed.

Amount is the quantity of a split in the split account's commodity.
Value is that amount converted to the transaction currency, which in turn is 
determined by the account register in which the transaction is created. If that 
account is denominated in a non-currency commodity then it takes the currency 
of the nearest parent account that is denominated in a currency.
Price is the ratio between the two.

Commodities, both currency and otherwise, have minimum fractions. For example 
there is no such thing as a fraction of a car, a tenth of a Japanese Yen, or 
one thousandth of a US Dollar. Financial quantities are always rounded to that 
minimum fraction. GnuCash follows that practice.

GnuCash's number system uses rational numbers represented as the ratio of two 
64-bit integers; that allows a lot of precision but not infinite precision. 
Prices may be rounded to be representable. That's unlikely to have a material 
effect on any calculation, unlike the rounding of quantities, though for that 
to be true GnuCash has to limit the minimum fraction of a commodity to 10^-9, 
otherwise it's possible to have unrepresentable prices in highly inflated 
currencies.

So the claim value = price * shares is logically correct but depends on price * 
shares yielding a legal value in value's currency; the reverse is true as well: 
shares = value/price is true only if value/price produces an amount 
representable in the share commodity's minimum fraction.

The consequence of that rounding is that you should generally tell GnuCash the 
amount and value and let it calculate the price to ensure that GnuCash matches 
whatever rounding got applied at your financial institution.

Regards,
John Ralls


> On Sep 9, 2023, at 10:59, Bruce McCoy via gnucash-user 
>  wrote:
> 
> Jim,
> 
> Thank you for your response of Mon, Aug 21, 2023 at 5:00 PM via GnuCash-user. 
>   In it you said:
> 
> "Logically, $value = $price/share * #shares, and this should be 
> precise equality."
>   
> This is certainly true.   And accuracy is a top consideration in a financial 
> program.  
>
> GnuCash "...stores the price as a rational number, a ratio between 
> numerator and denominator (i.e., a fraction).  Thus it will 
> exactly satisfy the logical equation." 
>
> It is also certainly true that this way of storing a value as a rational 
> number is both excellent and exact.   Our desire is to exactly satisfy the 
> logical equation.  
> 
> "he actual $value of this $price and #shares is $14.99896, a 
> difference of $0.00104."
> 
> At the moment, using these figures, GnuCash is (14.99896/15.000) * 100 = 
> 99.9930666... % correct.  GnuCash is currently doing well.  The 
> incremental change needed is small.  This should encourage us.  This is our 
> major point for discussion.  Please allow me to discuss it in detail in a 
> later post.
>   
> For the moment, let's discuss a  minor point.
>   
> "GnuCash takes the position that price is approximate and transient, 
> but currency received and paid, and shares received and issued, 
> are exact and persistent. Thus a GnuCash securities transaction 
> stores the number of shares and the currency value of the 
> transaction, and derives the price as $value/#shares..."  
> 
> In this minor point, the viewpoint that the smallest units of currency are 
> considered exact both by governments and their financial companies will be 
> investigated.  One conclusion will be that GnuCash should consider "price" 
> and "currency received" as exact figures.  A second is that GnuCash should 
> consider "shares received and issued" as an approximation, although it is not 
> always true.  The details are discussed next.
> 
> It is true that GnuCash treats the number of shares received and issued as 
> exact and persistent quantities.  If someone were to ask us whether the way 
> GnuCash treats the currency pricing is either "approximate and transient" in 
> the case of $6.26 per share or "exact and persistent"  in the case of the 
> $15.00 annual account fee, what could our answer be?   Buying one share will 
> cost 626 pennies.  The annual fee is 1,500 pennies.  Other than the quantity 
> of them, what is the essential difference in the pennies used to purchase a 
> share and the pennies used to pay the fee?  
>  
> If we can show a difference in the pennies of one groups compared with the 
> pennies in the second group, then we could maintain that one group could 
> consist of pennies that are "approximate and transient" and the other group 
> of pennies are "exact and persistent."  What distinction could we make?  We 
> could say "GnuCash takes the position that price is approximate and 
> transient, but currency received and paid, and 

Re: [GNC] gnucash_user: rounding errors and significant digits

[Ken Farley]

I really don't see what is so difficult to understand about this.

The key equation is AMOUNT = PRICE * SHARES

Gnucash works under the philosophy that two of those terms must be 
maintained precisely:


AMOUNT - the total cost of the transaction. What you ultimately paid in 
the currency of your particular account.


SHARES - how many units of the security were sold/bought.

The PRICE, the amount paid per SHARE for this one transaction, is 
calculated using the other two. It's more an informative value than 
anything else.


What I really care about when I get my statements from investment 
institutions, or trade notifications, is the number of SHARES involved 
and the total cost to me. It truly does not matter as far as maintaining 
a good set of books for my finances, what the exact to-the-20th-decimal 
PRICE was. I just want the SHARES and my current cash balance to be in 
agreement when compared to a financial institution's statement.

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] gnucash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Jim,
    
Thank you for your response of Mon, Aug 21, 2023 at 5:00 PM via GnuCash-user.   
In it you said:

    "Logically, $value = $price/share * #shares, and this should be precise 
equality."
  
This is certainly true.   And accuracy is a top consideration in a financial 
program.  
   
    GnuCash "...stores the price as a rational number, a ratio between 
numerator and denominator (i.e., a fraction).      Thus it will exactly 
satisfy the logical equation." 
   
It is also certainly true that this way of storing a value as a rational number 
is both excellent and exact.   Our desire is to exactly satisfy the logical 
equation.  

    "he actual $value of this $price and #shares is $14.99896, a difference 
of $0.00104."

At the moment, using these figures, GnuCash is (14.99896/15.000) * 100 = 
99.9930666... % correct.  GnuCash is currently doing well.  The 
incremental change needed is small.  This should encourage us.  This is our 
major point for discussion.  Please allow me to discuss it in detail in a later 
post.
  
For the moment, let's discuss a  minor point.
  
    "GnuCash takes the position that price is approximate and transient, 
but currency received and paid, and     shares received and issued, are 
exact and persistent. Thus a GnuCash securities transaction stores the 
number     of shares and the currency value of the transaction, and 
derives the price as $value/#shares..."  

In this minor point, the viewpoint that the smallest units of currency are 
considered exact both by governments and their financial companies will be 
investigated.  One conclusion will be that GnuCash should consider "price" and 
"currency received" as exact figures.  A second is that GnuCash should consider 
"shares received and issued" as an approximation, although it is not always 
true.  The details are discussed next.

It is true that GnuCash treats the number of shares received and issued as 
exact and persistent quantities.  If someone were to ask us whether the way 
GnuCash treats the currency pricing is either "approximate and transient" in 
the case of $6.26 per share or "exact and persistent"  in the case of the 
$15.00 annual account fee, what could our answer be?   Buying one share will 
cost 626 pennies.  The annual fee is 1,500 pennies.  Other than the quantity of 
them, what is the essential difference in the pennies used to purchase a share 
and the pennies used to pay the fee?  
 
If we can show a difference in the pennies of one groups compared with the 
pennies in the second group, then we could maintain that one group could 
consist of pennies that are "approximate and transient" and the other group of 
pennies are "exact and persistent."  What distinction could we make?  We could 
say "GnuCash takes the position that price is approximate and transient, but 
currency received and paid, and shares received and issued, are exact and 
persistent."  Essentially that is how we have always considered the matter. 
  
Is "We have always done it this way." a compelling response?  If we look at our 
general situations as human beings over the course of the centuries, are we 
living our lives with, for example, many different technologies than our 
ancestors used?  If we looked at the specific cast of GnuCash itself, do we see 
features being added and defects being removed?  From both the general and the 
specific examples, is  "We have always done it this way." a compelling 
response? If so, we might continue as we have up to now.  If not, we might 
consider a change.
  
If we are going to continue as GnuCash has up to now, we have to show the 
essential difference in the pennies used to purchase a share and the pennies 
used to pay the fee.  As I fail to see an essential difference between the 
pennies in one group compared with the pennies in the other group, if someone 
were to ask me to explain why GnuCash holds the position it does in this 
matter, I would not know how to respond.  
  
In double-entry financial transactions involving the smallest units of the same 
currency at the same time, when are the units of one side of the transaction 
given different values than the units on the other side of the transaction?  I 
fail to remember any.
  
If we can not demonstrate an essential difference between the two groups of 
pennies,  how can it be clear that they are different?  If they are not 
different, they have to be the same.  Both values have to be either 
"approximate" or "exact."  If they are approximate, how do we distinguish that 
from their exact value?  If they are exact, then when we divide the fee of 
1,500 pennies by 626 pennies per share we may get an approximation of the 
number of shares purchased.
  
In this latest case, the currency values are considered to be exact and the 
transaction concerning the number of shares involved, although it, on occasion, 
may be exact, may frequently be an approximation.  

In 

Re: [GNC] gnucash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Jim,

 

Whata pleasure to read your response. What a pause before my response. 

 

Youare kind enough to say: 

 Iam interested by your statement, "results in gnucash reducingthe shares 
in the fund by 2.4". GnuCash is capable of storingshare counts to three 
decimal places. However, a setting in theAccount window for the security 
controls the number of decimalplaces GnuCash uses for that security. See 
the Tutorial and Concepts Guide, 9.4.1. Setup Accounts for Stocks and 
MutualFunds.See also Figure 9.8. The 
“New Security” Window, on that page.

 Foryour security, what is the value for "fraction traded" inthe security 
window? It should be 1/1000 or smaller. What is thevalue for "Smallest 
Fraction" in that dialogue box? Itshould be "Commodity Value". 

 

Youare exactly right. I corrected my mistake. Thank you for helpingme.

 

BestRegards,

 

Bruce





|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] gnucash_user: rounding errors and significant digits

[Jim DeLaHunt]

Bruce:

Welcome to the gnucash-user email list! Hopefully we can give you some 
useful answers. I will answer based on what I have heard developers say 
on the list, and what I see in my stock transactions in GnuCash, though 
I have not read the relevant GnuCash source code.


On 2023-08-21 10:21, Bruce McCoy via gnucash-user wrote:
...Could you please help me comprehend what ishappening in the 
calculations of gnucash compared with thecalculations of Federated 
Hermes? FederatedHermes determines the number of shares traded by the 
currency amountof the trade divided by the price of the shares. For 
example, onceupon a time they charged me a $15.00 Annual Fiduciary 
Administrationfee. The share price was $6.26. To meet the fee they 
sold 2.396shares and recorded it on their statement as -2.396 shares, 
accurateto 1/1,000 of a share, for the transaction.


It sounds like they charged you 2.396 shares to fulfil an obligation for 
$15.00. They used the price of $6.26 to arrive at the amount of 2.396 
shares, but it is not a fundamental part of the transaction. This is 
important to how GnuCash records such transactions.


Logically, $value = $price/share * #shares, and this should be precise 
equality. But is possible for a brokerage statement to report values 
which do not have precise equality. It sounds like Federated Hermes 
reported $15.00 = $6.26 * 2.396, but the actual $value of this $price 
and #shares is $14.99896, a difference of $0.00104.


GnuCash takes the position that price is approximate and transient, but 
currency received and paid, and shares received and issued, are exact 
and persistent. Thus a GnuCash securities transaction stores the number 
of shares and the currency value of the transaction, and derives the 
price as $value/#shares. It stores the price as a rational number, a 
ratio between numerator and denominator (i.e., a fraction). Thus it will 
exactly satisfy the logical equation.


In your example, I expect GnuCash stored the price as , simplified to 
3750/599 $/share.


As we see below thenumber of shares they reported was truncated from 
the more accuratefigure given below. AnnualFiduciary Administrative 
Fee of $15.00/Share price of $6.26 =2.3961661341853035143769968 
05111821086261980830670926517571884984025559105431309904153354632587859425shares 
traded. Ingnucash, entering the fee of $15 and the number of shares as 
2.396,results in gnucash reducing the shares in the fund by 2.4, 
changingthe fund and expense accounts by $15.02, and setting the trade 
priceat $6.2583. Gnucashunderestimates the trade price by 
(1-(6.2583/6.26))*100 = 0.02715 %. Gnucashcould use a longer fraction 
to generate a more accurate share price. This only requires that the 
fraction have more significant digits. If gnucash multiplied the 
$15.00 fee by2.3961661341853035143769968051118 
21086261980830670926517571884984025559105431309904153354632587859425shares, 
won't the result be a share price of $6.26.


Please rethink this paragraph, treating the currency amount and number 
of shares in the transaction as fundamental, and the price as a 
byproduct. It would be something like, Annual Fiduciary Administrative 
Fee of $15.00, #shares = 2.396, price = 15000/2396 = 3750/599 $/share. 
In decimal terms, this is about $6.26043405676127/share. You might 
describe it as, "the transaction price they reported was rounded from 
the more accurate 3750/599".


I am interested by your statement, "results in gnucash reducing the 
shares in the fund by 2.4". GnuCash is capable of storing share counts 
to three decimal places. However, a setting in the Account window for 
the security controls the number of decimal places GnuCash uses for that 
security. See the Tutorial and Concepts Guide, 9.4.1. *Setup Accounts 
for Stocks and Mutual 
Funds*. 
See also Figure 9.8. *The “New Security” Window*, on that page.


For your security, what is the value for "fraction traded" in the 
security window? It should be 1/1000 or smaller. What is the value for 
"Smallest Fraction" in that dialogue box? It should be "Commodity Value".


Mutualfunds seem to treat both the amount of the local currency 
tenderedand the price per share as decimal numbers of high precision 
e.g.$15.000 or $6.2600. They seem 
toconsider the number of shares traded as an approximation. Of 
coursethey add and subtract fractional numbers of shares. Where do we 
seethem dividing the transaction cost by the number of shares, 
includingfractional shares, to calculate the the price per share? 
Inevery mutual fund statement I have seen, the prices and the 
numbersof shares always agree from month to month


You just gave an example of a transaction where the price and number of 
shares does not agree with the currency value of the transaction: $6.26 
* 2.396 = $14.99896, not the stated value $15.00.


I would 

[GNC] gnucash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Bruce, please include the user list in your replies.  Then others are kept in 
the loop.  I am copying your reply here this time.
Also, I am at my computer with a real keyboard so I will hopefully avoid fat 
finger mistakes.  Your rhetorical questions do not have good answers.  
Historically, there has not been consistency between financial institutions' 
methods of calculation, and GnuCash would go crazy trying to match all of them. 
 Further, some GnuCash features such as the one called Trading Accounts have 
additional accuracy issues which are more concerning to some users than to 
others.  See 
https://lists.gnucash.org/pipermail/gnucash-user/2022-July/102072.html for 
example.

I, for one, have found a way to get the results that I want from GnuCash.David 
Carlson
~~~
David,  
Thank you for copying my reply to gnucash-user@gnucash.org. I'll try to do that 
in the future.  
  
Thank you for confirming my suspicion that financial institutions vary in their 
calculations.  Could it be that most of them report the fractions of shares 
traded to 3 or 4 decimal places and that there are only about 3-4 major 
rounding schemes?  If so, a programmer could design options to for the number 
of decimal places and the type of rounding used and also another option to let 
the user enter the values himself.  This would be relatively simple and should 
allow a lot of flexibility to gnucash.  
Concerning Trading Accounts, thank you for your reference to your 26 Jul 2022 
message and the other comments -- including those of Peter Selinger.  
Cordially,Bruce




|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] gnucash_user: rounding errors and significant digits

[David Carlson]

The developers can give you a more detailed answer, but in fact GnuCash
carries much more prrcision inyernally.  To get the best results, enter
number of shares and total currency then let GnuCash calculate the price.
That usually allows GnuCash reports
To mstch your brokers reports.



On Mon, Aug 21, 2023, 12:22 PM Bruce McCoy via gnucash-user <
gnucash-user@gnucash.org> wrote:

> Greetings to all of you,
>
>
> Ingnucash, you have developed a wonderful program. Thank you.
>
>
> Greatis my anticipation for using it, although there is at least one areaI
> do not understand. Could you please help me comprehend what ishappening in
> the calculations of gnucash compared with thecalculations of Federated
> Hermes?
> FederatedHermes determines the number of shares traded by the currency
> amountof the trade divided by the price of the shares. For example,
> onceupon a time they charged me a $15.00 Annual Fiduciary
> Administrationfee. The share price was $6.26. To meet the fee they sold
> 2.396shares and recorded it on their statement as -2.396 shares, accurateto
> 1/1,000 of a share, for the transaction. As we see below thenumber of
> shares they reported was truncated from the more accuratefigure given
> below.
>
> AnnualFiduciary Administrative Fee of $15.00/Share price of $6.26
> =2.3961661341853035143769968
>  
> 05111821086261980830670926517571884984025559105431309904153354632587859425shares
> traded.
> Ingnucash, entering the fee of $15 and the number of shares as
> 2.396,results in gnucash reducing the shares in the fund by 2.4,
> changingthe fund and expense accounts by $15.02, and setting the trade
> priceat $6.2583.
> Gnucashunderestimates the trade price by (1-(6.2583/6.26))*100 = 0.02715
> %.
> Gnucashcould use a longer fraction to generate a more accurate share
> price. This only requires that the fraction have more significant digits.
> If gnucash multiplied the $15.00 fee by2.3961661341853035143769968051118
> 21086261980830670926517571884984025559105431309904153354632587859425shares,
> won't the result be a share price of $6.26.
>
> Mutualfunds seem to treat both the amount of the local currency
> tenderedand the price per share as decimal numbers of high precision
> e.g.$15.000 or $6.2600. They seem
> toconsider the number of shares traded as an approximation. Of coursethey
> add and subtract fractional numbers of shares. Where do we seethem dividing
> the transaction cost by the number of shares, includingfractional shares,
> to calculate the the price per share?
> Inevery mutual fund statement I have seen, the prices and the numbersof
> shares always agree from month to month. Aren't mutual funds astandard in
> calculation of financial values? Why do we not do thesame by incorporating
> more significant digits in the calculations?
> InEdit > Preferences > Numbers, Date, Time > Numbers >Force Prices to
> display as decimals, the maximum number of decimalplaces one can display is
> only 8 (eight). If this is close to thenumber of significant digits gnucash
> is currently using, could it bethat we might consider using, instead of,
> say, double binaryfloating-point method, a decimal floating-point
> arithmetic, e.x.http://speleotrove.com/decimal, as is done in financial
> andcommercial applications (like engineering) requiring exact,
> precisemeasurements, especially in applications having multiple
> trailingzeros achieved by scaling?
>
>
>
> Aswe know both the IEEE have standards (ex. IEEE 754) recommending
> andEuropean regulatory agencies have laws mandating working precision
> indecimal digits for calculations. Packages like the Java BigDecimalclass
> and the C decNumber package have been developed to providecompliance.
>
>
> Whydo we not avoid rounding errors? Why do we not enjoy the accuracyand
> precision that everyone else can? Well, we can increase theprecision of our
> calculations by increasing the number of significantdigits in the decimal
> representations of our numerical data.
>
> Bruce
>
>
>
>
>
> |  | Virus-free.www.avast.com |
>
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[GNC] gnucash_user: rounding errors and significant digits

[Bruce McCoy via gnucash-user]

Greetings to all of you,   

 
Ingnucash, you have developed a wonderful program. Thank you. 
  

Greatis my anticipation for using it, although there is at least one areaI do 
not understand. Could you please help me comprehend what ishappening in the 
calculations of gnucash compared with thecalculations of Federated Hermes?
FederatedHermes determines the number of shares traded by the currency amountof 
the trade divided by the price of the shares. For example, onceupon a time they 
charged me a $15.00 Annual Fiduciary Administrationfee. The share price was 
$6.26. To meet the fee they sold 2.396shares and recorded it on their statement 
as -2.396 shares, accurateto 1/1,000 of a share, for the transaction. As we see 
below thenumber of shares they reported was truncated from the more 
accuratefigure given below. 
   
AnnualFiduciary Administrative Fee of $15.00/Share price of $6.26 
=2.3961661341853035143769968   
 
05111821086261980830670926517571884984025559105431309904153354632587859425shares
 traded.   
Ingnucash, entering the fee of $15 and the number of shares as 2.396,results in 
gnucash reducing the shares in the fund by 2.4, changingthe fund and expense 
accounts by $15.02, and setting the trade priceat $6.2583.   
Gnucashunderestimates the trade price by (1-(6.2583/6.26))*100 = 0.02715 %.   
Gnucashcould use a longer fraction to generate a more accurate share price. 
This only requires that the fraction have more significant digits. If gnucash 
multiplied the $15.00 fee by2.3961661341853035143769968051118   
21086261980830670926517571884984025559105431309904153354632587859425shares, 
won't the result be a share price of $6.26. 
   
Mutualfunds seem to treat both the amount of the local currency tenderedand the 
price per share as decimal numbers of high precision 
e.g.$15.000 or $6.2600. They seem 
toconsider the number of shares traded as an approximation. Of coursethey add 
and subtract fractional numbers of shares. Where do we seethem dividing the 
transaction cost by the number of shares, includingfractional shares, to 
calculate the the price per share?   
Inevery mutual fund statement I have seen, the prices and the numbersof shares 
always agree from month to month. Aren't mutual funds astandard in calculation 
of financial values? Why do we not do thesame by incorporating more significant 
digits in the calculations?   
InEdit > Preferences > Numbers, Date, Time > Numbers >Force Prices to display 
as decimals, the maximum number of decimalplaces one can display is only 8 
(eight). If this is close to thenumber of significant digits gnucash is 
currently using, could it bethat we might consider using, instead of, say, 
double binaryfloating-point method, a decimal floating-point arithmetic, 
e.x.http://speleotrove.com/decimal, as is done in financial andcommercial 
applications (like engineering) requiring exact, precisemeasurements, 
especially in applications having multiple trailingzeros achieved by scaling? 
   

 
Aswe know both the IEEE have standards (ex. IEEE 754) recommending andEuropean 
regulatory agencies have laws mandating working precision indecimal digits for 
calculations. Packages like the Java BigDecimalclass and the C decNumber 
package have been developed to providecompliance.   

 
Whydo we not avoid rounding errors? Why do we not enjoy the accuracyand 
precision that everyone else can? Well, we can increase theprecision of our 
calculations by increasing the number of significantdigits in the decimal 
representations of our numerical data.   

Bruce





|  | Virus-free.www.avast.com |

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.