"strtr" <strtr@spam.com> wrote in message news:hjd6t1$beh$1@digitalmars.com...
> This may be is a very basic question, but is there a way to let me omit a repeating variable when doing multiple boolean operations?
>
> if ( var == a || var == b || var == c || var == d)
> if ( var == (a || b || c || d) )

I do this:

-------------------------
import tango.core.Array;

void main()
{
    if( [3, 5, 6, 12].contains(7) )
    {
    }
}
-------------------------

There's probably a phobos equivilent, too.

Alhough, I would much prefer what other people mentioned about having "in" refer to the values of a collection rather than the keys. But I've been using the above as a substitute.

On 01/26/2010 01:02 AM, Nick Sabalausky wrote:
> "strtr"<strtr@spam.com>  wrote in message
> news:hjd6t1$beh$1@digitalmars.com...
>> This may be is a very basic question, but is there a way to let me omit a
>> repeating variable when doing multiple boolean operations?
>>
>> if ( var == a || var == b || var == c || var == d)
>> if ( var == (a || b || c || d) )
>
> I do this:
>
> -------------------------
> import tango.core.Array;
>
> void main()
> {
>      if( [3, 5, 6, 12].contains(7) )
>      {
>      }
> }
> -------------------------
>
> There's probably a phobos equivilent, too.
>
> Alhough, I would much prefer what other people mentioned about having "in"
> refer to the values of a collection rather than the keys. But I've been
> using the above as a substitute.
>
>
I think in should work for keys in an associative array and for values in a regular array.

This is how it works in python.

On 22/01/10 21:55, strtr wrote:
> This may be is a very basic question, but is there a way to let me omit a repeating variable when doing multiple boolean operations?
>
> if ( var == a || var == b || var == c || var == d)
> if ( var == (a || b || c || d) )

/**
 * Untested code, it works something like this though
 * Find tools at:
 *  http://dsource.org/projects/scrapple/browser/trunk/tools/tools
 */

import tools.base;

void main()
{
  T var, a, b, c, d;
  ...
  if ( var == a /or/ b /or/ c /or/ d )
  {
    /**
     * The same as:
     * ----
     * if ( var == a || var == b || var == c || var == d)
     * {
     *    ...
     * }
     */
  }
}

Pelle MÃ¥nsson:
> I think in should work for keys in an associative array and for values
> in a regular array.
> This is how it works in python.

opIn_r for normal arrays is something very natural. One of the very few persons that doesn't like it is Walter. Maybe I can create a small poll to see how many agree that this is useful, semantically clean, and a really common thing to do. This may change his mind or not.
Time ago I have listed few things that are both very handy and small, but Walter has ignored them. I think he doesn't believe in "programming in the small" much.

Bye,
bearophile

"Pelle Månsson" <pelle.mansson@gmail.com> wrote in message news:hjmmod$1iok$1@digitalmars.com...
>
> I think in should work for keys in an associative array and for values in a regular array.
>
> This is how it works in python.

Aside from that being how Python does it, why do you see that as preferable? I see both arrays and associative arrays as things that map an input value to an output value. The only significant differences are the implementation details, and the fact that regular arrays are more restrictive in their sets of valid inputs (must be integers, must start with 0, and must all be consecutive values). So having a single syntax work on the outputs for regular arrays, but then on the inputs for AAs, seems highly inconsistent and error-prone to me.

Hello Nick,

> "Pelle Månsson" <pelle.mansson@gmail.com> wrote in message
> news:hjmmod$1iok$1@digitalmars.com...
> 
>> I think in should work for keys in an associative array and for
>> values in a regular array.
>> 
>> This is how it works in python.
>> 
> Aside from that being how Python does it, why do you see that as
> preferable? I see both arrays and associative arrays as things that
> map an input value to an output value. The only significant
> differences are the implementation details, and the fact that regular
> arrays are more restrictive in their sets of valid inputs (must be
> integers, must start with 0, and must all be consecutive values). So
> having a single syntax work on the outputs for regular arrays, but
> then on the inputs for AAs, seems highly inconsistent and error-prone
> to me.

