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 620191 - Allow alternative exponential notation that doesn't require brackets
Allow alternative exponential notation that doesn't require brackets
Status: RESOLVED OBSOLETE
Product: gnome-calculator
Classification: Core
Component: general
5.31.x
Other Linux
: Normal enhancement
: ---
Assigned To: gcalctool maintainers
gcalctool maintainers
Depends on:
Blocks:
 
 
Reported: 2010-05-31 22:19 UTC by Magnus Danielson
Modified: 2018-05-22 11:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Magnus Danielson 2010-05-31 22:19:25 UTC
When using older versions (such as 2.28.2) entering a number like 160M/8k would translate to entering the engineering wise 160E6/8E3. The Exp button was used for this. The replacement x10^y buttor produces the equation 160x10^6/8x10^3 which gives a completely different answer than intended. The syntax of the Exp function binds 6 and 3 to the number before harder than the x and / functions, so the calculations is (160E6)/(8E3) = (160x10^6)/(8x10^3) = 20000. The Exp button carries the needed syntax which now seems lost.

The 10^y functionality as an inverse for log is as expected. So would e^y be for ln.

It's sad to see gcalctool loose its usefulness as a scientific calculator. This change made operation much more complex than they should be. Please revert that "fix".
Comment 1 Robert Ancell 2010-06-01 00:22:52 UTC
Discussed on IRC:
http://irclogs.ubuntu.com/2010/06/01/%23ubuntu-desktop.html

One thing to note, I would like to support SI units, this may solve the issue in your case:
https://bugzilla.gnome.org/show_bug.cgi?id=581821
so then you would just enter 160M/8k

The conclusions were:

- The mathematically correct way is to use brackets
- The parser should support alternative notation using a special glyph for the "e" character, e.g.:
1
Comment 2 Robert Ancell 2010-06-01 00:26:59 UTC
Hmm, bugzilla didn't like the glyph, the rest of the comment should read:

1E2  (but using U+1D5D8 MATHEMATICAL SANS-SERIF BOLD CAPITAL E)

- There was discussion that perhaps this "E" mode should be the default behaviour in Engineering mode but I think I'll put it in the preferences instead.

I don't get this comment:
"The 10^y functionality as an inverse for log is as expected. So would e^y be
for ln."
Do you mean "why is there no e^y button?" - there is an "e" button, you can just use it as a standard variable.
Comment 3 Magnus Danielson 2010-06-01 01:19:53 UTC
Disagree. The E notation is what is used in engineering and scientific usage, which in reality is much closer to actual use than strict mathematics.

Do not confuse the "Scientific" mode with scientific use!

The changed titel does not reflect what this bug is about!

Also, this is not an enhancement, this is getting a functionality back that was there!

This bug was filed since the <val>=<num>E<num> function was removed and replaced by the <val>=<val>x10^<val> which has very different semantics.

Entering numbers like 1,6099E-22 is commonplace in scientific and engineering work, and this functionality was lost and this bug was filed to restore that. The E is actually part of forming a value.

The IRC discussion referred to in comment #1 misses the point that xEy is not an operation, but actually part of entering a number. The conclusions in the IRC thread does not relate to the essence of this bug.

To comments on comment #2:

In normal calculator tradition certain functions and their inverses may be combined, such logical pairs inclue 10^x and log x, e^x and ln x. Such pairing may be used and will not confuse many users. The infamous Inv button creates the alternation.

However, the E button shall not be confused with the e^x function.

Oh, and the title no longer reflects the bug content. Please change back.
Comment 4 Robert Ancell 2010-06-01 01:35:08 UTC
You can read the design goals of gcalctool here:
http://live.gnome.org/Gcalctool

The functionality has changed from 2.28.2 (intentionally) but you have raised a valid use case where the "E" exponential abbreviation is more useful than the mathematically correct x10^ notation.

There were technical reasons why E notation was not continued (discussed on IRC) but this has been resolved by proposing a new glyph for the notation.

The title reflects the problem you have raised, which is using exponential notation requires brackets and this makes it slow to use.

The solution is to add new functionality, thus this is an enhancement.
Comment 5 Robert Ancell 2010-06-01 01:38:16 UTC
The issue regarding the e^x button is in my opinion a hangover from physical calculator days where a stack based approach required buttons for everything

gcalctool is not trying to match physical calculator behaviour; it is more logical to write equations as you would write them on paper, thus there is no need for e^x.
Comment 6 Magnus Danielson 2010-06-01 02:05:41 UTC
Having already read the design goals of gcalctool, I can't see the relevance here. Are you attempting to say that standard scientific use is not in the scope of gcalctool? Saying mathematical is a restriction which may misguide you.

The use of E in the representation of numbers both as being entered and being presented is mathematically equivalent to x10^y but is not equivalent in the syntax.

Already from the start I have been trying to point out that the syntactic meaning of E when entering numbers for calculations is distinctly different from that of the x10^y and only after the syntax construct of <num>E<num> has been converted into a val it may be allowed for any calculation, as E has higher precedence than * or / in this case. Look at the C grammar for inspiration.

I think comment #5 is not helpful. The functionality here is widely used and understood by many. It saves time for users. Many alternative approaches such as support for SI scaling units may exist in parallel, for convenience. What was in other calculators or how a mathematical writing would look may not be relevant references, but ease of use. Many conventions exists and is widely used. Ease of use is. The reason for me filing a bug-report is that functionality that used to be there was removed and it caused the user to be confused and somewhat frustrated. This is only my trial bug, I have a few other things gone missing!
Comment 7 GNOME Infrastructure Team 2018-05-22 11:44:52 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-calculator/issues/13.