Re: [GNC] GnuCash getting worse?

[Bruce McCoy via gnucash-user]

On Thu, Dec 28, 2023 at 10:41 AM Michael D Novack wrote: 
>“Do you immediately upgrade to the newest version or do
>you wait long enough for the new version bugs to be found and corrected?”
>“if you dislike being an involuntary beta tester...then wait a little while 
>before upgrading.”
 
Michael’s post is excellent.And I agree with it. 
If you did upgrade, thank you for, in effect, being a beta tester. Your reports 
of bugs (and we all are dismayed that they are there.) prove that you are an 
asset to this project. 
I feel that GnuCash is an excellent program. And it is getting even better. 
Thank you.
 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.

[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 

Re: [GNC] DOS Payroll, Inventory, A/R, A/P, and G/L program

[Bruce McCoy via gnucash-user]

Michael,
(I was too hasty. Let me try it with a link. 
https://www.dropbox.com/scl/fi/aahbzubzzyc3y14hz2owu/_BKS_SRC.zip?rlkey=58pc9vuady2fn86tzbph1qmw7=0
 I apologize.)
On Tue, Oct 31 at 6:40 AM Michael Hendry wrote:    >I have some accounts in TAS 
Books

Thank you so much for looking. I did find some old files.  
 
Here is the source code. Someone will have an example after all.

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] DOS Payroll, Inventory, A/R, A/P, and G/L program

[Bruce McCoy via gnucash-user]

Michael,

On Nov 1 at 1:06 PM Michael Hendry wrote:     >sorry...

That’s OK. You are helping.  Thank you for finding out the information. 
  
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] DOS Payroll, Inventory, A/R, A/P, and G/L program

[Bruce McCoy via gnucash-user]

Hi Everyone,

On October 30, 2023 at 04:59:52 PM EDT, Michael Novack wrote: 
    >Confusion? What would DOS ...have to do with SOURCE 
    >CODE files? It's the compiler's job and the link editor's job 
    >to turn that source code into an executable

Yes, you are right. I apologize for the confusion. For the files in question, 
please see the links below. In the BOOKS system, TAS, not explained by me, is 
the database program that modifies the BOOKS application. Maybe we could 
consider TAS to be a database/language runtime compiler written for DOS 2.0.


On October 30, 2023 at 06:03:44 PM EDT, David Cousens wrote: 
    >Thanks Bruce

You are welcome. 

    >the source code is likely to be of little direct value...
