str_real in rtl/inc/real2str.inc. Make sure to do a test suite run after changing anything in that code, because there are a lot of things that can go wrong there (and which have gone wrong in the past).

Jonas

I try to resolve http://bugs.freepascal.org/view.php?id=15308

Is not that fixed by svn rev 14490?

AFAIK this is Delphi compatible.

I tested some years ago while implementing sqlite dataset

Luiz

I try to resolve http://bugs.freepascal.org/view.php?id=15308
problem is with str
  str(1.0:10,s); writeln(s);
  str(1.05:10,s);writeln(s);
  str(1.05e2,s);writeln(s);
give results (:

1.000E+00
1.0E+0000
1.050000000000000E+0002
^^// moving

where I can find implementation of str

Darek

That's only part of a program, it does not compile. You may have typed it in your mail and accidentally put a ";" at the end instead of a ".", but that still means that the program you tested was probably different from what you wrote above.

result: 6.9388939907E-18 is this bug?

With which FPC version on which platform and with which test program do you get this result? Did you use any special options to compile the RTL or compiler? When I fix the above code to end with a "." instead of with a ";", I get " 0.00000000000000E+000" with FPC 2.2.4, 2.4.0 and 2.5.1 on different platforms (Mac OS X/ppc, Mac OS X/i386, Linux/i386).

Jonas

this program:
var
  d1,d2 : double;
begin
  d1:=105;
  d2:=1.05e2;
  writeln(d1-d2);
end;

result: 6.9388939907E-18

is this bug?
what should be repair:
formatfloat
real_str
constant assigment

Darek

I try this now with Delphi6 and all have only one space at front

I tested some years ago while implementing sqlite dataset

Darek

    d1,d2 : extended;

sorry,
I did not notice, that is different type (extended)

version 2.5.1 [2009/11/05] (linux and windows)

Darek

Ok, now I can reproduce it. It's caused by the fact that 1.05 cannot be represented exactly. 1.05e2 is first parsed as 1.05, and then multplied by 100. So you get an maximal error of extended_precision_delta*100. In that situation 6.9388939907E-18 is acceptable (extended_precision_delta is 1.0842021725e-19). The fact that the result is equal in case of double is simply because due to less available precision, the 1.05 value happens to be is rounded in a different way and 100*1.05 turns out the same as 105.0

Delphi apparently parses 1.05e2 in a different way (maybe it performs the "e2" multiplication on the string representation in order to minimise losses due to limited precision). Try the following program and you'll see that for the second subtraction, Delphi gives the same result as FPC:

var
 d1,d2,d3 : extended;
begin
 d1:=105;
 d2:=1.05e2;
 d3:=1.05;
 d3:=d3*100.0;
 writeln(d1-d2);
 writeln(d2-d3);
end.

Both results are correct in the context of IEEE floating point math.

Jonas

There is patch. Problem is only with numbers when correction of rounding
is made and only when  exponent is shown.
to test case these numbers should be added
str(0.99999999999e2:7,s);
str(0.99999999999e8:7,s);
str(1.0499999999999e2:10,s);

if someone help me I can modify test case.

Index: real2str.inc
===================================================================
--- real2str.inc	(wersja 14500)
+++ real2str.inc	(kopia robocza)
@@ -381,12 +381,6 @@
               d := frac(d);
               if (f < 0) then
                 begin
-                  dec(currprec);
-                  if (currprec=0) then
-                    begin
-                      inc(spos);
-                      temp[spos]:='0';
-                    end;
                 end;
             end;
           { calculate the necessary fractional digits }

Darek

I look at fpc_val_real_shortstr, which I think is used to convert form str to real
Its seems ease to change:
after decimal part of number is computed divide by length of fractional part should be moved to part of exponent (simply correct of exponent)

Try the following program and you'll see

That is different
1.05e2 is natural number, and 1.05 not
for natural number (till limit) we can expect equal representation

Darek