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 347791 - Import does not match any transactions when ATM fees threshold is set to 0
Import does not match any transactions when ATM fees threshold is set to 0
Status: VERIFIED FIXED
Product: GnuCash
Classification: Other
Component: Import - Other
2.0.x
Other Linux
: Normal normal
: ---
Assigned To: Christian Stimming
Christian Stimming
Depends on:
Blocks: 347575
 
 
Reported: 2006-07-17 14:52 UTC by Konstantin Goudkov
Modified: 2018-06-29 21:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Konstantin Goudkov 2006-07-17 14:52:16 UTC
In import-backend.c (line 598),
if (downloaded_split_amount ==  match_split_amount)
is not true even for matching amounts because of the use of double type.

Should be something like:
if(fabs(downloaded_split_amount - match_split_amount)<0.001)
Comment 1 Christian Stimming 2006-07-17 15:57:04 UTC
Err... yes. In fact, the conversion to double should be thrown out altogether, and instead the gnc_numeric should be used all the way. This would solve this problem once and for all.
Comment 2 Derek Atkins 2006-07-18 00:09:49 UTC
I think it was converted to double because gnc_numeric_equal() is fairly expensive.  I have no problem with the approach suggested in comment #0
Comment 3 Christian Stimming 2006-07-18 08:58:42 UTC
I do have a problem with the approach suggested in comment#0 in this simple form, because the precision must instead be depending on the commodity's SCU. So either we get the SCU and use that ins the difference norm, or we just use the gnc_numeric. The argument of using doubles instead of gnc_numeric_equal() was given by myself in r11496 (gnome2-branch, 2005-10-16); however, at the time I didn't think of this erroneous implications of double values. In the light of this error I would rather go back to the original gnc_numeric_equal().
Comment 4 Derek Atkins 2006-07-18 14:04:32 UTC
Why does the precision need to depend on the SCU?  The problem here is that 'zero' isn't necessarily 0.0.  It could be .00000000000000001 or -0.000000000000001 or something like that.  I think it's perfectly reasonable and perfectly safe to say:

   fabs(diff) < 0.00000000001

But you're welcome to return back to gnc_numeric_equal().
Comment 5 Christian Stimming 2006-08-12 14:49:23 UTC
Applied initial suggestion in r14648, awaiting audit and backport.
Comment 6 Derek Atkins 2006-08-14 05:17:16 UTC
Backported to 2.0 in r14667.
Comment 7 John Ralls 2018-06-29 21:10:04 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=347791. Please update any external references or bookmarks.