[GNC] Precision in exchange rate conversion

Paul Abraham paul at acasa.org.uk
Thu Feb 20 13:53:30 EST 2020


   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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-02-19 at 8.00.08 PM.png
Type: image/png
Size: 182269 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20200220/f88590c1/attachment-0001.png>


More information about the gnucash-user mailing list