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 309182 - exponential numbers with negative exponents can't be entered
exponential numbers with negative exponents can't be entered
Status: RESOLVED FIXED
Product: gnome-calculator
Classification: Core
Component: general
5.5.x
Other All
: Normal normal
: ---
Assigned To: Rich Burridge
Rich Burridge
: 314308 324598 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-06-28 13:11 UTC by Tom
Modified: 2005-12-20 15:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to fix the problem. (831 bytes, text/plain)
2005-06-30 14:27 UTC, Rich Burridge
Details

Description Tom 2005-06-28 13:11:17 UTC
Please describe the problem:
in scientific mode, the gcalctool howto explains how to enter
an exponential number correctly. For instance it reads:
number:      
0.00000012   
enter:    
12 Exp 8 +/- 
display:
1.2e-7

From at least version 5.5.41 entering the keys [1] [2] [Exp] [8] [+/-] 
yields the number: -1.2e9
I can't find a way to enter negative exponents, which makes the app 
unusable for scientific purposes.

Steps to reproduce:
1. Just try to enter any floating point number with a negative exponent in
scientific mode
2. 
3. 


Actual results:
the negative sign is interpreted to belong to the mantissa

Expected results:
the negative sign has to go to the exponent

Does this happen every time?
Yes

Other information:
Comment 1 Rich Burridge 2005-06-30 14:12:48 UTC
When the support for arithmetic operator precedence was added into
gcalctool in the 5.X.Y series, it looks like a section of code was
removed from the +/- handling, that specifically dealt with changing
the sign on the exponent. Now that the GNOME servers are back up,
I'll get that added back in today.

Having said that, you should be able to use the arithmetic operator
precdence mode to enter these numbers. First do to the View menu and
check the "Use Arithmetic Precedence" menu item. Then enter the number
with:

12 Exp +/- 8

You'll notice that the order of entry is different, and I'll open a
separate placeholder bug against the gcalctool documation, for this
to be fixed.

Tom, can you please confirm that you are able to successfully enter
number in arithmetic operator precedence mode using the above approach.
I've tried it with the latest gcalctool (5.6.18), but hopefully it should
work with 5.5.41 too.
Comment 2 Rich Burridge 2005-06-30 14:27:44 UTC
Created attachment 48456 [details]
Patch to fix the problem.
Comment 3 Rich Burridge 2005-06-30 14:30:31 UTC
Change checked back into CVS HEAD. I've bumped the version
number in configure.in to 5.6.19.
Comment 4 Rich Burridge 2005-06-30 14:37:37 UTC
I've opened bug #309210 to handle gcalctool documentation
changes needed for GNOME 2.11/12.
Comment 5 Tom 2005-06-30 15:14:24 UTC
Entering the keys 

 12 Exp +/- 8

gives

 -(12*10^)8

which means it does not work in version 5.5.41.
The minus sign generated by "+/-" is not taken to belong to the exponent but in
front of the whole expression.

  Anyway, thanks for your efforts.

 Cheers,
 Tom
Comment 6 Rich Burridge 2005-06-30 15:44:22 UTC
Sorry, I gave you the wrong expression. In arithmetic precedence
mode that should have been:

12 Exp - 8

(minus not change sign).

Does that expression work for you?
If it does, I'll fixup the doc bug reference too.
Comment 7 Tom 2005-07-01 09:08:15 UTC
Allright, this way it works.
Cheers!
Comment 8 Rich Burridge 2005-07-01 16:12:36 UTC
Cool. I've update the gcalctool bug accordingly. Thanks.
Comment 9 Rich Burridge 2005-07-01 16:26:34 UTC
Jeez. I write one line and make two mistakes. Let's try that again.

Cool. I've updated the gcalctool documentation bug accordingly. Thanks.
Comment 10 Rich Burridge 2005-08-24 14:49:55 UTC
*** Bug 314308 has been marked as a duplicate of this bug. ***
Comment 11 Rich Burridge 2005-12-20 15:43:09 UTC
*** Bug 324598 has been marked as a duplicate of this bug. ***