Bug 119355

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.