After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 502017 - Some workaround for reducing rounding error in extreme currency rates
Some workaround for reducing rounding error in extreme currency rates
Status: RESOLVED DUPLICATE of bug 432764
Product: GnuCash
Classification: Other
Component: General
git-master
Other Linux
: Normal normal
: ---
Assigned To: Charles Day
Andreas Köhler
Depends on:
Blocks: backport
 
 
Reported: 2007-12-06 12:34 UTC by Frank H. Ellenberger
Modified: 2018-06-29 21:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Frank H. Ellenberger 2007-12-06 12:34:51 UTC
Am Dienstag, 4. Dezember 2007 19:47 schrieb Frank H. Ellenberger:
> in bugzilla are a few problems reported about currency handling. Today for
> me, I solved one of them.

Good. We're very happy to improve the currency handling, especially if someone 
sends us patches.

Unfortunately I haven't quite understood what your *solution* here is.

> The price editor (...)
>
> But, ... if I press OK then, I get a rate of 0,000088. This is really not
> precise, the inversion would be 11363.63..

That's bad, yes.

<<My solution/workaround:>>
> My conclusion is: do not use the price editor for currencies. Instead
> create and delete a dummy transaction to enter more precise exchange rates.
>
> So my first question is, are there any objections, that the price-editor
> does not use the same smart code as xfer-editor for currencies?

"objections"? I think this is just a bug in the price-editor. If you say the 
xfer-editor has the correct code, the price-editor should use it as well.

> 2. should the conclusio be published anywhere?

As long as current gnucash has a bug here, you can file a bugzilla entry with 
this text and your proposed solution. 

Christian

This was originally filed under http://lists.gnucash.org/pipermail/gnucash-devel/2007-December/021701.html

Frank
Comment 1 Frank H. Ellenberger 2007-12-16 04:37:35 UTC
I think, I should be more precise:

also the xfer-editor stores this insufficient rounded to 6 digits number, if entering a RATE,
but entering an AMOUNT results in the much more precise a+b/c form.

Comment 2 Charles Day 2008-08-01 18:05:41 UTC
From my testing, in the transfer dialog it does not matter whether you use "Exchange Rate" or "To Amount". The price is always added to the price db in the a+b/c form. However, if you then edit the price using the price editor and click OK, the price gets truncated to 6 digits (as described in the mailing list link above).

So the transfer dialog is fine, and this bug has the same underlying cause as bug 309863.
Comment 3 Charles Day 2008-08-01 18:21:44 UTC
I am tempted to mark this bug as a duplicate of bug 309863, but I think I will keep them separate because the descriptions and comments are substantially different.

Fix committed in r17421 and r17429. Requesting backport for 2.2.
Comment 4 Charles Day 2008-08-01 20:27:12 UTC
I think that bug is essentially a duplicate of your other report, bug 432764, with a suggested workaround. The easiest workaround is to not press "OK" in the Price Editor if you don't intend to change the price.

Since bug 432764 is older, let's keep that one and mark this one off as duplicate.

*** This bug has been marked as a duplicate of 432764 ***
Comment 5 John Ralls 2018-06-29 21:55:47 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=502017. Please update any external references or bookmarks.