[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