floating point literals

[srvaldez]

a feature request then is to have typed literals.

[PascalDragon]

a feature request then is to have typed literals.

No, because you can already type them by typecasting them.

[srvaldez]

well ok, but I am an advocate for unambiguous code AKA pedantic code, why leave something to guesswork?
yes, you can cast constants but in my opinion a simple postfix symbol is easier both to type and to read

[xixixi]

Alternatively, a different exponent marker, as in Lisp:

1e0 - real
1d0 - double
1f0 - single

[PascalDragon]

yes, you can cast constants but in my opinion a simple postfix symbol is easier both to type and to read

There is no need for some kind of postfix symbol, because the type casting already exists. We tend to avoid implementing multiple ways to express the same functionality except when required for compatibility to specific language dialect.

Alternatively, a different exponent marker, as in Lisp:

1e0 - real
1d0 - double
1f0 - single

No, see above.

[explainedd]

The typecast is the most clear (and verbose) solution for a few values.
It is possible to PUSH/POP the $MINFPCONSTPREC for larger code blocks:

Code: Pascal  [Select][+][-]

1. {$MODE DELPHI}
2. program demoFP;
3.  
4. type TestValue = packed record
5.     case uint64 of
6.         0: (doubleRepresentation: double);
7.         1: (UInt64Representation: uint64);
8. end;
9.  
10. var
11.     tv: TestValue;
12.     d: double;
13.  
14. begin
15.     d := 1.0 / 3.0;
16.     tv.doubleRepresentation := d;
17.     writeln('                    single / single :', tv.UInt64Representation);
18.  
19.     d := Double(1.0) / Double(3.0);
20.     tv.doubleRepresentation := d;
21.     writeln('casted to double / casted to double :', tv.UInt64Representation);
22.  
23.     {$IFDEF FPC}{$PUSH}{$MINFPCONSTPREC 64}{$ENDIF}
24.     d := 1.0 / 3.0;
25.     {$IFDEF FPC}{$POP}{$ENDIF}
26.     tv.doubleRepresentation := d;
27.     writeln('                    double / double :', tv.UInt64Representation);
28. end.
29.  

[PascalDragon]

It is possible to PUSH/POP the $MINFPCONSTPREC for larger code blocks:

$MINFPCONSTPREC is not part of the settings that is (re)stored by $PUSH/$POP.

[Thaddy]

It is also hardly documented, but in my view should be a local.

[explainedd]

The documentation seems clear to me.

In Free Pascal Programmer’s Guide:
https://downloads.freepascal.org/fpc/docs-pdf/prog.pdf

$MINFPCONSTPREC is listed under Local directives.

$POP and $PUSH says:
Global settings (search paths etc.) are not saved/restored by this directive.

If I replace {$MINFPCONSTPREC 64} with {$APPTYPE GUI} (a global one), I get the following message:
demo_fp_02.pas(23,25) Warning: Misplaced global compiler switch, ignored

Here is a simple test to check $POP:

Code: Pascal  [Select][+][-]

1. {$MODE DELPHI}
2. program demoFP;
3.  
4. type TestValue = packed record
5.     case byte of
6.         0: (doubleRepresentation: double);
7.         1: (UInt64Representation: uint64);
8. end;
9.  
10. var
11.     tv: TestValue;
12.     d: double;
13.  
14. begin
15.     d := 1.0 / 3.0;
16.     tv.doubleRepresentation := d;
17.     writeln('                    single / single :', tv.UInt64Representation);
18.  
19.     d := Double(1.0) / Double(3.0);
20.     tv.doubleRepresentation := d;
21.     writeln('casted to double / casted to double :', tv.UInt64Representation);
22.  
23.     {$IFDEF FPC}{$PUSH}{$MINFPCONSTPREC 64}{$ENDIF}
24.     d := 1.0 / 3.0;
25.     {$IFDEF FPC}{$POP}{$ENDIF}
26.     tv.doubleRepresentation := d;
27.     writeln('                    double / double :', tv.UInt64Representation);
28.  
29.     d := 1.0 / 3.0;
30.     tv.doubleRepresentation := d;
31.     writeln('Single type again:  single / single :', tv.UInt64Representation);
32. end.
33.  

The results:

                    single / single :4599676419600023552
casted to double / casted to double :4599676419421066581
                    double / double :4599676419421066581
Single type again:  single / single :4599676419421066581


Still double / double.

This gives back the single/single result:

Code: Pascal  [Select][+][-]

