GNOME Bugzilla – Bug 439087
Gcalctool can't handle small physic constants like the Boltzmann constant
Last modified: 2007-10-03 04:45:46 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/gcalctool/+bug/110177 "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. ..."
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.
reply from the ubuntu bug submitter: "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"
Reopening until I have the time to investigate further.
Note that as part of the fix to bug #469245, you can now cut and paste exponential numbers. This fix is currently only in SVN trunk, but will be included in the next gcalctool tarball release for GNOME 2.21.1. Hopefully before then, I'll increase the allowed number of places to something like 200 as well.
Created attachment 96527 [details] [review] Patch to mostly fix this problem. This patch makes the following changes: The number of significant places has been increased to 99 and the number of displayable digits has been increased to 150. The online help has been adjust to reflect these changes. In ce_tokeniser.l, I had to make the same change (s/40/150) five times. Sami, is there any way that this can be defined as a constant or something? There is one other small but annoying problem, which I'm not sure is gcalctool's fault. If you have something in the gcalctool display that is wider than the display area, a scrollbar is shown, but the first digit isn't properly displayed. The workaround here, is to enlarge the size of the calculator window until the scrollbar goes away.
Sami, could you look at and respond to the ce_tokeniser.l problem mentioned in comment #5 please? Thanks.
Hi, Yes I think we should be able to use use constants. Replacing if (strlen(yytext) > 150) parser_state.error = -PARSER_ERR_TOO_LONG_NUMBER; with if (strlen(yytext) > MAX_DIGITS) parser_state.error = -PARSER_ERR_TOO_LONG_NUMBER; in tokenisers should work.
Created attachment 96533 [details] [review] Revised patch Yes, that seems to fix the problem. Thanks.
I've opened bug #482688 http://bugzilla.gnome.org/show_bug.cgi?id=482688 on the Gtk+ scrollbar problem. I've committed this patch to SVN trunk. It'll also be in the first gcalctool tarball for GNOME 2.21.X in the near future. I'm closing it as FIXED. I realize there is still the scrollbar issue, but a separate bug has been filed on that (and there is a workaround). If anybody finds any other problems related to this fix, please comment. Thanks.
Created attachment 96551 [details] [review] Increased the maximum number of displayable digits to 200. Reread the bug comments again and saw that 200, not 150 was requested. Also had to adjust the max_fix array. This is the maximum value (depending upon the current numeric base), before a fixed number is automatically converted to scientific notation.