Re: [GNC] Precision in exchange rate conversion
Paul Abraham 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]p...@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@acasa.org.uk] > > References > >1. mailto:p...@acasa.org.uk > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using
Re: [GNC] Precision in exchange rate conversion
Yes, they're both standard registers (both bank current accounts in fact). Paul 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]<[1]p...@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 ;-) [[2]cid:part2.62ACF325.60F042A3@acasa.org.uk] References 1. [3]mailto:p...@acasa.org.uk ___ gnucash-user mailing list [4]gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: [5]https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see [6]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. References 1. mailto:[1]p...@acasa.org.uk 2. cid:part2.62ACF325.60F042A3@acasa.org.uk 3. mailto:p...@acasa.org.uk 4. mailto:gnucash-user@gnucash.org 5. https://lists.gnucash.org/mailman/listinfo/gnucash-user 6. https://wiki.gnucash.org/wiki/Mailing_Lists ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Precision in exchange rate conversion
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]p...@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@acasa.org.uk] > > References > >1. mailto:p...@acasa.org.uk > ___ > gnucash-user mailing list > gnucash-user@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 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Precision in exchange rate conversion
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 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 ;-) ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Precision in exchange rate conversion
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 ;-) On 19/02/2020 14:26, Adrien Monteleone wrote: Check that Preferences > General > Numbers > 'Force Prices to display as decimal s' is *unchecked*. This should result in fractions being shown rather than being rounded or truncat ed. You may need to have Trading Accounts turned on, but I could be mistaken. The total decimals used I think has something to do with the setting of the invo lved currencies. Both BRL and GBP are set to 1/100 as the lowest fractional piece of currency. Th us an exchange between them will preserve 4 decimal places. (1/100 * 1/100 = 1/1 ) Unfortunately, I don’t see a way to edit this field as it is greyed out in the S ecurity Editor. Regards, Adrien On Feb 19, 2020 w8d50, at 5:31 AM, Paul Abraham [1] wrote: I have real world transaction that involves a transfer from a GBP to a BRL account but cannot get it to accept either the correct value in BRL or the actual exchange rate. It insists on truncating the rate to 3 decimal places (or 4 sig figs?) and adjusting the amount to match, even though the "Transfer Funds" window suggests it's working to 6 DPs - . How do I fix this? Details are: OS: 4.19.102-1-MANJARO Gnucash version: Version: 3.8 (Build ID: 3.8b+(2019-12-29)) - the latest in the Manjaro repository. Amount in GBP: 1975.10 Amount in BRL: 11102.12 Exchange Rate: 5.62104 Gnucash forces exchange rate to 5.621000 resulting in BRL value of 11,102.04 Thanks ___ gnucash-user mailing list [2]gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: [3]https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see [4]https://wiki.gnucash.org/wiki/Ma iling_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. References 1. mailto:p...@acasa.org.uk 2. mailto:gnucash-user@gnucash.org 3. https://lists.gnucash.org/mailman/listinfo/gnucash-user 4. https://wiki.gnucash.org/wiki/Mailing_Lists ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Precision in exchange rate conversion
Hi, Yes, that's what I did first (it's actually what I normally do) but gnucash clobbers it to the incorrect value. I then tried entering the rate and the same thing occured. On 19/02/2020 15:18, Derek Atkins wrote: Hi, Paul Abraham [1] writes: I have real world transaction that involves a transfer from a GBP to a BRL account but cannot get it to accept either the correct value in BRL or the actual exchange rate. It insists on truncating the rate to 3 decimal places (or 4 sig figs?) and adjusting the amount to match, even though the "Transfer Funds" window suggests it's working to 6 DPs - . How do I fix this? Details are: OS: 4.19.102-1-MANJARO Gnucash version: Version: 3.8 (Build ID: 3.8b+(2019-12-29)) - the latest in the Manjaro repository. Amount in GBP: 1975.10 Amount in BRL: 11102.12 Exchange Rate: 5.62104 Gnucash forces exchange rate to 5.621000 resulting in BRL value of 11,102.04 The exchange rate is computed; so ignore that and just enter the correct values for GBP and BRL and ignore what exchange it gnucash claims. Thanks Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. -derek References 1. mailto:p...@acasa.org.uk ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Precision in exchange rate conversion
Hi, Paul Abraham writes: >I have real world transaction that involves a transfer from a GBP to a >BRL account but cannot get it to accept either the correct value in BRL >or the actual exchange rate. It insists on truncating the rate to 3 >decimal places (or 4 sig figs?) and adjusting the amount to match, even >though the "Transfer Funds" window suggests it's working to 6 DPs - . >How do I fix this? Details are: >OS: 4.19.102-1-MANJARO >Gnucash version: Version: 3.8 (Build ID: 3.8b+(2019-12-29)) - the >latest in the Manjaro repository. >Amount in GBP: 1975.10 >Amount in BRL: 11102.12 >Exchange Rate: 5.62104 >Gnucash forces exchange rate to 5.621000 resulting in BRL value of >11,102.04 The exchange rate is computed; so ignore that and just enter the correct values for GBP and BRL and ignore what exchange it gnucash claims. >Thanks > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-user mailing list gnucash-user@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.
Re: [GNC] Precision in exchange rate conversion
Check that Preferences > General > Numbers > 'Force Prices to display as decimals' is *unchecked*. This should result in fractions being shown rather than being rounded or truncated. You may need to have Trading Accounts turned on, but I could be mistaken. The total decimals used I think has something to do with the setting of the involved currencies. Both BRL and GBP are set to 1/100 as the lowest fractional piece of currency. Thus an exchange between them will preserve 4 decimal places. (1/100 * 1/100 = 1/1) Unfortunately, I don’t see a way to edit this field as it is greyed out in the Security Editor. Regards, Adrien > On Feb 19, 2020 w8d50, at 5:31 AM, Paul Abraham wrote: > > I have real world transaction that involves a transfer from a GBP to a > BRL account but cannot get it to accept either the correct value in BRL > or the actual exchange rate. It insists on truncating the rate to 3 > decimal places (or 4 sig figs?) and adjusting the amount to match, even > though the "Transfer Funds" window suggests it's working to 6 DPs - . > How do I fix this? Details are: > OS: 4.19.102-1-MANJARO > Gnucash version: Version: 3.8 (Build ID: 3.8b+(2019-12-29)) - the > latest in the Manjaro repository. > Amount in GBP: 1975.10 > Amount in BRL: 11102.12 > Exchange Rate: 5.62104 > Gnucash forces exchange rate to 5.621000 resulting in BRL value of > 11,102.04 > > Thanks ___ gnucash-user mailing list gnucash-user@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.
[GNC] Precision in exchange rate conversion
I have real world transaction that involves a transfer from a GBP to a BRL account but cannot get it to accept either the correct value in BRL or the actual exchange rate. It insists on truncating the rate to 3 decimal places (or 4 sig figs?) and adjusting the amount to match, even though the "Transfer Funds" window suggests it's working to 6 DPs - . How do I fix this? Details are: OS: 4.19.102-1-MANJARO Gnucash version: Version: 3.8 (Build ID: 3.8b+(2019-12-29)) - the latest in the Manjaro repository. Amount in GBP: 1975.10 Amount in BRL: 11102.12 Exchange Rate: 5.62104 Gnucash forces exchange rate to 5.621000 resulting in BRL value of 11,102.04 Thanks ___ gnucash-user mailing list gnucash-user@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.
