[GNC] problem setting the price of a share

Wed Sep 19 11:16:06 EDT 2018

correction: floating point fails with irrational numbers too.

David C

On Wed, Sep 19, 2018 at 10:13 AM David Carlson <david.carlson.417 at gmail.com>
wrote:

> I did not know "decimal format" was synonymous with floating point. I need
> to see the exponent to think floating point. I think of decimal as simply a
> way to print out numbers on paper or computer screens, not a computation
> method.  I definitely agree that floating point computations always have
> accuracy problems with very large or very small numbers.
> Since you mentioned BCD, that used to be a format used often in [16 bit]
> programmable controllers decades ago. In those days PLC's integers, binary
> numbers, hexadecimal and octal representation all used the same rudimentary
> logic for four function math. BCD was originally considered to be
> hexadecimal with the upper digits truncated for display purposes.  I think
> that the demise of BCD format partly came when some PLC manufacturers
> seemed to think that BCD and  hexadecimal were essentially equivalent which
> lead to serious programming issues in their controllers.
>
> David C
>
> On Wed, Sep 19, 2018 at 8:58 AM John Ralls <jralls at ceridwen.us> wrote:
>
>> David,
>>
>> David,
>>
>> Yes: "GnuCash was changed in release 2.6.8, dated late 2015 to usually
>> store
>> prices in decimal format when they were entered in decimal format”
>>
>> In computation, “decimal” and “floating point” are generally equivalent.
>> The rare exception is binary-coded-decimal or BCD, but few languages and no
>> current hardware support that directly (C/C++ doesn’t) and when I tested a
>> couple of BCD libraries in 2014 at Christian Stimming’s prompting I found
>> them to be unnacceptably slow.
>>
>> Regards,
>> John Ralls
>>
>> On Sep 18, 2018, at 11:36 PM, David Carlson <david.carlson.417 at gmail.com>
>> wrote:
>>
>> John,
>>
>> Did you find a reference to floating point in my last message?  If so it
>> was obsolete or inadvertent, as I know enough of the history of GnuCash to
>> know that GnuCash never has and never will go there and why.  There may
>> have been something in one of the bug reports that I cited, but I also
>> know
>> that those bug reports do not represent GnuCash current or future policy
>> but mostly users' perceptions which probably were not implemented either
>> because no developer had time or there was some conflict.  They will
>> mostly
>> be obsolete after release 3.3 comes out.
>>
>> The bug report that you referenced in your discussion regarding what will
>> happen in release 3.3 https://bugs.gnucash.org/show_bug.cgi?id=794755,
>> did
>> not appear in my search because my search was limited to open bugs.  I was
>> hoping to find it, but now I know why I missed it.
>>
>> David C
>>
>>
>> On Tue, Sep 18, 2018 at 11:46 PM Christian Pinedo Zamalloa <
>> chr.pinedo at gmail.com> wrote:
>>
>> If instead of a mailing list it was a social network, I just would like
>> your reply! Thanks again for your input and references,
>>
>> --
>> Christian Pinedo Zamalloa (zako)
>> Sent from my mobile device, please excuse brevity or typos
>>
>> El mié., 19 sept. 2018 1:22, David Carlson <david.carlson.417 at gmail.com>
>> escribió:
>>
>> There have been several discussions over the years around various aspects
>> of the topics of numeric accuracy, displaying accurate values vs easily
>> readable values, whether GnuCash records do or do not match brokers'
>> reports or newspaper stock price listings, and even whether the GnuCash
>> price database is properly configured and whether data is correctly
>> extracted from it for various reports. If you want to research the topic
>> further there are several threads in this user maillist going back a
>> decade
>> or more.
>>
>> I just searched the bug database and found several open bug reports which
>> directly involve these points.
>> *Bug 787813* <https://bugs.gnucash.org/show_bug.cgi?id=787813>
>> *Bug 793556* <https://bugs.gnucash.org/show_bug.cgi?id=793556>
>> *Bug 638175* <https://bugs.gnucash.org/show_bug.cgi?id=638175>
>> *Bug 410060* <https://bugs.gnucash.org/show_bug.cgi?id=410060>
>>
>> GnuCash was changed in release 2.6.8, dated late 2015 to usually store
>> prices in decimal format when they were entered in decimal format, but
>> there was a regression in the 2.7.x development series leading up  to the
>> 3.x releases reverting to the fractional display currently seen.  Bug
>> 793556 has already been filed regarding the fractional format as related
>> to
>> CSV imports and exports, but it does not extend to use of those values in
>> spreadsheets.  The fractional format is the raw display of the number
>> format used internally for certain calculations requiring high accuracy,
>> and a few users actually prefer to see prices displayed in that format, so
>> it is not likely to be completely hidden.
>>
>> John Ralls points out in his reply that release 3.3 will fix your first
>> concern as well as it can in this real world.
>>
>> David C
>>
>> On Tue, Sep 18, 2018 at 4:22 PM Christian Pinedo Zamalloa <
>> chr.pinedo at gmail.com> wrote:
>>
>> Hi David,
>>
>> At the end I was able to get properly the price by skipping it and
>> letting to GnuCash to calculate it as you suggested. However, I think that
>> this might be a kind of bug, because if I insert the price in decimal
>> format, it shouldn't be modified and the total amount should be calculated
>> accordingly.
>>
>> Regarding the fractional format of prices, one more issue. Apart from
>> being more difficult to read, when transactions are exported to CSV, the
>> fractional format is maintained (i.e. "123 + 3/45") and if the CSV is
>> opened with calc/excel we need to modify all the prices to be considered
>> numbers not strings (i.e. insert "=123 + 3/45").
>>
>> Thanks for your suggestions!!
>>
>>
>>
>> El sáb., 15 sept. 2018 a las 16:26, David Carlson (<
>> david.carlson.417 at gmail.com>) escribió:
>>
>> As I stated in my reply, enter the number of shares and total amount,
>> Skip the price, let GnuCash take care of that.
>>
>> David C
>>
>> On Sat, Sep 15, 2018 at 9:21 AM Christian Pinedo Zamalloa <
>> chr.pinedo at gmail.com> wrote:
>>
>> Hi David,
>>
>> I also agree with you that the fractional format is more difficult to
>> read than decimal and I also hope to return to decimal format or at least
>> to be able to choose between decimal or fractional format.
>>
>> Regarding my problem with price, I insert the number of shares, the
>> prices (in decimal format) and press enter. The decimal formal is
>> converted
>> to fractional format, but fractional number is not the same that I
>> inserted
>> before. :-(
>>
>> Any idea?
>>
>> --
>> Christian Pinedo Zamalloa (zako)
>> Sent from my mobile device, please excuse brevity or typos
>>
>> El sáb., 15 sept. 2018 14:49, David Carlson <
>> david.carlson.417 at gmail.com> escribió:
>>
>> Christian Pinedo Zamalloa
>>
>> You have discovered that it is impossible to have all three values
>> shares, price and total exactly as reported by your broker because he
>> usually has to round off one of the numbers.  The solution is to let
>> GnuCash set the price after you enter the number of shares and the total
>> amount.  Actually, GnuCash is closer to being correct than your broker is.
>>
>> You have also discovered that in release 3.3 GnuCash shows the number
>> of shares in fractional format, which has the technical advantage of being
>> very accurate, if very hard to read.  I believe that in the future GnuCash
>> may be changed back to show the number of shares in decimal format to be
>> easier to read, if less accurate.
>>
>> David C
>>
>>
>>
>> On Sat, Sep 15, 2018 at 4:16 AM Christian Pinedo Zamalloa <
>> chr.pinedo at gmail.com> wrote:
>>
>> Hello,
>>
>> I have problems to set the correct price of a share that I am
>> selling.
>>
>> I try to put the value "128,181208053691" which is automatically
>> converted
>> by GnuCash when i push enter key to "128 + 64/377" whose real value
>> is
>> "128,169761". Furthermore, I checked if I insert value "1", it is
>> automatically converted by GnuCash to value "1+3/377" (1,007958).
>>
>> I don't know how to solve this mesh. Am I doing something wrong?
>>
>> --
>> zako
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
>>
>>
>> --
>> Christian Pinedo Zamalloa (zako)
>> PGP keyID: 0xdb577d4ee6ffbd55
>> PGP Fgprt: A895 7C11 84F6 30B4 4938  32A4 9306 DFD0 CDE4 B542
>>
>>
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
>>
>>