Can I ask what determines the precision of floating point calculations are done in? It seems that fpc treats (for example, with J declared as integer)

1/sqrt(J+1.0) as single

but

1/sqrt(J+1) as double

which seems counter-intuitive. In FORTRAN I can force double precision evaluation with sqrt(J+1.0D0) but there is no equivalent idea of a double constant in Pascal.

Colin

In 2.1.2 and 2.2, both will be evaluated as single (except on 80x87, because it is not possible to tell the 80x87 to perform a particular calculation using only single/double precision).

which seems counter-intuitive. In FORTRAN I can force double precision evaluation with sqrt(J+1.0D0) but there is no equivalent idea of a double constant in Pascal.

The Pascal equivalent is sqrt(j+double(1.0)).

Jonas

The current SVN (which is the only one I am using at the moment) does give the results at different precisions as shown for x86_64 and PPC - I don't know if that should be considered as a bug. (I understand that the older 386 architecture will normally use double or extended all the time).

Having said that, for numerical programming if double is wanted, the evaluation as double in the absence of specific precision information is actually desirable, and avoids some hard to find errors. Values like Sqrt(2) are common, which I should presumably write as Sqrt(Double(2)) to be sure I don't loose precision. It came up because my application (which requires double rather than single accuracy) was giving slightly different results for different architectures. I have now gone through and fixed the differences I can find, and the results are now the same, but it is difficult to be sure I have caught all the problem areas.

Is there some way of optionally making double the default for constants (rather than single) as a way of avoiding these errors?

Colin

Ah, yes: the j+1 is evaluated (obviously) as integer, and then it's the overloading mechanism that jumps in to decide whether sqrt (single) or sqrt(double) should be picked. I guess that one simply picks the one with the most precision if there is no exact match and you pass an integer argument.

In case of j+1.0, 1.0 is a single, so j+1.0 also becomes a single and since there is an sqrt(single), the exact match is picked instead.

(I understand that the older 386 architecture will normally use double or extended all the time).

Indeed.

Please file a bug report/feature request for this. The current behaviour is needed for Delphi compatibility, and for avoiding wrong precision loss warnings like in
http://www.freepascal.org/mantis/view.php?id=7179

Jonas

I have filed the feature request at
<http://www.freepascal.org/mantis/view.php?id=8678>

Having looked at 7179 would the behavior I want be obtained if we had the option just to treat 1.0 as Double rather than Single?

Colin