I think this is one of the few cases where the strictly logical choice is not the way anyone expect things to work.

That said however, it might make a difference in template code

void fn(T)(T t, T u, int i)
{
   if(auto x = i in t) u[i] = *x; }

--

<IXOYE><

Nick Sabalausky:
> Aside from that being how Python does it, why do you see that as preferable?

Because:
1) linear searches in an array are damn common. I don't remember the results of my benchmarks, but until your integer arrays is quite longer than 30-50 items, performing a linear search is faster than a lookup in an AA, on DMD. On Tango this number is probably 70% higher
1b) In Python if you perform a "foo" in "barfoo" the language doesn't perform a linear search, it uses a much smarter search that has a complexity lower than the product of the two lengths, using a custom algorithm. So in D you can use the same syntax to search for substrings/subarrays. Where such smarter search is not possible, D can use a naive search.
2) It's really handy. I use isIn(item, items) to search on arrays in D, but having a item in items is nicer.
3) You can use the same syntax to search into anything that's lazily iterable too (a Range). This is very handy.


> So having a single syntax work on the outputs for regular arrays, but then on the inputs for AAs, seems highly inconsistent and error-prone to me.

I have followed many Python newbies personally, I am following the Python newsgroups, and I have programmed for years in Python, and while I have seen many different kinds of bugs, I have not seen a significant amount of bugs in this. Python programmers just learn that dicts and lists are a little different in this regard. At the same way they learn that a set and a dict are different data structures, with different capabilities and usages.

Why don't you start using Python, I think in 5 days you can tell that's easy to not confuse the following usages:
5 in {5:1, 2:2, 5:3}
5 in [1, 2, 5]
"5" in "125"
"25" in "125"

Bye,
bearophile

On Tue, Jan 26, 2010 at 1:21 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Nick Sabalausky:
>> Aside from that being how Python does it, why do you see that as preferable?
>
> Because:
> 1) linear searches in an array are damn common. I don't remember the results of my benchmarks, but until your integer arrays is quite longer than 30-50 items, performing a linear search is faster than a lookup in an AA, on DMD. On Tango this number is probably 70% higher
> 1b) In Python if you perform a "foo" in "barfoo" the language doesn't perform a linear search, it uses a much smarter search that has a complexity lower than the product of the two lengths, using a custom algorithm. So in D you can use the same syntax to search for substrings/subarrays. Where such smarter search is not possible, D can use a naive search.
> 2) It's really handy. I use isIn(item, items) to search on arrays in D, but having a item in items is nicer.
> 3) You can use the same syntax to search into anything that's lazily iterable too (a Range). This is very handy.
>
>
>> So having a single syntax work on the outputs for
>> regular arrays, but then on the inputs for AAs, seems highly inconsistent
>> and error-prone to me.
>
> I have followed many Python newbies personally, I am following the Python newsgroups, and I have programmed for years in Python, and while I have seen many different kinds of bugs, I have not seen a significant amount of bugs in this. Python programmers just learn that dicts and lists are a little different in this regard. At the same way they learn that a set and a dict are different data structures, with different capabilities and usages.

It's not even really  inconsistent if you just think about these data
structures in terms of function rather than form.
An array is often used as a simple set of things.  "O in Array" means
"is O in that set of things"
An AA is a set of things that also have some associated data.  "O in
AA" means "is O in that set of things" (not the ancillary data)
If you have an actual "set" data structure for containing a set of of
things, then "O in Set" means, again, "is O in that set of things".
(In fact the closest thing D has to a built-in set type is an AA with
"don't care" associated data, reinforcing the notion of AA as a set
plus extra data.)

