GNOME Bugzilla – Bug 721825
Online prices displayed as unreadable fractions in 2.6.0
Last modified: 2018-06-29 23:24:20 UTC
Windows XP Pro SP3 32bit. Online prices from Finance::Quote are showing in the Price Editor as large unreadable fractions. Example: EUR (vs GBP) in Price Editor window is shown as 9999/999999999. Resizing the column doesn't make any diffrence. If the price is viewed by clicking 'Edit' then is is shown as 824699999/999999999 So the price is really 0.8246 EUR/GBP but without actually clicking on the individual price you can;t see what it is. The 9999's seem unnecessary and clutter the interface to meke it unusable. In 2.4.13 the equivalent price would be displayed as 0.824600
Same issue for me. Windows XP SP3. Fresh install of Strawberry perl 5.18.2.1. Ran the "Install Online Price Retrieval" script to install the Finance::Quote and Date::Manip modules. Tested the install by running the gnc-fq-helper script echo (yahoo "HIINX") | perl gnc-fq-helper (("HIINX" (symbol . "HIINX") (gnc:time-no-zone . "2014-01-10 18:25:00") (last . 69.96) (currency . "USD"))) In the Price Editor I see "69 + 9599999/9999999" for the Quote. This was working before with GnuCash 2.4.13.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 410060 ***
This is different from bug 410060, which is only a question of the output format. But here we have a real import error. So https://bugzilla.gnome.org/show_bug.cgi?id=410060#c18 belongs here: > I see fractional retrieved prices, but gnc-fq-dump is not showing the > fractions. Is there a difference between what I see with gnc-fq-dump and > what's processed by gnucash? > > C:\Program Files (x86)\gnucash\bin>perl .\gnc-fq-dump yahoo NGUAX > Finance::Quote fields Gnucash uses: > symbol: NGUAX <=== required > date: 01/14/2014 <=== required > currency: USD <=== required > last: 19.16 <=\ > nav: <=== one of these > price: 19.16 <=/ > timezone: <=== optional > > C:\Program Files (x86)\gnucash\bin> > > The price editor reflects this as 19 + 1600000/9999999. > > For the security, I have the fraction traded set as 1/100000. > > If it matters, I'm seeing this in Windows after moving my data files from > linux. I did not see the fractional values under linux. Under linux I do not see this issue, too. Fetching quotes I get decimals as expected. But probably related: Import - QIF Bug 721447 - Entries with values of ,50 are imported as ,51 That is on windows
(In reply to comment #3) > This is different from bug 410060, which is only a question of the output > format. > But here we have a real import error. I don't see any evidence of that. In fact, I see exactly the same problem, in Windows, in the Transfer Dialog when editing exchange rates. The problem is likely in gnc-numeric. > > So https://bugzilla.gnome.org/show_bug.cgi?id=410060#c18 belongs here: > > I see fractional retrieved prices, but gnc-fq-dump is not showing the > > fractions. Is there a difference between what I see with gnc-fq-dump and > > what's processed by gnucash? > > > > C:\Program Files (x86)\gnucash\bin>perl .\gnc-fq-dump yahoo NGUAX > > Finance::Quote fields Gnucash uses: > > symbol: NGUAX <=== required > > date: 01/14/2014 <=== required > > currency: USD <=== required > > last: 19.16 <=\ > > nav: <=== one of these > > price: 19.16 <=/ > > timezone: <=== optional > > > > C:\Program Files (x86)\gnucash\bin> > > > > The price editor reflects this as 19 + 1600000/9999999. > > > > For the security, I have the fraction traded set as 1/100000. > > > > If it matters, I'm seeing this in Windows after moving my data files from > > linux. I did not see the fractional values under linux. > > Under linux I do not see this issue, too. Fetching quotes I get decimals as > expected. Yup, Windows only. > But probably related: Import - QIF > Bug 721447 - Entries with values of ,50 are imported as ,51 > That is on windows Maybe. Derek suggested that it might be a rounding problem.
r23720. Not quite a rounding problem, more a problem with computing the denominator. On Windows, (int)pow(10, 2) sometimes returns 99 instead of 100. The ramifications are obvious. *** This bug has been marked as a duplicate of bug 721447 ***
To close the loop on https://bugzilla.gnome.org/show_bug.cgi?id=410060#c18, I have updated to 2.6.1 and no longer see the bug. Many thanks! Ed
Thanks for the update, Ed!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=721825. Please update any external references or bookmarks.