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 -- Gcalctool can't handle small physic constants like the Boltzmann constant https://bugs.launchpad.net/bugs/110177 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
