[GNC] Precision in exchange rate conversion

[Derek Atkins]

Paul Abraham <paul at acasa.org.uk> writes:

> Yes, they're both standard registers (both bank current accounts in fact).

Then IMHO this is a bug.
That setting should not affect the Rate Column.
Please file a bug in Bugzilla.

Thanks!

> Paul

-derek

> On 20/02/2020 16:06, Derek Atkins wrote:
>
>     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