View mode: basic / threaded / horizontal-split · Log in · Help
November 13, 2012
iota with custom boundary conditions
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?
November 13, 2012
Re: iota with custom boundary conditions
Joseph Rushton Wakeling:

> Any thoughts?

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

Bye,
bearophile
November 13, 2012
Re: iota with custom boundary conditions
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.
November 13, 2012
Re: iota with custom boundary conditions
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.
November 13, 2012
Re: iota with custom boundary conditions
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
November 13, 2012
Re: iota with custom boundary conditions
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?
November 14, 2012
Re: iota with custom boundary conditions
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?
Top | Discussion index | About this forum | D home