--bb

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:hjnmdl$166s$1@digitalmars.com...
> Nick Sabalausky:
>> Aside from that being how Python does it, why do you see that as preferable?
>
> Because:
> 1) linear searches in an array are damn common. I don't remember the
> results of my benchmarks, but until your integer arrays is quite longer
> than 30-50 items, performing a linear search is faster than a lookup in an
> AA, on DMD. On Tango this number is probably 70% higher
> 1b) In Python if you perform a "foo" in "barfoo" the language doesn't
> perform a linear search, it uses a much smarter search that has a
> complexity lower than the product of the two lengths, using a custom
> algorithm. So in D you can use the same syntax to search for
> substrings/subarrays. Where such smarter search is not possible, D can use
> a naive search.
> 2) It's really handy. I use isIn(item, items) to search on arrays in D,
> but having a item in items is nicer.
> 3) You can use the same syntax to search into anything that's lazily
> iterable too (a Range). This is very handy.
>

I don't see how any of that argues against the idea of making "in" always operate on the elements and having a different method for checking the keys. Can you be more clear on that point?

>
>> So having a single syntax work on the outputs for
>> regular arrays, but then on the inputs for AAs, seems highly inconsistent
>> and error-prone to me.
>
> I have followed many Python newbies personally, I am following the Python newsgroups, and I have programmed for years in Python, and while I have seen many different kinds of bugs, I have not seen a significant amount of bugs in this. Python programmers just learn that dicts and lists are a little different in this regard. At the same way they learn that a set and a dict are different data structures, with different capabilities and usages.
>
> Why don't you start using Python, I think in 5 days you can tell that's
> easy to not confuse the following usages:
> 5 in {5:1, 2:2, 5:3}
> 5 in [1, 2, 5]
> "5" in "125"
> "25" in "125"
>

I'm sure I could, but that doesn't change anything. I've used a lot of languages with lots of poorly-designed features, and I've always been able to deal with the problems in those poorly-designed features. But just because I can get used to dealing with them doesn't mean they're not poorly-designed or that I wouldn't prefer or be better off with something different. (And for the record, I have used a bit of Python here and there. Still not particularly happy with it.)

Ex: All of us get along just fine with "if(is())", but it's still widely
considered a design in need of fixing.
Ex: C/C++ programmers get by with its system of #include and header files
just fine. But obviously it still had plenty of worthwhile room for
improvement.

Nick Sabalausky:

>I don't see how any of that argues against the idea of making "in" always operate on the elements and having a different method for checking the keys.<

I have already done my best with those words, so... :-)

AA elements are its keys, that are a set. In Python3 if you have a dict named foo, then foo.keys() returns something that's very like a set view. And foo itself acts like a set (you can iterate on the items of this set, etc).
The values are the things associated to that set of elements.
So maybe your are seeing associative arrays as arrays, while in Python they are seen as sets with associated values :-) And seeing them as a special kind of set is better, because it gives you some handy syntax back, that I have shown you. Maybe we can change their name in D and call them "Associative Sets" :o)


>I'm sure I could, but that doesn't change anything. I've used a lot of languages with lots of poorly-designed features, and I've always been able to deal with the problems in those poorly-designed features. But just because I can get used to dealing with them doesn't mean they're not poorly-designed or that I wouldn't prefer or be better off with something different.<

What kind of problems has caused the "in" in your Python programs?


>Ex: All of us get along just fine with "if(is())", but it's still widely considered a design in need of fixing. Ex: C/C++ programmers get by with its system of #include and header files just fine. But obviously it still had plenty of worthwhile room for improvement.<

You can find several people (me, for example) that think of those are warts or badly designed things (or things designed for much less powerful computers, #include). While if you take a sample of 50000 Python and Ruby programmers you will not find many of them that think that "in" is badly designed  (or not very handy) in Python. If you search on the web you can find pages that list some Python warts, you will not find "in" among them. You can find things like:
class Foo:
  def __init__(self, x=[]): ...
Where people say that [] causes problems or they don't like that "self" as first argument, etc.

Probably I am not going to change your mind (and probably Walter's, he probably doesn't even reads the d.learn group), so this discussion is probably mostly academic :-)

Bye,
bearophile