Yes, other than provide one concrete, working example.

    >A payroll system would have to account for the current range 
    >of payroll practices across many different jurisdictions...
    >GnuCash AFAIK does not have a functional API in C or C++ code... 
    >an inventory system has to accommodate the cost management and 
    >the model for inventory handling (FIFO, LIFO... 

Exactly right.

    >I have not explored the Python interface enough to 
    >know if it would be sufficient...

Thank you for thinking of that.

    >Large parts of both of these systems are 
    >largely independent...

True.

    >If this were to be attempted one approach 
    >would be standalone modules... 

Good idea.

    >If the necessary interfacing code does 
    >not exist it would have to be created...
    >to make these projects viable.

Right. What will we decide to do?


On Tue, Oct 31 at 6:40 AM Michael Hendry wrote: 
    >I have some accounts in TAS Books which 
    >I created and maintained on Windows XP 

Me too. I’ve used version 1e. What about you?

    >I’ve had to maintain a copy of Windows XP Pro

Had I done that, your life would be simpler.

    >legacy files inherited from my late father

I’m sorry for his demise. I am sure you miss him. I do miss both my parents. I 
hope your dad was as nice as mine. 

    >I haven’t been able to find TAS.ZIP 
    >in your Dropbox folders. 

Michael, that's because I did not send you the links. Here they are:

BKS.EDT.zip
https://www.dropbox.com/scl/fi/uijxiym22r707k4cgfais/TAS.zip.txt?rlkey=qs6z1j7zrz5de2y8pjbyghppi=0

BKS.EDT.zip.txt
https://www.dropbox.com/scl/fi/qpihxsi392bk47wi86hsb/TAS.zip?rlkey=n60xy601m9r2yvxshi20h9l2m=0

TAS.zip
https://www.dropbox.com/scl/fi/kg3yw34naznmk9myvbhuk/BKS.EDT.zip.txt?rlkey=2q9zbkg9ko8g16euzgm6you6y=0

TAS.zip.txt
https://www.dropbox.com/scl/fi/e8ohz1g2qnfa55qq4e0i7/BKS.EDT.zip?rlkey=68tlmfi88day9ph7bshncfnes=0

Anyone with this link: can edit
 
https://www.dropbox.com/scl/fo/gdrodliyh9up81mv1r0yx/h?rlkey=512xq60pa5dn9bplnmitjtuej=0

TAS.zip is the program generator that will display the source code. Run TAS.exe 
in DOS. Let it operate on each of the .EDT files. It will output the source 
code in a text file in a more easily readable format than the .EDT files.


On October 31, 2023 at 02:29:24 PM EDT, Adrien Monteleone wrote: 
    >I'm of a similar opinion.

Me too.

    >UI Mockups might illustrate requirements or scope...
    >but the code to accomplish that is a different beast... 
    >I'd posit that if anyone wanted to work on such a module, 
    >that they would and probably should, do so from scratch 
    >with modern tools, languages, and UI/UX paradigms 
    >from other *current* software

Exactly.

    >The lack of a payroll module isn't because 
    >no one knows what it should look like or 
    >how it might work.

Encouraging. Thank you for telling me that.What would you say is needed, to 
develop a payroll module for GnuCash?
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] DOS Payroll, Inventory, A/R, A/P, and G/L program

[Bruce McCoy via gnucash-user]

David,
  Here are the source code text files, *.EDT, for the program. They are in 
BKS.EDT.zip. These files are corrected. To make them easier to read, like 
TAXCODE.txt (q.v.), run them with TAS, which is in TAS.zip. 

BKS.EDT.zip, BKS.EDT.zip.txt,  TAS.zip  and TAS.zip.txt are in General at
https://www.dropbox.com/scl/fo/d323887f48f9gote69ohm/h?rlkey=gudyrc3o8r8wf0icti0k705gn=0
All we need to do that is find someone with DOS. I do not have a DOS machine 
any more. I'll ask my contacts to see whether they still have that capability. 
  
You may find people who use DOS. If so, you will be able to make the source 
code files read like TAXCODE.txt yourself.
 
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] DOS Payroll, Inventory, A/R, A/P, and G/L program

[Bruce McCoy via gnucash-user]

David,
  
You are correct. The zip file only contains some schema for the database and 
some pictures of certain User Interface screens. It gives an idea of what is 
useful for a payroll module. 
  
This is a single-user, DOS program, written in an old language, not C++. 
Although I have the code, it needs to be rewritten in a currently supported 
language. It can not, as is, communicate with the GnuCash data structure. 
   
Our GnuCash C++ developers, as far as I know, are overworked. These files are 
not GnuCash plug-ins. They are offered for references. They are meant to be 
saved until, at some future time, the GnuCash developers are in a position to 
consider writing a payroll module or, in the case of 
GL_AR_AP_Inventory_BOOKS.zip, some other GnuCash module.  
  
Payroll_BOOKS.zip is just for reference in GnuCash payroll module design. 
GL_AR_AP_Inventory_BOOKS.zip is for non-payroll modules that GnuCash developers 
may wish to develop at some future time. Both are provided for reference in the 
design phase of development. 

I did not send everything as I did not know whether there would be any interest 
in this material. If, at some time, interest develops, then, if needed, it is 
possible I could send more material.  There was a bug in the End-of-Year 
section of the code. If needed, I’d be glad to try to provide more material 
concerning that bug.
Whoever might develop this for GnuCash can use Payroll_BOOKS.zip as an example 
in development. They could integrate this information into their design for a 
GnuCash payroll module. The coding should be pretty straightforward. 
  
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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

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