Gcalctool can't handle small physic constants like the Boltzmann constant

Bug #110177 reported by wwwandy
6
Affects Status Importance Assigned to Milestone
GCalctool
Fix Released
Medium
gcalctool (Ubuntu)
Invalid
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gcalctool

Open Gcalctool, switch to
"Ansicht"-"Wissenschaftlich" (in english i think "view" "scintific")
Klick on drop-down "constants", "edit constants"

Now i tried to add the Boltzmann-Konstante 1,380 650 5 · 10−23 J K−1
But there is a hint at the lower border: "Alle Werte werden zur numerischen Dezimalbasis angegeben"
So, it doesn't seem to be possible to add a constant like "1.38e-24"

then i tried to add it without e 0.00000000000000000000000013806505 which is somewhat annoying.
Then I clicked on the new constant and a "0" appeared". Then I switched the display mode to "scintific" and now the constant
1.380650656e-23 is shown correctly. Even if i switch back to the constant editing window, the constant is now shown in exponential form,
but can't be edited. Just try to change 1.38e-23 to 1.38e-24.

ProblemType: Bug
Architecture: i386
Date: Thu Apr 26 08:27:00 2007
DistroRelease: Ubuntu 7.04
ExecutablePath: /usr/bin/gcalctool
Package: gcalctool 5.9.14-0ubuntu1
PackageArchitecture: i386
ProcCmdline: gcalctool
ProcCwd: /home/robo
ProcEnviron:
 LANGUAGE=de_DE:de:en_GB:en
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: gcalctool
Uname: Linux robo-desktop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

Revision history for this message
wwwandy (spam-tech-chat) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here:http://bugzilla.gnome.org/show_bug.cgi?id=439087

Changed in gcalctool:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Unconfirmed → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

upstream closed it as NOTABUG

"This works for me (upto the accuracy of 30 significant places).
I'm using gcalctool v5.19.2 with Ubuntu Feisty.

I'm in scientific mode. I used the Acc menu, "Other..." menu item
to set the accuracy to 30 significant places. (This is the bit I think
the bug submitter missed).

I highlighted "0.00000000000000000000000013806505" from this bug report
and used the right mouse button menu to "Select All".
I clicked on the "Edit Constants..." menu item in the "Con" menu.
and double clicked on the Value field of one of the existing constants,
cleared it, then used the right mouse button menu to "Paste" in the
new number. 30 significant places stores "0.000000000000000000000000138065".
I hit the OK button to accept it.

Pulling down the Con menu shows "0.000000000000000000000000138065" set
for that Constant. (Note that if I had the significant places set to a
lower value -- like 9 -- it does indeed show up in this menu as "0").

Now the menu item can be retrieved from the Constant menu and used in
calculations.

NOTABUG."

Changed in gcalctool:
status: Confirmed → Rejected
Changed in gcalctool:
status: Unknown → Rejected
Revision history for this message
Scott Jackson (scott-jackson) wrote :

No, actually, this is very much a bug:
#1 - gcalctool treats constants the same as the mode the calculator is currently in. This is okay, but it should be able to accept 6.626e-34 in that particular format without me having to switch it to scientific notation and then switch out.
#2 - even when I switch to scientific notation and enter Planck's Constant (see above), it becomes incorrect when I switch back to regular mode. I get no notification of whether or not my constant is parseable or what value it even represents- it sits holding my constant as if it's going to do something with it and the constant just disappears into the innards of the app. The actual *bug* part can be seen when I switch the calculator to scientific notation by pressing the "Sci" radio, go into the "Con" menu and pick "Edit Constants...". If I change something to Planck's Constant (6.626e-34, supported notation in gcalctool's sci mode), and try to use the constant later, it comes out as 6.626e0, which is not even an approximation (which would be, like, 0.00 or 0.01 or something at all), but a wrong answer.
#3 - 30 decimal places makes this calculator extremely weak compared to commercial-grade pocket calculators. My TI solar can do e-99 to e+99, but my Dual-Core can't even comprehend Planck's constant? Since this seems to be the flagship calculator application on gnome, I might make the suggestion to consider refactoring in the capability to do, at the minimum, 99 places before and after the decimal. Since we're not limited by display length like EEs addressing seven-segment displays are, it should be a lot less boring to find a way to display 99 places on a desktop app.

Feel free to ask follow-ups

Revision history for this message
Sebastien Bacher (seb128) wrote :

could you comment upstream? that will work better than having somebody from the distribution team sending comments there

Revision history for this message
Scott Jackson (scott-jackson) wrote :

Ouch, you mean I have to make an account for *another* bugzilla?
I suppose, when I have time and motivation I will, but it would be cool, since launchpad/ubuntu seems so keen on integration with other bug trackers, if perhaps it could keep comments updated...
but I guess that belongs on the launchpad tracker, now dunnit

Revision history for this message
Sebastien Bacher (seb128) wrote :

I've copied your comment upstream.

Changed in gcalctool:
status: Rejected → Unconfirmed
Changed in gcalctool:
status: New → In Progress
Changed in gcalctool:
status: In Progress → Fix Released
Changed in gcalctool:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.