Show quoted text 6 lines
Hello,
People that have installed FPC 1.0.6 using an RPM from our download site
or one of the mirrors, should check their installation. There has been an
error when generating the RPMs due to some misconfiguration of the RPM
build system.
Hi Michael.
Apologies for not have prepared the bug report...as promissed at AEI.....unf
ortunately the workaround gives the correct result and I am pressed for time to continue. I will get back to *that* specific bug...later..
However,
I had a bit of a ding-dong with the compilers.
Verion 1.0.4 had several small bugs which partially was resolved with the compiler I downloaded now (1.0.6). "Beta" also had the bug.
I picked up some extras with 1.0.6.
Whether I can call (1) a bug I dont know, but it is probably not correct. (2) may be of serious consideration although I really do not want to point fingers.
=================================================================
1) If a writeln contains functions which generates a lot of writeln output, then the result of the writeln is lost.
e.g
writeln('Integral=',Generalised_EllipticE(y,k)[1],' ',Generalised_EllipticE(y,k)[2],' i');
output is NOT the last writeln on the terminal if the functions themselves contain writelns.
Somehow this does not seem as intended (or correct to me)....Did you intend it to do that?
If this is not exactly clear I will send an example although this does not bother me at the moment.
Then for a curious one
=================================================================
2) The question is,
Was it your intention that operators such as "=" be independent of the datastructure?
e.g. in double precission vs extended ?
An example:
==========
In attached "bug1.tar.gz" you will find two directories. case_double
and
case_extended
In both directories there is a file named.
test.bug.pas
Run each of them in turn by CD'ing into the relevant directory... Please compile them in their respective directory if you do not want to use my binaries.
Description of problem:
The example programs is simple and self explanatory. All it does is to evaluate y=1/k with double and extended precission.
Cd to case_double ansd execute test.bug
case_double]$ ./test.bug
k>1
y>1/k
y<=1
k>1
y>1/k
y<=1
y-1/k= 7.4918370118748356E-0017
re= 0.000000000000000E+000 im= 0.000000000000000E+000 case_double]$
Then, Cd to case_extended and execute test.bug
case_extended]$ ./test.bug
k>1
y<= 1/k
k>1
y<= 1/k
y-1/k=-5.4210108624275222E-0020
re= 0.0000000000000000E+0000 im= 0.0000000000000000E+0000 case_extended]$
Note the programs in the two directories are IDENTICAL except for DOUBLE replaced with EXTENDED.
From the output above, you will see that the "=" operator behaves
differently under double and extended precission.
The extended precission example is correct as it yields the following switches k>1 y<= 1/k.
However, the double precission example yields the following switches k>1 y>1/k y<=1 which is not correct as operators such as "=" should be independent of precission used.
=================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gz00000.gz
Type: application/octet-stream
Size: 115683 bytes
Desc: "bug1.tar.gz"
Url : http://localhost/pipermail/lazarus/attachments/20020523/9f926bb9/gz00000.obj
