A small proposal -- would it be possible, without introducing lots of complications, to permit iota to take a template parameter for boundary conditions similar to that used for std.random.uniform?

So, iota!"[)"() would give the current iota behaviour of including the start point but not the end; iota!"[]" would include beginning and end; iota!"(]" would include the end but not the beginning; and iota!"()" would exclude both beginning and end.

It certainly has application in my own code where e.g. I'd like to be able to use,

     foreach(x; iota!"[]"(0, 1, 0.05)) { .... }

i.e. to foreach across the closed interval [0, 1] with 0.05 step increments.  I can see similar use-cases for the open interval elsewhere, e.g. when I'm dealing with a function that will display asymptotic behaviour at the limit values.

Any thoughts?

Joseph Rushton Wakeling:

> Any thoughts?

In general is it a good idea to use iota with floating point arguments?

Bye,
bearophile

On 11/13/2012 03:08 PM, bearophile wrote:
> In general is it a good idea to use iota with floating point arguments?

I guess you're thinking of the difficulty of making exact equality comparisons between the current value and the end value?  A floating-point iota certainly allows you to represent certain things quite elegantly, although I suppose for safety's sake you might want to use an integer-based iota and calculate FP values from that.

In any case, the usefulness of closed-vs-open boundary conditions isn't limited to FP iota, although it's certainly the main use case.

On Tuesday, 13 November 2012 at 14:20:45 UTC, Joseph Rushton Wakeling wrote:
> On 11/13/2012 03:08 PM, bearophile wrote:
>> In general is it a good idea to use iota with floating point arguments?
>
> I guess you're thinking of the difficulty of making exact equality comparisons between the current value and the end value?  A floating-point iota certainly allows you to represent certain things quite elegantly, although I suppose for safety's sake you might want to use an integer-based iota and calculate FP values from that.
>
> In any case, the usefulness of closed-vs-open boundary conditions isn't limited to FP iota, although it's certainly the main use case.

The only time I could possibly see a use for open-close in iota, is when you want to iterate all the way to T.max.

But I don't think that use-case justifies the change.

monarch_dodra:

> The only time I could possibly see a use for open-close in iota, is when you want to iterate all the way to T.max.

Like when you want to fill an array with all ubytes or all chars. Currently to do this with foreach or iota you need an unsafe cast. This is not good.

Bye,
bearophile

On 11/13/2012 03:43 PM, monarch_dodra wrote:
> The only time I could possibly see a use for open-close in iota, is when you
> want to iterate all the way to T.max.
>
> But I don't think that use-case justifies the change.

Suppose I want to calculate function values across a continuous interval. Obviously an elegant way of doing this is to foreach across the range of an iota that covers the interval with small increment.

However, the function may be asymptotic at either the upper or lower boundary, or both, or none.  So I need to be able to indicate correspondingly whether the upper or lower bounds of the iota should be included or not.

It's maybe not the most important use-case, but if the change can be introduced in a non-breaking way, why not?

On 11/13/2012 04:11 PM, Joseph Rushton Wakeling wrote:
> It's maybe not the most important use-case, but if the change can be introduced
> in a non-breaking way, why not?

Actually, this was probably the main reason I brought it up: _is_ it possible to do this as a non-breaking change?  In principle I'd think so, but then again if someone has actually written something like,

    auto r = iota!(size_t, size_t, size_t)(0, 200, 2);

... then introducing a default form of

    iota(string boundaries = "[)", B, E, S)(B begin, E end, S step)

would break, no?  Nevertheless, is it worth entering as a feature request?