Hello again, Bruce!
I can point out a logic error in your argument here.
On 2023-09-13 17:28, Bruce McCoy via gnucash-user wrote:
...Yousay that 3750/599 is "the more accurate." How precise isit? Let's see.
2.396shares * (3750/599) $/share = 2.396 shares
*6.260434056761268781302170283806343906510851419
3171953255425709515859766277128547579298831385642737 $/share
= $15.000000000000000000000000
0000000000000000000006839999999999999999999999999999999999999999999999997852.
So, thefraction is accurate to 51 significant digits....
By converting the rational number (3750/599) into a decimal number
6.260434..., you introduce a numerical error. The decimal number,
6.26043405676126878130 2170283806343906510 8514193171953255425
709515859766277128 547579298831385642737
is equal to the rational number,
626043405676126878130 2170283806343906510 8514193171953255425
709515859766277128 547579298831385642737 / 1 00000000000000000000
0000000000000000000 0000000000000000000 000000000000000000
000000000000000000000
This is a fraction in reduced form, since the numerator does not have 2
or 5 as factors. (This is easy to tell by inspection, because integers
with 2 as a factor have an even number as the final digit, and integers
with 5 as a factor have 0 or 5 as the final digit.)
The above fraction does not have the same numerical value as the price I
think is correct to use for your example transaction,
3750/599
The inaccurate decimal number you use as the price leads to an
inaccurate value for the resulting dollar amount. You show this
inaccuracy in the result.
So, rather than changing the numerical value of the price before
multiplying it by the number of shares, how about using that exact value?
2.396 = (2396/1000) by the definition of decimal number notation
2.396 shares * (3750/599) $/share = (2396/1000)*(3750/599) =
((4*599)/1000)*(3750/599)
= ((4*1)/1000)*(3750/1) = (4*3750)/1000 = 15000/1000 = 15.00... $
Thus, when GnuCash derives the price from the number of shares and the
transaction amount, and stores it as a rational number, it ensures that
our basic relationship,
$value = $price/share * #shares
is precisely satisfied.
You ask,
In September of 2003, we have a lot better options than Terry did in2000. What
are some of the ones we prefer?
By my calendar, this is September of 2023 not 2003, and we have even
better options available now than we did in 2003. However, the option
GnuCash uses now seems to give correct, exactly precise answers. Why change?
By the way, you did not respond to my question,
On 2023-09-09 13:05, Jim DeLaHunt wrote:
1. if your brokerage reports a transaction in terms of price, currency
received and paid, and shares received and issued, which are logically
inconsistent, how should you interpret that information? This is a
step you have to take before entering the transaction into your
bookkeeping.
I think that your answer to this question might really help you get to
the bottom of what is driving you in this thread.
Best regards,
—Jim DeLaHunt
On 2023-09-13 17:28, Bruce McCoy via gnucash-user wrote:
Jim,
Inyour response of Mon, Aug 21, 2023 at 5:00 PM via GnuCash-user yousaid:
"Logically,$value = $price/share * #shares, and this should be
preciseequality."
GnuCash“stores the price as a rational number, a ratio between numeratorand
denominator,”
"price= 15000/2396 = 3750/599 $/share...the more accurate 3750/599."
Let'ssee what GnuCash, excellent program that it is, does with the exact(price
per share) fraction it was given to use. If GnuCash does thecalculation
correctly, then
$value= $price/share * #shares will be a precise equality. If GnuCashdoes the
calculation incorrectly, then
$value= $price/share * #shares will not be a precise equality.
Yousay that 3750/599 is "the more accurate." How precise isit? Let's see.
2.396shares * (3750/599) $/share = 2.396 shares
*6.260434056761268781302170283806343906510851419
3171953255425709515859766277128547579298831385642737 $/share =
$15.000000000000000000000000
0000000000000000000006839999999999999999999999999999999999999999999999997852.
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.
_______________________________________________
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.
