Re: Bug or feature? iota has different semantics for integer and float arguments

[Arredondo via Digitalmars-d-learn]

On Saturday, 7 January 2023 at 02:31:14 UTC, Ali Çehreli wrote:

On 1/6/23 17:50, Arredondo wrote:

> Would anyone volunteer to file a bug report?

Me! Me! :)

  https://issues.dlang.org/show_bug.cgi?id=23604

Ali


Thanks a lot :D

Arredondo.

Re: Bug or feature? iota has different semantics for integer and float arguments

[Ali Çehreli via Digitalmars-d-learn]

On 1/6/23 17:50, Arredondo wrote:

> Would anyone volunteer to file a bug report?

Me! Me! :)

  https://issues.dlang.org/show_bug.cgi?id=23604

Ali

Re: Bug or feature? iota has different semantics for integer and float arguments

[Arredondo via Digitalmars-d-learn]

On Saturday, 7 January 2023 at 00:52:20 UTC, Ali Çehreli wrote:
Although that difference is a bug, iota does have a special 
floating point implementation to prevent the accumulation of 
floating point errors.


Thank you for this clarification Ali. I appreciate the fact that 
there is a specialized implementation for float types in an 
attempt to mitigate error accumulation.


After posting my previous message I became convinced that the 
behavior I was seeing was indeed a bug. The specialized fp 
implementation simply does not conform to the semantics specified 
in the documentation: "If begin < end && step < 0 or begin > end 
&& step > 0 or begin == end, then an empty range is returned."


The culprit is this assert in the `in` block of the fp 
implementation:


```
assert((end - begin) / step >= 0, "iota: incorrect startup 
parameters");

```

This effectively prevents iota from ever returning an empty 
range. Git blame points to a commit from March 2015. It's 
unbelievable to me this hasn't been fixed in almost 8 years.


Would anyone volunteer to file a bug report? I attempted to do it 
myself but I would need to create an account in the Issue 
Tracking System, and apparently it doesn't accept gmail addresses 
anymore? (facepalm).


Arredondo.

Re: Bug or feature? iota has different semantics for integer and float arguments

[Ali Çehreli via Digitalmars-d-learn]

On 1/6/23 15:23, Arredondo wrote:

> then you get an exception (incorrect startup parameters).

Although that difference is a bug, iota does have a special floating 
point implementation to prevent the accumulation of floating point 
errors. I mention it as item 4 here:


  https://www.youtube.com/watch?v=gwUcngTmKhg&t=634s

Briefly, iota's regular popFront() is a trivial

  front += step

but it is

  ++n

for floating types so that front can be

  begin + (n * step)

for them.

The iota discussion starts at an earlier point in the video here:

  https://www.youtube.com/watch?v=gwUcngTmKhg&t=558s

Ali

Bug or feature? iota has different semantics for integer and float arguments

[Arredondo via Digitalmars-d-learn]

Consider:

```
import std.range.iota;
auto r = iota(5, 0);
```

`r` is an empty range, as it should be. But if you call:

```
auto r = iota(5.0, 0);
```

then you get an exception (incorrect startup parameters).

This was unexpected, and a pain to debug. What is the rationale 
behind iota having different semantics depending on whether the 
arguments are floats or not?


Arredondo.