correction: floating point fails with irrational numbers too. David C
On Wed, Sep 19, 2018 at 10:13 AM David Carlson <david.carlson....@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 <jra...@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....@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.pin...@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....@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.pin...@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....@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.pin...@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....@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.pin...@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@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@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. >> >> >> _______________________________________________ gnucash-user mailing list gnucash-user@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.
