[GNC] Precision in exchange rate conversion

[Derek Atkins]

Hi,

Are you doing this in a standard register or in a Stock/Mutual register?
In a stock/mutual register it has inputs for quantity, amount, and
price-per-unit.  In this case, the quantity and amount are stored, and the
price-per-unit is computed.  You can enter 2/3 and GnuCash will compute
the 3rd for you, so if we recommend entering in the two stored values.

In the regular register, however, where you get an "exchange rate dialog",
that's not how it works.  In that case it DOES store and use the exchange
rate.  So if you have the rate "displayed" as a decimal then it can round
and cause this behavior.  If it's stored as a fraction, then you wont have
that behavior.

It USED to be the case that the "rate" column was hidden and always stored
as a fraction, so this wasn't an issue.  I'm not sure when it changed.

John's message reminded me of this change, but I was unaware that it
affected the rate column (which, IMHO, it should not have since it is
supposed to be a non-visible column in the standard register).

-derek

On Thu, February 20, 2020 1:53 pm, Paul Abraham wrote:
>    No, sorry, that's not what I meant. I'm sure the fractional
>    representation, unhelpful though it is, is right*.
>
>    It's the fact that if I set the display setting to decimal, gnucash
>    tramples on the input value for the converted amount - I enter 11102.12
>    and it changes it to 11102.08. This is what is not very clever - the
>    programming here . Display settings shouldn't affect actual data, and
>    especially not user entered data (and even more especially not without
>    advising the user - it does this silently).
>
>    * ... well, in a sense: The arithmetic is right. But that isn't how
>    exchange rates work - banks don't start from the original and converted
>    values and calculate an absolutely precise ratio between the two. The
>    exchange rate comes first. The original value is multiplied by the
>    exchange rate (which is a decimal value) and then round the result to
>    form the converted value. Gnucash's fractional version is a fiction.
>
>    Regards
>
>    Paul Abraham
>
>    On 20/02/2020 01:01, John Ralls wrote:
>
>    That's not mangling the data, it's presenting the exact value of
>    11102.12/1975.10, a number that isn't representable as a decimal
>    without rounding.
>
>    As for the display being clever, of course it isn't, it's a computer.
>
>    But it you enter the two values 11102.12 and 1975.10 GnuCash shouldn't
>    change them, it should just calculate the ratio and present that as the
>    price, either exactly as 5 + 61331/98755 or as  5.621041972558352
>    rounded to however many decimal places. When I test that, it's exactly
>    what I get, see the attached screen shot. Note the exact exchange rate
>    in the exchange rate box but the rounded decimal values to the right of
>    it.
>
>    Regards,
>
>    John Ralls
>
>      On Feb 19, 2020, at 12:12 PM, Paul Abraham <[1]paul at acasa.org.uk>
>      wrote:
>      Hmm. That seems to work, but it certainly isn't what I want. The
>        exchange rate is now shown as "5 + 61331/98755" which is less than
>        helpful - it most certainly is not how real world exchange rates
>      are
>        quoted, and it makes comparison almost impossible!
>        Why does the display option mangle the data? That isn't very
>      clever. I
>        think I'll just stick in a fudge factor as a separate split to
>      correct
>        the total though it's a long way from ideal.
>        Thanks very much for the answer, though. I can stop chasing
>      moonbeams
>        now ;-)
>
>    [cid:part2.62ACF325.60F042A3 at acasa.org.uk]
>
> References
>
>    1. mailto:paul at acasa.org.uk
> _______________________________________________
> 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.
>


-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant