On 9/3/12 8:31 AM, Andrei Alexandrescu wrote:
> 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.

Rats, sorry (no coffee yet). It was about "handful" and I was at "interval". I can see how an inclusion for tuple would make sense, even in the current notion - i.e. we could add "in" to Tuple and get to write:

if (x in tuple("struct", "class", "union")) { ... }


Andrei

On Mon, 03 Sep 2012 08:29:34 +0200, Jacob Carlborg <doob@me.com> 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.

It's not optional, it has a default value.

-- 
Simen

On Mon, 03 Sep 2012 08:34:33 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> we could add "in" to Tuple and get to write:
>
> if (x in tuple("struct", "class", "union")) { ... }

if (x in tuple(1, new Foo(), "baa!") { ... }

Just kidding.


tuple has the inconvenience that we don't know the values at compile-time.
If we did, we could take advantage of some cleverer tricks for fast
comparison. At the same time, it's a neat and logical solution.


-- 
Simen

On 02/09/12 22:42, SomeDude wrote:
> On Sunday, 2 September 2012 at 15:09:50 UTC, deadalnix wrote:
>> Le 02/09/2012 16:51, Jacob Carlborg a écrit :
>>> I really don't like the name "handful". What would be the difference
>>> compared to a regular set container? To me it sounds like we should have
>>> a standard set container in Phobos, std.container.set.
>>>
>>
>> +1, and we are back to the allocator design.
>
> +2 on the basis of typical "real world" (if I may says so) usage. It
> calls for a set container, both mutable and immutable.
>
> For a "handful" of values (say 5 or less), I'm not even sure the O(1)
> method is faster than the O(n) one.
>
> As for the intervals, I suppose one would have to define open intervals,
> because I think they would be much more useful than closed ones when the
> intervals are contiguous (in particular with floats/doubles).
> One must be able to translate x0 <= x < x1 in intervals else they are
> practically useless for anything else than integers and other discrete
> values.

But practically everything on a computer uses discrete values. Floating point numbers always do, for example; they are *not* mathematical real numbers with infinite precision.
For floats and doubles, any non-empty interval can be expressed using closed intervals.

Use the nextUp() and nextDown() to convert between open and closed intervals.

[ x .. y ] == ( nextDown(x) .. nextUp(y) )
( x .. y ) == [ nextUp(x) .. nextDown(y) ]


In general:

Fully closed interval: cannot express an empty interval.
Fully open interval: cannot express a maximum-sized interval. Empty intervals can be expressed but not uniquely.
Half-open: not closed under negation.

Either of the first two are reasonable choices for arithmetic applications. The third is broken for anything that allows negative values.

Le 3 sept. 2012 08:42, "Simen Kjaeraas" <simen.kjaras@gmail.com> a écrit :
>
> On Mon, 03 Sep 2012 08:34:33 +0200, Andrei Alexandrescu <
SeeWebsiteForEmail@erdani.org> wrote:
>
>> we could add "in" to Tuple and get to write:
>>
>> if (x in tuple("struct", "class", "union")) { ... }
>
>
> if (x in tuple(1, new Foo(), "baa!") { ... }
>
> Just kidding.

I was about to say the same, except not kidding :)
I can see value in having this: finding if a value in a struct '.tupleof',
for example. Or finding a range among a tuple of ranges, all of subtly
different types and that cannot be put in an array.
I was imagining 'in' to return a boolean, but if you need it to return a
possible value, then it can return a pointer to CommonType!(Ts) if this
exists, or a pointer to Algebraic!(Types...).

Of course, that would also be a interesting place to use an Option!(T) type.

> tuple has the inconvenience that we don't know the values at compile-time. If we did, we could take advantage of some cleverer tricks for fast comparison. At the same time, it's a neat and logical solution.

We can try to get a fully-CT version, using template arguments, but I'm not sure that would be interesting.

People here are talking about sets, but does Andrei really have sets in mind? That has consequences if you want 'in' to return a pointer to a value.

On 9/3/12 10:27 AM, Philippe Sigaud wrote:
> People here are talking about sets, but does Andrei really have sets in
> mind? That has consequences if you want 'in' to return a pointer to a value.

I wanted to define a couple of simple convenience functions. It seems we've headed into a paralysis of analysis.

Andrei

On Monday, 3 September 2012 at 09:01:37 UTC, Andrei Alexandrescu wrote:
> On 9/3/12 10:27 AM, Philippe Sigaud wrote:
>> People here are talking about sets, but does Andrei really have sets in
>> mind? That has consequences if you want 'in' to return a pointer to a value.
>
> I wanted to define a couple of simple convenience functions. It seems we've headed into a paralysis of analysis.
>
> Andrei

I would advocate using, a < x < b, this trivially addresses open/closed intervals etc.

I disagree with the porting from other languages argument... comparing bool with < > is not a common occurring pattern, and even if there is such code in the wild, many coding standards would force the use of () if using such an expression anyway... so the porting issues would be minimal.

On 9/3/12 11:37 AM, Sven Torvinger wrote:
> On Monday, 3 September 2012 at 09:01:37 UTC, Andrei Alexandrescu wrote:
>> On 9/3/12 10:27 AM, Philippe Sigaud wrote:
>>> People here are talking about sets, but does Andrei really have sets in
>>> mind? That has consequences if you want 'in' to return a pointer to a
>>> value.
>>
>> I wanted to define a couple of simple convenience functions. It seems
>> we've headed into a paralysis of analysis.
>>
>> Andrei
>
> I would advocate using, a < x < b, this trivially addresses open/closed
> intervals etc.
>
> I disagree with the porting from other languages argument... comparing
> bool with < > is not a common occurring pattern, and even if there is
> such code in the wild, many coding standards would force the use of ()
> if using such an expression anyway... so the porting issues would be
> minimal.

It's a sensible argument. What about "among"?

Andrei

On Monday, 3 September 2012 at 10:42:34 UTC, Andrei Alexandrescu wrote:
>> I would advocate using, a < x < b, this trivially addresses open/closed
>> intervals etc.
>>
>> I disagree with the porting from other languages argument... comparing
>> bool with < > is not a common occurring pattern, and even if there is
>> such code in the wild, many coding standards would force the use of ()
>> if using such an expression anyway... so the porting issues would be
>> minimal.
>
> It's a sensible argument. What about "among"?
>
> Andrei

Since 'among' only is concerned with equality it doesn't suffer from the open/closed interval complication... thus in this case, the simplest solution is the best imho... 'in' sugar would not add much to the readability.

if (a.among("struct", "class", "union")) { ... }

On Monday, 3 September 2012 at 11:20:27 UTC, Sven Torvinger wrote:
> if (a.among("struct", "class", "union")) { ... }

Wouldn't that rather be a.among!("struct", "class", "union")? If the string is not known at compile-time, I'd prefer to focus on optimizing something along the lines of ["struct", "class", "union"].canFind(a) (something similar is actually a quite common idiom in Ruby).

David