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 430121 - Incorrect Sign Symbol for Fractional Commodity/Security Sale
Incorrect Sign Symbol for Fractional Commodity/Security Sale
Status: VERIFIED FIXED
Product: GnuCash
Classification: Other
Component: Register
git-master
Other Linux
: Normal major
: ---
Assigned To: David Hampton
Chris Shoemaker
Depends on:
Blocks: backport
 
 
Reported: 2007-04-15 22:36 UTC by Wanrong Lin
Modified: 2018-06-29 21:32 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Wanrong Lin 2007-04-15 22:36:55 UTC
This is best illustrated with an example.

Suppose I have a commodity/stock that can be traded at fractions of 1/6. If I have to sell 1/6 share, I can do that by entering "-1/6" in the "Shares" column of the transaction register. After the transaction is entered and the edit focus moves to the next line, the number in "Shares" column will automatically become "-0 + 1/6" (I don't think the "0" is necessary here, but it does not do any harm.). Now, if I move the edit focus back to the transaction I just entered, the bug will manifest itself like this: the minus sign in "-0 + 1/6" disapears, it becomes "0 + 1/6". In addition to confuse people, this will also create incorrect register entries if I  continue to edit other fields in the transaction, wrongly assuming my previous entered "-1/6" stays unchanged.
Comment 1 Wanrong Lin 2007-04-16 03:10:39 UTC
Just want to add that this bug seems to be still there in version 2.0.99, although in that version the "-" sign becomes red parenthesis.

By the way, I installed the 2.0.99 Windows binary, which is great! The windows binary is very timely for me since I just found out I can no longer build the new releases (2.10) on my fedora box since I don't have the latest libgoffice...

Thanks a lot for your guys work!
Comment 2 Christian Stimming 2007-04-18 09:10:12 UTC
If I understand correctly, then already the "-0 + 1/6" is an error because according to normal arithmetic rules, this means the number turns out positive instead of negative. Sounds like a bug in the expression parser. Have you been able to reproduce this erroneous number interpretation/parsing in other text fields of gnucash as well?
Comment 3 Wanrong Lin 2007-04-20 03:40:41 UTC
You are right, -0 + 1/6 is already wrong by normal arithmetic rules. But with the parenthesis representing negative numbers in version 2.0.99 (for windows), that is no longer a problem. However, my main issue is: 

1. It is awkward to enter a negative fractional share number (i.e., the number of shares to sell). Say, if I put "(1/6)" into the "Shares" field and leaves all other numerical fields to be blank (i.e., I just lost 1/6 share without any proceeds), the system seems to be very resillient to it. As soon as you enter this transaction, GnuCash will flip (1/6) back to a positive number "0 + 1/6". But if you put an integer number there, say "(1)", you don't have that problem. In other more complex situations, it will take quite a bit trial-and-error to get the transaction entered correctly. 

2. As awkward as it is, if I already have entered a transaction with a negative fractional share number, and I wish to modify that transaction (say change the number of shares from 1/6 to 1/3). As soon as my edit focus is on that register line, the negative number is flipped into a positive number by the system, and after I changed the number from 1/6 to 1/3, I press the "enter" button, and guess what? I changed the transaction from selling into buying.

I did not try this on any other fields, since I thought only shares of stocks can have fractions other than 1/10, 1/100, 1/1000.... It seems numbers like (0.23) works fine without the problems I described above.

Hope this helps a little bit. Please let me know if you need more infor. Thanks a lot.
Comment 4 Charles Day 2008-08-09 04:06:49 UTC
Confirmed in 2.2.6, however since r17457 it only affects fractions which numerator larger than denominator, e.g. "-4/3" experiences the bug, but "-1/3" doesn't. (This is because "-1/3" prints as "-1/3" now, rather than "-0 + 1/3".)
Comment 5 Andreas Köhler 2008-09-17 17:04:15 UTC
Fixed by r17533 on trunk and r17539 on branches/2.2 for inclusion in GnuCash 2.2.7.
Thanks for the report!
Comment 6 John Ralls 2018-06-29 21:32:08 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=430121. Please update any external references or bookmarks.