On 9/2/2012 4:40 PM, Andrei Alexandrescu wrote:
> On 9/2/12 10:24 PM, Walter Bright wrote:
>> On 9/2/2012 7:45 AM, Andrei Alexandrescu wrote:
>>> On 9/2/12 4:22 PM, Andrei Alexandrescu wrote:
>>> [snip]
>>>
>>> The alternative would be to simply define these as functions:
>>>
>>> if (a.among("struct", "class", "union")) { ... }
>>> if (b.between(1, 100)) { ... }
>>
>> Is between inclusive or not of the endpoints?
>
> After quite a bit of thought, I think inclusive is the right way.

Then there's no way to specify an empty interval. I suppose with "between" that would not be relevant.

> There are two
> reasons:
>
> 1. Ranges that end in e.g. float.max or int.max would not be expressible if
> bounds were not included.
>
> 2. SQL defines between to include the limits, which sets a precedent.
>
> Ranges are open to the right but I think intervals are quite different.
>
>
> Andrei

On Sunday, September 02, 2012 21:47:13 Walter Bright wrote:
> On 9/2/2012 4:40 PM, Andrei Alexandrescu wrote:
> > On 9/2/12 10:24 PM, Walter Bright wrote:
> >> On 9/2/2012 7:45 AM, Andrei Alexandrescu wrote:
> >>> On 9/2/12 4:22 PM, Andrei Alexandrescu wrote:
> >>> [snip]
> >>> 
> >>> The alternative would be to simply define these as functions:
> >>> 
> >>> if (a.among("struct", "class", "union")) { ... }
> >>> if (b.between(1, 100)) { ... }
> >> 
> >> Is between inclusive or not of the endpoints?
> > 
> > After quite a bit of thought, I think inclusive is the right way.
> 
> Then there's no way to specify an empty interval. I suppose with "between" that would not be relevant.

It could take a std.aglorithm.openRight as its third, parameter, then you could choose to do one or the other. It just becomes a question of which is the default.

Certainly, my natural inclination is to go with having intervals be open on the right, but if you have a choice, it's less of an issue regardless of which is the default.

- Jonathan M Davis

On Monday, 3 September 2012 at 04:56:54 UTC, Jonathan M Davis wrote:
>
> It could take a std.aglorithm.openRight as its third, parameter, then you
> could choose to do one or the other. It just becomes a question of which is
> the default.
>
> Certainly, my natural inclination is to go with having intervals be open on
> the right, but if you have a choice, it's less of an issue regardless of which
> is the default.
>
> - Jonathan M Davis

http://www.boost.org/doc/libs/1_51_0/libs/icl/doc/html/index.html

Recently at work, I was quite pleasantly surprised by the boost solution... it solves a number of problems quite elegantly, different policies for handling overlapping ranges and etc... and found myself wishing for the same in D.

ex.

typedef std::set<string> guests;
interval_map<time, guests> party;
party += make_pair(interval<time>::right_open(time("20:00"), time("22:00")), guests("Mary"));
party += make_pair(interval<time>::right_open(time("21:00"), time("23:00")), guests("Harry"));

// party now contains
[20:00, 21:00)->{"Mary"}
[21:00, 22:00)->{"Harry","Mary"} //guest sets aggregated on overlap
[22:00, 23:00)->{"Harry"}

On 2012-09-02 17:06, Alex Rønne Petersen wrote:

> The argument seems to be that since an array search is O(n) and an AA
> lookup is O(1), this example would be "misleading".

What would it be for this set type?

-- 
/Jacob Carlborg

On 2012-09-02 17:17, Andrei Alexandrescu wrote:

> The difference is in scale and primitives offered. Handful would be
> read-only and limited to the size of its initializer. Its representation
> would take advantage of that.
>
> Anyhow, I think among would be a simpler solution for this all.

This doesn't sound like an approach you would take Andrei :) I would expect you to say something like:

"This isn't general enough, we need a general set container that is fast and efficient enough for this uses cases as well".

-- 
/Jacob Carlborg

On 9/3/12 6:47 AM, Walter Bright wrote:
> On 9/2/2012 4:40 PM, Andrei Alexandrescu wrote:
>> On 9/2/12 10:24 PM, Walter Bright wrote:
>>> On 9/2/2012 7:45 AM, Andrei Alexandrescu wrote:
>>>> On 9/2/12 4:22 PM, Andrei Alexandrescu wrote:
>>>> [snip]
>>>>
>>>> The alternative would be to simply define these as functions:
>>>>
>>>> if (a.among("struct", "class", "union")) { ... }
>>>> if (b.between(1, 100)) { ... }
>>>
>>> Is between inclusive or not of the endpoints?
>>
>> After quite a bit of thought, I think inclusive is the right way.
>
> Then there's no way to specify an empty interval. I suppose with
> "between" that would not be relevant.

Apparently I didn't think enough :o).

Andrei

On 2012-09-02 17:29, Dmitry Olshansky wrote:

> I wouldn't question utility but rather the implementation of the above.
> One thing I'd love to see is thing like
> handful!("struct", "class", "union")
>
> that does pre-process contents at compile time to speed up search.
> In other words it's possible to not only come close to  a series of a ==
> "struct" || a == "class" || a == "union" but surpass it.

Sounds like an enhanced tuple?

> At the very least handful!(a,b,c) can take expression tuple and make
> x in handful!(a,b,c) lower to:
> return x == a || x == b || x == c;
>
> even for run-time variables a, b & c.
>


-- 
/Jacob Carlborg

On 2012-09-02 17:16, Andrei Alexandrescu wrote:

> Iota is a different notion (it has a step).

Yes, but that is optional, making "iota" a more general form of an interval.

-- 
/Jacob Carlborg

On 9/3/12 8:28 AM, Jacob Carlborg wrote:
> On 2012-09-02 17:29, Dmitry Olshansky wrote:
>
>> I wouldn't question utility but rather the implementation of the above.
>> One thing I'd love to see is thing like
>> handful!("struct", "class", "union")
>>
>> that does pre-process contents at compile time to speed up search.
>> In other words it's possible to not only come close to a series of a ==
>> "struct" || a == "class" || a == "union" but surpass it.
>
> Sounds like an enhanced tuple?

Tuple is the representation of an interval but that's where commonality stops.

Andrei

On 9/3/12 8:29 AM, Jacob Carlborg wrote:
> On 2012-09-02 17:16, Andrei Alexandrescu wrote:
>
>> Iota is a different notion (it has a step).
>
> Yes, but that is optional, making "iota" a more general form of an
> interval.

I think in this case the generalization goes the wrong way.

Andrei