Re: [GNC] Update F::Q in flatpak GC?

[rsbrux via gnucash-user]

Still one problem (perhaps better handled on the F::Q mailing list):
My main reason for wanting to update F::Q is that I saw that SIX.pm had 
been updated.


However, in GC (flatpak) 5.3+ with the updates to the PM scripts 
mentioned below, the Securities Editor still shows the obsolete SIXfunds 
and SIXshares as sources and no SIX. Furthermore. both SIXfunds and 
SIXshares are greyed out.


According to GitHub 
(https://github.com/finance-quote/finance-quote/commit/19962d29985549bfefef89891670dafb93e87f27) 
SIXfunds.pm and SIXshares.pm were merged into SIX.pm as of 19 Nov., 2020.


What do I need to do to get rid of the obsolete entries and get access 
to SIX as a source of securities pricing?


On 18.08.23 18:16, rsbrux wrote:

Spot on! Deleted the two lines, now working as expected.
Many thanks!

-Original Message-
From: John Ralls 
Sent: Thursday, August 17, 2023 11:23 PM
To: rsbrux 
Subject: Re: [GNC] Update F::Q in flatpak GC?

I meant go back to the 1.56 version of IndiaMutual.pm, leaving everything
else in place.

You don't need to delete it, just remove the two lines in Quote.pm that
refer to it.

Regards,
John Ralls




On Aug 17, 2023, at 12:21 PM, rsbrux  wrote:

I don’t need IndiaMutual.pm, but I don’t want to go back to 1.56 because I
would like to try out the updated version of six.pm.  Can I just delete
IndaiMutual.pm?

Sent from my iPad


On 17 Aug 2023, at 19:30, john  wrote:

IndiaMutual.pm has a new perl dependency IO::String
(https://metacpan.org/pod/IO::String) as of F::Q 1.57. That dependency is
in the nightlies but not the release flatpak. It's pure perl and has no
dependencies so you have a couple of ways forward:

* Get the source code (there are links in the sidebar on the left on
the IO::String page) and install it in the flatpak's perl directory
as IO/String.pm
* Install a recent nightly build and apply the F::Q update to that
* If you don't need the IndiaMutual module you can restore the 1.56
version that doesn't need IO::String.

Regards,
John Ralls



On Aug 17, 2023, at 01:59, rsbrux  wrote:

Thanks for the further tips.  I was unable to find gnucash.trace in
either /tmp or /var/tmp (or their subdirectories.  Before trying to pipe
the logs to the console as described in
https://wiki.gnucash.org/wiki/Flatpak#Getting_Console_Output, I tried
running the quote retrieval from the command line, as you suggested.
This resulted in the following error message:

Price retrieval failed: Finance::Quote check returned error Can't
locate IO/String.pm in @INC (you may need to install the IO::String
module) (@INC contains: /app/lib/perl5/site_perl/5.32.0/x86_64-linux
/ap
p/lib/perl5/site_perl/5.32.0 /app/lib/perl5/5.32.0/x86_64-linux
/app/lib/perl5/5.32.0) at /app/lib/perl
5/site_perl/5.32.0/Finance/Quote/IndiaMutual.pm line 33.
BEGIN failed--compilation aborted at
/app/lib/perl5/site_perl/5.32.0/Finance/Quote/IndiaMutual.pm line 33.
Compilation failed in require at
/app/lib/perl5/site_perl/5.32.0/Module/Load.pm line 78.
Can't locate Finance/Quote/IndiaMutual in @INC (@INC contains:
/app/lib/perl5/site_perl/5.32.0/x86_64-l
inux /app/lib/perl5/site_perl/5.32.0
/app/lib/perl5/5.32.0/x86_64-linux /app/lib/perl5/5.32.0) at /app/
lib/perl5/site_perl/5.32.0/Module/Load.pm line 78.
at /app/bin/finance-quote-wrapper line 113.
Attempt to reload Finance/Quote/IndiaMutual.pm aborted.
Compilation failed in require at
/app/lib/perl5/site_perl/5.32.0/Module/Load.pm line 78.
Can't locate Finance/Quote/IndiaMutual in @INC (@INC contains:
/app/lib/perl5/site_perl/5.32.0/x86_64-l
inux /app/lib/perl5/site_perl/5.32.0
/app/lib/perl5/5.32.0/x86_64-linux /app/lib/perl5/5.32.0) at /app/
lib/perl5/site_perl/5.32.0/Module/Load.pm line 78.
at /app/bin/finance-quote-wrapper line 114.

<<

This suggests to me that the changes in the pm scripts depend on changes
in the actual program code.

Can I just copy the entire tarball extract into
/var/lib/flatpak/app/org.gnucash.GnuCash/current/active/, or do I need
to limit what I copy or keep any residual files in that directory tree?

Thanks for your support!

On 15.08.23 19:19, john wrote:

Look in the tracefile (https://wiki.gnucash.org/wiki/Tracefile) or run
`gnucash-cli -Q info` (see
https://wiki.gnucash.org/wiki/Flatpak#Using_Command_Line_Tools for how
to run that from a flatpak) to see what the errors are.

Regards,
John Ralls



On Aug 15, 2023, at 08:26, rsbrux  wrote:

Now that I copied over the Quote directory and the Quote.pm script in
/var/lib/flatpak/app/org.gnucash.GnuCash/current/active/files/lib/perl5/site_perl/5.32.0/Finance/
with the files from the 1.58 release package, the "Get Quotes" button
in the Price Database tool is disabled. I already gave universal
execute privileges to  all of the newly copied files (and directory).
What else might be the cause?

On 15.08.23 14:51, rsbrux wrote:

Sorry, dumb question.  I found the tarball here:
https://sourceforge.net/projects/finance-quote/

On 15.08.23 14:48, rsbrux wrote:

Thanks for the tip, but I'm

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

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.

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

[David Carlson]

On Mon, Aug 21, 2023 at 1:03 PM Bruce McCoy  wrote:

> David.
>
> Thanks for your response.  You are right. gnucash usually matches the
> brokers' reports and it does calculate the price given the number of shares
> and the total currency, and internally gnucash has more precision in its
> calculations than two decimal places.
>
> Does it always match the brokers' reports?  Are the price, total currency
> and number of shares always in agreement?  Does gnucash have enough
> internal precision to always be accurate?
>
> Your kind answer shows that we both agree about the current capabilities
> of gnucash.  I also like gnucash -- as do the tens of thousands, as I
> understand it, of users.  You and I also know that there is room in gnucash
> for improvement.  Thank you for your evaluation.
>
> Best regards,
> Bruce
>
>
>
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.





>
>
>
> On Monday, August 21, 2023 at 01:35:06 PM EDT, David Carlson <
> david.carlson@gmail.com> wrote:
>
>
> 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.
>
>
>
> |  | 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.
>
>
>
> 
> Virus-free.www.avast.com
> 
> <#m_-2574180124110445366_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>


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

[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] Update F::Q in flatpak GC?

[john]

The list of sources in the Security Edit dialog is hard coded and not often 
updated. Entries are grayed out if the item isn't found in the list of sources 
retrieved from F::Q at start up, which at preset is a lot of them. Sources that 
are in the F::Q list but don't have a hardcoded entry get added to the Unknown 
list at the bottom. I found `six` in that list.

https://github.com/Gnucash/gnucash/pull/1626
WIP: Incorporate new Finance::Quote get_features() to automatically configure 
quote sources by vincentl · Pull Request #1626 · Gnucash/gnucash
github.com
 seeks to replace the hard-coded lists, but there are still a few details to 
work out and the contributor doesn't seem to have a lot of time to work on it.

Regards,
John Ralls

> On Aug 21, 2023, at 05:12, rsbrux via gnucash-user  
> wrote:
> 
> Still one problem (perhaps better handled on the F::Q mailing list):
> My main reason for wanting to update F::Q is that I saw that SIX.pm had been 
> updated.
> 
> However, in GC (flatpak) 5.3+ with the updates to the PM scripts mentioned 
> below, the Securities Editor still shows the obsolete SIXfunds and SIXshares 
> as sources and no SIX. Furthermore. both SIXfunds and SIXshares are greyed 
> out.
> 
> According to GitHub 
> (https://github.com/finance-quote/finance-quote/commit/19962d29985549bfefef89891670dafb93e87f27)
>  SIXfunds.pm and SIXshares.pm were merged into SIX.pm as of 19 Nov., 2020.
> 
> What do I need to do to get rid of the obsolete entries and get access to SIX 
> as a source of securities pricing?
> 
> On 18.08.23 18:16, rsbrux wrote:
>> Spot on! Deleted the two lines, now working as expected.
>> Many thanks!
>> 
>> -Original Message-
>> From: John Ralls 
>> Sent: Thursday, August 17, 2023 11:23 PM
>> To: rsbrux 
>> Subject: Re: [GNC] Update F::Q in flatpak GC?
>> 
>> I meant go back to the 1.56 version of IndiaMutual.pm, leaving everything
>> else in place.
>> 
>> You don't need to delete it, just remove the two lines in Quote.pm that
>> refer to it.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>> 
>>> On Aug 17, 2023, at 12:21 PM, rsbrux  wrote:
>>> 
>>> I don’t need IndiaMutual.pm, but I don’t want to go back to 1.56 because I
>>> would like to try out the updated version of six.pm.  Can I just delete
>>> IndaiMutual.pm?
>>> 
>>> Sent from my iPad
>>> 
 On 17 Aug 2023, at 19:30, john  wrote:
 
 IndiaMutual.pm has a new perl dependency IO::String
 (https://metacpan.org/pod/IO::String) as of F::Q 1.57. That dependency is
 in the nightlies but not the release flatpak. It's pure perl and has no
 dependencies so you have a couple of ways forward:
 
 * Get the source code (there are links in the sidebar on the left on
 the IO::String page) and install it in the flatpak's perl directory
 as IO/String.pm
 * Install a recent nightly build and apply the F::Q update to that
 * If you don't need the IndiaMutual module you can restore the 1.56
 version that doesn't need IO::String.
 
 Regards,
 John Ralls
 
 
> On Aug 17, 2023, at 01:59, rsbrux  wrote:
> 
> Thanks for the further tips.  I was unable to find gnucash.trace in
> either /tmp or /var/tmp (or their subdirectories.  Before trying to pipe
> the logs to the console as described in
> https://wiki.gnucash.org/wiki/Flatpak#Getting_Console_Output, I tried
> running the quote retrieval from the command line, as you suggested.
> This resulted in the following error message:
> 
> Price retrieval failed: Finance::Quote check returned error Can't
> locate IO/String.pm in @INC (you may need to install the IO::String
> module) (@INC contains: /app/lib/perl5/site_perl/5.32.0/x86_64-linux
> /ap
> p/lib/perl5/site_perl/5.32.0 /app/lib/perl5/5.32.0/x86_64-linux
> /app/lib/perl5/5.32.0) at /app/lib/perl
> 5/site_perl/5.32.0/Finance/Quote/IndiaMutual.pm line 33.
> BEGIN failed--compilation aborted at
> /app/lib/perl5/site_perl/5.32.0/Finance/Quote/IndiaMutual.pm line 33.
> Compilation failed in require at
> /app/lib/perl5/site_perl/5.32.0/Module/Load.pm line 78.
> Can't locate Finance/Quote/IndiaMutual in @INC (@INC contains:
> /app/lib/perl5/site_perl/5.32.0/x86_64-l
> inux /app/lib/perl5/site_perl/5.32.0
> /app/lib/perl5/5.32.0/x86_64-linux /app/lib/perl5/5.32.0) at /app/
> lib/perl5/site_perl/5.32.0/Module/Load.pm line 78.
> at /app/bin/finance-quote-wrapper line 113.
> Attempt to reload Finance/Quote/IndiaMutual.pm aborted.
> Compilation failed in require at
> /app/lib/perl5/site_perl/5.32.0/Module/Load.pm line 78.
> Can't locate Finance/Quote/IndiaMutual in @INC (@INC contains:
> /app/lib/perl5/site_perl/5.32.0/x86_64-l
> inux /app/lib/perl5/site_perl/5.32.0
> /app/lib/perl5/5.32.0/x86_64-linux /app/lib/perl5/5.32.0) at /app/
> lib/perl5/site_perl/5.32.0/Module/Load.pm line 78.
> at /app/bin/finance-quote-wrapper line 114.
> 
> <<

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 characterise