GNOME Bugzilla – Bug 410060
automatically calculated exchange rates are displayed as fractions
Last modified: 2018-06-29 21:27:23 UTC
When I enter a transaction from an EUR account to a TRL account, a window appears asking for the exchange rate. When I choose "To Amount" instead of entering the exchange rate, the corresponding price in the price editor is entered as a fractional value. For example: I enter 200 EUR = 370 TRL as a transaction (as "To Amount"). Afterwards, in the price editor, there is an entry which has as exchange rate "0 + 20/37" (which is mathematically correct). However, on gnucash-devel, Derek Atkins says: ..."the system shouldn't ever display fractions anymore."
I did not repro this, but I'm almost positive it's confirmed.
It is still present in version 2.4.7
*** Bug 701435 has been marked as a duplicate of this bug. ***
I like the more precise algebraic expression expression. Eventually we could have 2 columns and the user can hide the less interesting one.
In https://bugzilla.gnome.org/show_bug.cgi?id=701435 I was referring to data downloaded from the internet by the price editor and displayed there which may or may not be the same as a manually entered price. I cannot disagree with the internal use of the fractional form for computations, but Frank is the only person that I know of that wants to see currency values expressed that way on the screen.
Searching for inaccuracies like rounding errors, I prefer to see in transaction based entries i.e. I got 3 USD for 2 EUR "0 2/3" while the online quote of USD in EUR was reported as 0.666667 Eventually we should keep the current behavior, but add a button to the dialog "Display all rates as decimals"
Which dialog? Would that be in the Online Banking section of the GnuCash Preferences and retained indefinitely? It would not be changed very often, if ever.
I thought of the price db editor dialog. To get it persistent, we could in preferences add a section "price db" with a checkbox.
I just took another look at my own data file. Prices that originated from the Finance:Quote module are decimal showing 6 decimal places in US Dollars. I found one recent price expressed in fractional form that came from user:xfer-dialog which I think is what Thomas Klausner [reporter] is referring to in the original description just before his quote from Derek Atkins. Stock purchase transactions are not generating price entries in my file. That may be covered in another bug report. My point is that I did not find a reason for prices to be expressed to 6 decimal places. I think that the price db is only intended to be a local source of prices for reports. Thus I would propose that prices should be expressed to the same number of decimal places that was received from the source or as displayed in the file default currency or in the reported currency if it is not the default currency. Then it might make sense to have an option to show fractional form or to select the number of decimal places to show. These should be persistent if they are user selectable. Reports do not need more digits than the default for the currency. Calculations for specific trades are kept with each transaction individually. That is the only place where higher accuracy may be needed, although the price really only serves as a check to see if the number of shares and total (or net) amount reasonably go together for that trade. In fact, some users probably bury commissions and costs in the price instead of tracking them separately, so for them the price is definitely only a reference. There is a place in the stock db for fractions of shares traded. That too is sufficient for reports.
6 decimals are usual at all exchanges, I know. And they make sense: assume you wish to buy a house for 100,000.00 € and pay in US$ The price db is not only used for your reports but also for your transactions. The result will then be rounded to the least fraction of your commodity e.g 1¢.
We use rational (i.e., variable-denominator) math to avoid unintentional rounding errors. I don't think we should change that, but we could make it a preference item to always display rates as decimal approximations. A second preference could specify the precision. Would that satisfy everyone?
That works for me as long as there is a way to make the display easy to read.
And by "easy to read" you mean decimal rather than a fraction with a lot of digits, right?
Yes, because that is the form we see in the newspapers and in the corporate annual reports.
*** Bug 721825 has been marked as a duplicate of this bug. ***
Frank: do you know when and why this change in behaviour was introduced ? It must have been between branching 2.4 and 2.5.2 according to bug 701435. I can understand your reasoning, but it seems several users don't like the new behaviour.
When I was programming machines, I generally used a different numbering system for internal calculations than I used to display numbers on the MMI. Actually, in early PLC's the best accuracy was obtained using integer math with single precision integers. Now there are better choices for accuracy, but it is always desirable to display values in engineering units. Thus there was for me a mandatory final step of converting numbers that were intended to be displayed into engineering units for the display registers only. I do not think that things are that different in PCs that numbers cannot be converted for display purposes only. As I stated before, internal calculations can and should be done using the best methods available, but normal users see dollars and cents in the United states or Euros with decimals in the European Union. Numbers displayed in other forms require additional thought, and in particular forms that look like irrational fractions are nearly incomprehensible. Granted, judging from the problem that cropped up in release 2.6.0 and reported in https://bugzilla.gnome.org/show_bug.cgi?id=721447, conversions for display must be done carefully.
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.
Sorry, here we have "only" a discussion of formats, but bug 721825 and #c18 have real differences between imported and stored/displayed values. So I copied comment 18 to bug 721825. About Bug 701435 - Price editor shows updated prices in integer fraction form: David, do you remember the exact value of your source and which OS you used? If it was Finance::Quote, they use usually 6 decimals. Then the result would be impossible and it would be the first occurence of the wrong import. Then it should be reassigned as a duplicate of 721825.
On Windows, (int)pow(10, 2) was returning 99 instead of 100, which created a result that was both correct and impossible to convert back to an exact decimal, at least using our extremely lame gnc_numeric_to_decimal function. r23720 fixes that, which will reduce some of the agony, especially with regard to prices retrieved via F::Q as two-decimal-place floats.
*** Bug 722794 has been marked as a duplicate of this bug. ***
I created Bug 701435 on June 1, referring to the 2.5.x series if I recall. I was referring to prices imported from the F::Q into release 2.5.0 or thereabouts. I probably was testing in Windows 7. The May 31 mutual fund quotes are still in my data file, identified as from F::Q and in fractional form. For a couple of NYSE stocks and NASDAQ stocks there are two May 31 F::Q prices, one in decimal form and one in fractional form. I do not recall the time of day that I downloaded the quotes, although it was probably a few hours after the closing bell. There is no second price in decimal form for the mutual funds. Perhaps I got the decimal quotes earlier in the day before the May 31 mutual fund prices were available. So technically that bug may be an earlier manifestation of bug 721825 or 721447. At this point I do not think that it matters except as a point of interest.
2.6.8 has a couple more changes that will help with this, though it won't completely fix it. If you enter an actual price or get one from Finance::Quote that's in decimal form and > 1, GnuCash won't mess with it. If it's < 1, GnuCash will invert it and that may well result in a fraction that won't display in decimal form. If you enter an amount, GnuCash will convert the price so that it's > 1 which does improve the likelihood that it will be displayable as a decimal. Ideally we should always display in decimal form even when we're storing a fraction in the background, but implementing that in this case is a bit more involved than the other changes.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=410060. Please continue processing the bug there and please update any external references or bookmarks.