Version: 2.0 (using KDE 3.5.0 Level "a" , SUSE 10.0 UNSUPPORTED) Compiler: Target: i586-suse-linux OS: Linux (i686) release 2.6.13-15-smp Step to reproduce: Entered the value 2415020.3135 into KCalc and hit enter. Actual behaviour: KCalc displays the value as 2.41502e+06. This does not display the extra precision of the entry value, comprising of the digits 03135. Expected behaviour: KCalc should display the value as 2415020.3135. Attempts at obtaining expected behaviour that failed: I tried changing the maximum number of digits and decimal digits in KCalc settings to 20 and 10 respectively to no avail. Justification for expectation: We wants to see all the digits we entered. If we were content with an e+ notation of fewer digits we would enter it so ourselves. Further, not all digits are "at home" in the exponential notation. For example the value I entered above is a Julian Date (see http://en.wikipedia.org/wiki/Julian_date for what that is) which is most often a long number with seven digits to the left of the decimal point and quite often with as much as four digits to the right of the decimal point. Such values should be displayed as entered. If this bug is not fixed otherwise a user who tries to calculate the difference between 2415020.3135 and 2415022.1177 will see 2.41502e+06 being subtracted from "itself" but to give a (correct) result of -1.8042. The "invisible" digits suddenly come into being. Why not a wishlist: Mathematical tradition dictates that a value must be represented with as much precision as it actually has. This goes to the extent of saying that 5.0190 is different from 5.019, since the extra zero in the previous number indicates the greater precision in measurement whereas the latter number indicates the uncertainty at the fourth decimal place. Therefore IMHO this is not a "it would be nice if it were like this" case but a "it should be like this" case. Pardon please if misjudgment.
I think this has already been fixed.
Where, please? In the current development builds?
Hi Shiramana, The bug you reported was indeed quite embarrassing, but since other users had a similar problem, I fixed it for both KDE-3.5.1 (which will be released soon) and for KDE-4.0. Thanks Klaus *** This bug has been marked as a duplicate of 116835 ***
Can anybody confirm if these similar following issues have been fixed in 3.5.1: In base Dec, enter 1048576. Now change to base Hex. Display is correct -> 100000. Now change back to base Dec -> 1.04858e+06 (incidently, edit 'Copy' the Hex value here gives 0x1048576 saved to clip board). The same can be achieved by entering 100000 in base Hex, and then changing straight to Dec -> 1.04858e+06 Thanks, Nick
Using KCalc 2.01 on KDE 3.51 on SUSE Linux 10.0. > In base Dec, enter 1048576. Now change to base Hex. Display is correct -> > 100000. Yes. This is correct behaviour. > Now change back to base Dec -> 1.04858e+06 No. I get 1048576. This is correct behaviour. > edit 'Copy' the Hex value here gives 0x1048576 saved to clip board). No. I get 0x100000. This is correct behaviour. > entering 100000 in base Hex, and then changing straight to Dec -> 1.04858e+06 No. I get 1048576. This is correct behaviour. (Many many thanks to those who fixed this biiig bug! I was forced to access Windows Calculator over Wine and now I don't need to! :D Thanks again.)
Yes, just on the last hours of Konstruct building 3.5.1 - it is indeed fixed :-) Many thanks, Nick
The similar issue that Nick asked to test was reported by me as bug #119354 and dupped to bug #118279.
This bug which has been fixed in KCalc 2.01 is reproduced by the Kicker Math Expression Evaluator applet. I have hence reported: Bug #122725: Kicker applet Math Evaluator reproduces KCalc bug #119355