1. {$MODE DELPHI}
2. program demoFP;
3.  
4. type TestValue = packed record
5.     case byte of
6.         0: (doubleRepresentation: double);
7.         1: (UInt64Representation: uint64);
8. end;
9.  
10. var
11.     tv: TestValue;
12.     d: double;
13.  
14. begin
15.     d := 1.0 / 3.0;
16.     tv.doubleRepresentation := d;
17.     writeln('                    single / single :', tv.UInt64Representation);
18.  
19.     d := Double(1.0) / Double(3.0);
20.     tv.doubleRepresentation := d;
21.     writeln('casted to double / casted to double :', tv.UInt64Representation);
22.  
23.     {$MINFPCONSTPREC 64}
24.     d := 1.0 / 3.0;
25.     {$MINFPCONSTPREC DEFAULT}
26.     tv.doubleRepresentation := d;
27.     writeln('                    double / double :', tv.UInt64Representation);
28.  
29.     d := 1.0 / 3.0;
30.     tv.doubleRepresentation := d;
31.     writeln('Single type again:  single / single :', tv.UInt64Representation);
32. end.
33.  

Some clarification needed in the documentation.

Thanks PascalDragon

[explainedd]

TRon,

A full list of supported settings by $PUSH / $POP would be nice.
How can I decide if a directive is supported by $PUSH / $POP?

[TRon]

TRon,

A full list of supported settings by $PUSH / $POP would be nice.
How can I decide if a directive is supported by $PUSH / $POP?

Sorry for having removed my post explainedd.

Basically I wrote that the directive only applies to/for declarations. But as explainedd's example shows, that is not entirely true and apparently undocumented

So the question as of which directives are supported by push/pop seem to be a legitimate one. The basic rule is, as I always assumed, for every local directive as documented:

The $PUSH directive saves the current values of all local compiler directives on the settings stack

Perhaps another push/pop related issue ?

[Paolo]

@Kodezwerg

What kind of type is "1.0" from your point of view?
From my point of view it is first of all a float and there it begins with the "Single" type, "1.0" does fit into "Single" so compiler does treat it as such.

and What kind of type is "1" from your point of view?

and then, what is the rule ?

Code: Pascal  [Select][+][-]

1. var
2.   x, y : double;
3. ...
4.   x:=0.1;
5.   y:=1.0/10.0;
6.   if x=y then beep  //<-- never beep
7.  
8.   x:=0.1;
9.   y:=1/10;
10.   if x=y then beep  //<--- beep
11.  
12.  

[fcu]

@Kodezwerg

What kind of type is "1.0" from your point of view?
From my point of view it is first of all a float and there it begins with the "Single" type, "1.0" does fit into "Single" so compiler does treat it as such.

and What kind of type is "1" from your point of view?

and then, what is the rule ?

Code: Pascal  [Select][+][-]

1. var
2.   x, y : double;
3. ...
4.   x:=0.1;
5.   y:=1.0/10.0;
6.   if x=y then beep  //<-- never beep
7.  
8.   x:=0.1;
9.   y:=1/10;
10.   if x=y then beep  //<--- beep
11.  
12.  

seems gcc works the oposit way

Code: C  [Select][+][-]

1. void beep(int i){
2.   printf("Beep %d\n",i);
3. }
4.  
5. double x,y;
6. int main()
7. {
8.     x = 0.1;
9.     y = 1.0/10.0;
10.  
11.     if (x == y) beep(1); // beep
12.  
13.     x= 0.1;
14.     y= 1/10;
15.  
16.     if (x == y) beep(2); // no beep
17.  
18.     return 0;
19. }
20.  
21.  

[Paolo]

I really don't understand why "1" is considered different from "1.0". I like the suggestion to heve a way to size the literals, like suggested by xixixi and others.

[nanobit]

and then, what is the rule ?

Code: Pascal  [Select][+][-]

1. var
2.   x, y : double;
3. ...
4.   x:=0.1;
5.   y:=1.0/10.0;
6.   if x=y then beep  //<-- never beep
7.  
8.   x:=0.1;
9.   y:=1/10;
10.   if x=y then beep  //<--- beep
11.  
12.  

I don't know the example's settings, but one explanation could be:
Both operands (1.0, 10.0) are single-type (under {$MINFPCONSTPREC default})
which leads to single-precision operation under {$EXCESSPRECISION off} at compile time.
So the resulting y is less precise than x. This is how FPC currently works and looks to be improvable.
(1/10) has higher precision which could have different reasons.