is this a bug? For H in [a,b,c]

[mtanner]

When I code
var H:double;
For H in [0.001, (1/2), (7/10), 0.999] do ShowMessage(FloatToStr(H));

then the numbers displayed are as you would expect: 0.001, 0.5, 0.7, 0.999

But when I code
For H in [0.001, 0.5, 0.7, 0.999] then ShowMessage(FloatToStr(H));

I see : 0.001, Nan, 0.7, 0.999

[howardpc]

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

1. program Project1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   SysUtils;
7.  
8.   var
9.     arr: array of Double = (0.001, 1/2, 7/10, 0.999);
10.     arr2: array of Double = (0.001, 0.5, 0.7, 0.999);
11.     H: Double;
12.  
13. begin
14.  for H in arr do
15.    WriteLn(FloatToStr(H));
16.  
17.  for H in arr2 do
18.    WriteLn(FloatToStr(H));
19.  ReadLn;
20. end.

The above runs as expected.
I think your [] syntax is not interpreted as you expect.
Do you use {$mode Delphi}?

[mtanner]

When I code

var Hlist:array of double = (0.001, 0.5.0.7.0.999);
For H in HList do ShowMessage(FloatToStr(H));
then the numbers display as expected.

But with
For H in [0.001, 0.5, 0.7, 0.999] do ShowMessage(FloatToStr(H));
then the 0.5 comes out as Nan.

The syntax
For H in (0.001,0.5,0.7,0.999) do ...
is not accepted.

I am not using {$mode Delphi} as far as I am aware, defintely not explicitly.

I am just very puzzled. Why should 0.5 give Nan while 0.7 gives 0.7?

[Zvoni]

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

1. program Project1;
2. Uses SysUtils;
3. Var
4.   H:Double;
5. begin
6.   For H in [0.001, 0.5, 0.7, 0.999] Do Writeln(H.ToString);
7. end.
8.  

Result (German locale):
0,001
0
0,7
0,999

There is something rotten in Denmark......

[Handoko]

The NAN issue happened on me too, I guess because I'm using Lazarus and doing it in GUI (don't use Writeln).

[Zvoni]

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

1. program Project1;
2. Uses SysUtils;
3. Var
4.   H:Double;
5.   i:Integer;
6.   arr2: array of Double = (0.001, 0.5, 0.7, 0.999);
7. begin
8.   For H In arr2 Do Writeln(H.ToString);  
9.   For i:=Low(arr2) To High(arr2) Do Writeln(arr2[i].ToString);
10. end.

Returns:
0,001
0,5
0,7
0,999
0,001
0,5
0,7
0,999

Yep, seems to be the In-operator in combination with a "direct" Array (Not in a variable)

[AlexTP]

Reported to GitLab, https://gitlab.com/freepascal.org/fpc/source/-/issues/39656

[Zvoni]

It's getting weird....
Replace the Double-Type with "Extended"
For the 0.5 i'm getting
3,85284689429794E-4942
when i Writeln it.....

[PascalDragon]

Fixed in 815734c47a4afe7d07083757f9ed6df233762abb.

[mtanner]

Bit of a shame to have issues line this with the "in" operator. I developed my (sometimes bad) Pascal coding habits with the original Turbo Pascal, which (I think) did not have the IN operator. Having recently stumbled across an article on the net about FPC features I discovered the in operator, and have found it extremely useful.  Like discovering a great new DIY tool, only to find it breaks very easily when you actually use it.

[AlexTP]

When you see bugs like these, just report them on the forum. Devs missed it.

[marcov]

Fixed in 815734c47a4afe7d07083757f9ed6df233762abb.

Merged?

[PascalDragon]

Bit of a shame to have issues line this with the "in" operator. I developed my (sometimes bad) Pascal coding habits with the original Turbo Pascal, which (I think) did not have the IN operator. Having recently stumbled across an article on the net about FPC features I discovered the in operator, and have found it extremely useful.  Like discovering a great new DIY tool, only to find it breaks very easily when you actually use it.

You are mixing two different things here. Pascal has an in-operator since it has sets which it has from its beginnings.
What was used here is not the in-operator, but the for … in-loop. These are totally different things. Also this functionality didn't break, because the ability to use an literal array as the expression to be iterated on the right side of the in was only added with 3.2.0. And there this use case simply wasn't handled, because literal arrays were mainly tested with assignments and concatenation, but not with for … in, thus this issue simply slipped past and no preexisting code broke with this.

When you see bugs like these, just report them on the forum. Devs missed it.

No, if you see bugs like these, then report them on the issue tracker, not the forum. Also this issue was known for a longer time already, just as always the point is to find the time and yesterday I already wanted to tackle the other bug with the string array and there just happened to be this one as well (which pointed me in the right direction to solve this).

Fixed in 815734c47a4afe7d07083757f9ed6df233762abb.

Merged?

Now it is. I wanted to wait for the testsuite results for other platforms.