www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 'in' for arrays?

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
I keep wanting to say
   if (val in somearray) {
   }

but 'in' doesn't work for arrays...  Is there any reason why not?
Basically I just expect it to do something like this function (untested, 
modified from a similar function in Cashew):

T* item_in (T) (T[] haystack, T cmp)
{
   foreach (index, inout needle; haystack) {
     if (needle==cmp) {
       return &needle;
     }
   }
   return null;
}

I.e. I just expect it to do a plain old linear search through the list, 
nothing fancy, but it would be handy.

--bb
Dec 05 2006
next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Bill Baxter wrote:

 I keep wanting to say
   if (val in somearray) {
   }


It makes sense to make "in" behave as if an int[] is a int[int], but the 
problem is that "in" for normal arrays is O(n), slow. If you need to 
search the array, you probably should have been using another container 
in the first place.

My philosophy is always that CPU-expensive actions should also appear as 
such in code. A small "in" that actual does a linear search might seem a 
like a good idea, but people should be discouraged from using it.

L.
Dec 06 2006
prev sibling next sibling parent reply Egor Starostin <egorst gmail.com> writes:
 I keep wanting to say
    if (val in somearray) {
    }


Me too.

For example, in Python I can write

if val in ('off','disable','no')

and in D I have to write

if (val == "off" || val == "disable" || val == "no")

which is less readable (to me, at least).


--
Egor
Dec 06 2006
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Egor Starostin wrote:

 I keep wanting to say
    if (val in somearray) {
    }


 Me too.
 
 For example, in Python I can write
 
 if val in ('off','disable','no')
 
 and in D I have to write
 
 if (val == "off" || val == "disable" || val == "no")
 
 which is less readable (to me, at least).
 
 
 --
 Egor


Yep.  That's the kind of usage case I have in mind.

About "it's expensive but it doesn't look expensive"...
Expensive is all relative.  If you tend to have lists with tens or even 
hundreds of elements in them then a linear search is a perfectly 
reasonable way to do it.  And in terms of "looks inexpensive", well to 
me   (val in somearray) looks exactly like it's going to do a linear 
search.  What else *could* it do when handed a general array?

--bb
Dec 06 2006
prev sibling next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Egor Starostin wrote:

 I keep wanting to say
    if (val in somearray) {
    }


 Me too.
 
 For example, in Python I can write
 
 if val in ('off','disable','no')


OK, granted, if (val in ["off","disable","no"]) does look cool, but a 
switch(val) would still be faster (uses binary search if I'm not mistaken).

Maybe D should get an alternative "if" for this construct:

switch(val) {
   case "off","disable","no":
      // code here
   default:
      break;
}

Anyway, supporting "in" for normal arrays has my vote. In my post I just 
mentioned a possible concern.

L.
Dec 06 2006
parent reply Alexander Panek <a.panek brainsware.org> writes:
Lionello Lunesu wrote:

 Egor Starostin wrote:

 I keep wanting to say
    if (val in somearray) {
    }


 Me too.

 For example, in Python I can write

 if val in ('off','disable','no')


 
 OK, granted, if (val in ["off","disable","no"]) does look cool, but a 
 switch(val) would still be faster (uses binary search if I'm not mistaken).
 
 Maybe D should get an alternative "if" for this construct:
 
 switch(val) {
   case "off","disable","no":
      // code here
   default:
      break;
 }


May I ask in what way this is different from:

switch ( val ) {
     case "off":
     case "disable":
     case "no":
         // code here
         break;
}

?


 
 Anyway, supporting "in" for normal arrays has my vote. In my post I just 
 mentioned a possible concern.
 
 L.


Kind regards,
Alex
Dec 06 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Alexander Panek wrote:

 Lionello Lunesu wrote:

 switch(val) {
   case "off","disable","no":
      // code here
   default:
      break;
 }


 May I ask in what way this is different from:
 
 switch ( val ) {
     case "off":
     case "disable":
     case "no":
         // code here
         break;
 }


case x,y: is the same as case x: case y:
Apart from that, if you don't provide a 'default' statement, D inserts 
one with assert(0), meaning that your code would trip if val were 
anything other than those 3 mentioned cases.

L.
Dec 06 2006
parent reply Alexander Panek <a.panek brainsware.org> writes:
Lionello Lunesu wrote:

 Alexander Panek wrote:

 Lionello Lunesu wrote:

 switch(val) {
   case "off","disable","no":
      // code here
   default:
      break;
 }


 May I ask in what way this is different from:

 switch ( val ) {
     case "off":
     case "disable":
     case "no":
         // code here
         break;
 }


 
 case x,y: is the same as case x: case y:
 Apart from that, if you don't provide a 'default' statement, D inserts 
 one with assert(0), meaning that your code would trip if val were 
 anything other than those 3 mentioned cases.
 
 L.


Yea..I've seen that I forgot the default: break; after replying.. :P
Dec 06 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Alexander Panek wrote:

 Lionello Lunesu wrote:

 Alexander Panek wrote:

 Lionello Lunesu wrote:

 switch(val) {
   case "off","disable","no":
      // code here
   default:
      break;
 }


 May I ask in what way this is different from:

 switch ( val ) {
     case "off":
     case "disable":
     case "no":
         // code here
         break;
 }


 case x,y: is the same as case x: case y:
 Apart from that, if you don't provide a 'default' statement, D inserts 
 one with assert(0), meaning that your code would trip if val were 
 anything other than those 3 mentioned cases.

 L.


 
 Yea..I've seen that I forgot the default: break; after replying.. :P


And you're very likely to forget it when writing code ..
Dec 06 2006
parent Alexander Panek <a.panek brainsware.org> writes:
Hasan Aljudy wrote:

 
 
 Alexander Panek wrote:

 Lionello Lunesu wrote:

 Alexander Panek wrote:

 Lionello Lunesu wrote:

 switch(val) {
   case "off","disable","no":
      // code here
   default:
      break;
 }


 May I ask in what way this is different from:

 switch ( val ) {
     case "off":
     case "disable":
     case "no":
         // code here
         break;
 }


 case x,y: is the same as case x: case y:
 Apart from that, if you don't provide a 'default' statement, D 
 inserts one with assert(0), meaning that your code would trip if val 
 were anything other than those 3 mentioned cases.

 L.


 Yea..I've seen that I forgot the default: break; after replying.. :P


 
 And you're very likely to forget it when writing code ..


I usually don't forget it..actually. But that's just me. ;)
(In this case lack of time prevented any re-reading :O )
Dec 06 2006
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Egor Starostin" <egorst gmail.com> wrote in message 
news:el5vpc$9nt$1 digitaldaemon.com...

 Me too.

 For example, in Python I can write

 if val in ('off','disable','no')

 and in D I have to write

 if (val == "off" || val == "disable" || val == "no")

 which is less readable (to me, at least).


struct _Tuple(T...)
{
 bool opIn_r(U)(U value)
 {
  foreach(val; T)
  {
   static if(is(typeof(val) : U))
   {
    if(val == value)
     return true;
   }
  }

  return false;
 }
}

template Tuple(T...)
{
 const _Tuple!(T) Tuple;
}

void main()
{
 if(4 in Tuple!("hi", 5.5, 4))
  writefln("yep");
 else
  writefln("nope");

 if("no" in Tuple!("hi", 5.5, 4))
  writefln("yep");
 else
  writefln("nope");
}


Meh.  :)
Dec 06 2006
next sibling parent Alexander Panek <a.panek brainsware.org> writes:
Ha! Very nice.

I start to like those mysterious Tuples. ;)

Jarrett Billingsley wrote:

 "Egor Starostin" <egorst gmail.com> wrote in message 
 news:el5vpc$9nt$1 digitaldaemon.com...

 Me too.

 For example, in Python I can write

 if val in ('off','disable','no')

 and in D I have to write

 if (val == "off" || val == "disable" || val == "no")

 which is less readable (to me, at least).


 
 struct _Tuple(T...)
 {
  bool opIn_r(U)(U value)
  {
   foreach(val; T)
   {
    static if(is(typeof(val) : U))
    {
     if(val == value)
      return true;
    }
   }
 
   return false;
  }
 }
 
 template Tuple(T...)
 {
  const _Tuple!(T) Tuple;
 }
 
 void main()
 {
  if(4 in Tuple!("hi", 5.5, 4))
   writefln("yep");
  else
   writefln("nope");
 
  if("no" in Tuple!("hi", 5.5, 4))
   writefln("yep");
  else
   writefln("nope");
 }
 
 
 Meh.  :)
Dec 06 2006
prev sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Tuples, For The Win.

This is a prime example of why we can overload operators in D, and how 
templates further enhance that capability.  There's little need to add 
language features when the language supports so many possible constructs 
already.

Jarrett Billingsley wrote:

 struct _Tuple(T...)
 {
  bool opIn_r(U)(U value)
  {
   foreach(val; T)
   {
    static if(is(typeof(val) : U))
    {
     if(val == value)
      return true;
    }
   }
 
   return false;
  }
 }
 
 template Tuple(T...)
 {
  const _Tuple!(T) Tuple;
 }
 
 void main()
 {
  if(4 in Tuple!("hi", 5.5, 4))
   writefln("yep");
  else
   writefln("nope");
 
  if("no" in Tuple!("hi", 5.5, 4))
   writefln("yep");
  else
   writefln("nope");
 }
 
 
 Meh.  :) 
 
 



-- 
- EricAnderton at yahoo
Dec 07 2006
prev sibling next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Bill Baxter wrote:

 I keep wanting to say
   if (val in somearray) {
   }


Wait! That's just it!

It's "KEY in CONTAINER" and the KEY of a regular array is the index, not 
the value. So dare I suggest the following instead?

if (index in somearray) {
}

This "in" would be:
(cast(size_t)index < somearray.length?&somearray[index]:null)

Totally analogous to the associative array. And it also solves the 
"Length comparison" issue.

L.
Dec 06 2006
next sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Lionello Lunesu wrote:

 Bill Baxter wrote:
 

 I keep wanting to say
   if (val in somearray) {
   }


 
 
 Wait! That's just it!
 
 It's "KEY in CONTAINER" and the KEY of a regular array is the index, not 
 the value. So dare I suggest the following instead?
 
 if (index in somearray) {
 }
 
 This "in" would be:
 (cast(size_t)index < somearray.length?&somearray[index]:null)
 
 Totally analogous to the associative array. And it also solves the 
 "Length comparison" issue.
 
 L.


hmmm, seems unintuitive to me.  I tend to think of the "in" operator 
acting on a set and a potential member of the set.  I also tend to think 
of an array as a set of somethings.  Now when I make an int[] and say 
something like if( 14 in somethings ) I'd expect it to look through the 
set of somethings and see if the number 14 is in there.  I wouldn't 
expect it to look through the set of integers that are less than 
somethings.length to see if 14 is in that.

Now I'm wondering, why is it a good idea to have "in" mean what it does 
for aa's?  It seems to hold back a lot of other stuff, and not provide 
much.  It would be nice to be able to write foreach(value in array) 
instead of using the strange semicolon syntax - and this is very common. 
  I doubt the current usage of "in" is anywhere near as common as that, 
or even as common as something like if(ipAddy in ipAddresses).  Thus it 
would be more appropriate to, in those few cases of aa "in" usage, 
instead write aa.hasKey(key) instead of (key in aa).  Changing that 
would also allow you to write (value in aa).

Notice that associative arrays have a .keys property.  Perhaps then, we 
could simply define the current usage of "in" - (key in aa) - to be 
shorthand for (key in aa.keys).  With that "in" has a more intuitive 
meaning, IMO.
Dec 06 2006
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Lionello Lunesu wrote:

 Bill Baxter wrote:

 I keep wanting to say
   if (val in somearray) {
   }


 
 Wait! That's just it!
 
 It's "KEY in CONTAINER" and the KEY of a regular array is the index, not 
 the value. So dare I suggest the following instead?
 
 if (index in somearray) {
 }
 
 This "in" would be:
 (cast(size_t)index < somearray.length?&somearray[index]:null)
 
 Totally analogous to the associative array. And it also solves the 
 "Length comparison" issue.
 
 L.


Now this I actually like... Can already think of places I could use it, such as
in Bovis 
during symbol/id lookups.  Its a nice idea.  (Might just add it to Cashew in
the meantime.)

-- Chris Nicholson-Sauls
Dec 06 2006
parent Bill Baxter <wbaxter gmail.com> writes:
Chris Nicholson-Sauls wrote:

 Lionello Lunesu wrote:
 

 Bill Baxter wrote:


 I keep wanting to say
   if (val in somearray) {
   }



 Wait! That's just it!

 It's "KEY in CONTAINER" and the KEY of a regular array is the index, 
 not the value. So dare I suggest the following instead?

 if (index in somearray) {
 }

 This "in" would be:
 (cast(size_t)index < somearray.length?&somearray[index]:null)

 Totally analogous to the associative array. And it also solves the 
 "Length comparison" issue.

 L.


 
 
 Now this I actually like... Can already think of places I could use it, 
 such as in Bovis during symbol/id lookups.  Its a nice idea.  (Might 
 just add it to Cashew in the meantime.)
 
 -- Chris Nicholson-Sauls


Ugh.  I've created a monster.

That would make sense in Lua where there is only one data structure 
(table), which can be indexed with numbers or non-numbers equally well, 
but in D, it just doesn't seem right to say 2 is 'in' 
["spam","eggs","spam"].  I certainly don't see any 2 in there.  The 
operation you want seems more like a get():

    T* get(T[] arr, size_t index) {
       return (index < arr.length ? &arr[index] : null)
    }

    if (somearray.get(10)) {
    }

The dict type in Python uses something like that for safe indexing, 
otherwise you use [] if throwing an exception is ok.

--bb
Dec 06 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Bill Baxter wrote:

 I keep wanting to say
   if (val in somearray) {
   }
 
 but 'in' doesn't work for arrays...  Is there any reason why not?


<snip>

You appear to be wanting it to find a given _value_ in an array. 
Several people have requested this.  The problem is that it would create 
a confusing inconsistency with associative arrays, in which it is 
defined to find a given _key_.

Logically, if in does anything on linear arrays, then it should check 
whether the given index is within the array's bounds.  This isn't just 
purism - it's also a generic programming concern.

Moreover, if we were to define an operator that finds a given _value_ in 
a linear array, we ought to have it for AAs too.

Stewart.
Dec 07 2006
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 07 Dec 2006 22:26:15 +0000, Stewart Gordon wrote:

Is this useful to someone?

// -----------------
template ContainsFrom (T)
{
    // Return 'index' if 'element' found in 'array' otherwise return -1
    int ContainsFrom(T[] pArray, T pElement, int pIndex)
    {
        if (pIndex >= 0)
        {
            while (pIndex < pArray.length)
            {
                if (pElement == pArray[pIndex])
                    return pIndex;
                pIndex++;
            }
        }
        return -1; // Not Found
    }
}

template Contains (T)
{
    int Contains(T[] pArray, T pElement)
    {
        return ContainsFrom(pArray,pElement,0);
    }

}

unittest
{

   int[] X;
   X ~= 3;
   X ~= 2;
   X ~= 6;
   X ~= 8;
   X ~= 1;

   assert(X.Contains(8)  == 3);
   assert(X.Contains(3)  == 0);
   assert(X.Contains(-1) == -1);
   assert(X.Contains(99) == -1);
   assert(X.ContainsFrom(8,4)  == -1);
   assert(X.ContainsFrom(8,2)  == 3);


   char[] Y = "qwerty";

   assert(Y.Contains('a') == -1);
   assert(Y.Contains('q') == 0);
   assert(Y.Contains('t') == 4);
   assert(Y.Contains('z') == -1);

}

// -------------


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
8/12/2006 9:52:26 AM
Dec 07 2006
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Stewart Gordon wrote:

 Bill Baxter wrote:

 I keep wanting to say
   if (val in somearray) {
   }

 but 'in' doesn't work for arrays...  Is there any reason why not?


 <snip>
 
 You appear to be wanting it to find a given _value_ in an array. Several 
 people have requested this.  The problem is that it would create a 
 confusing inconsistency with associative arrays, in which it is defined 
 to find a given _key_.


Confusing to whom?  That's the way it works in Python, and it never 
seemed the least bit odd or confusing to me, nor dare I say to the vast 
majority of Python users.

If you want to check for a value in an AA all you would need is
"v in aa.values".  There's no need for a special 'check values' function.


 Logically, if in does anything on linear arrays, then it should check 
 whether the given index is within the array's bounds. This isn't just
 purism - it's also a generic programming concern.


Depends on how you think of an array.  Technically, yes, that's logical 
if you think of an array as a function that maps natural numbers to 
values (which is the functional purist's view).  But in terms of usage, 
for the most part arrays tend to be more like generic containers for 
(ordered) values, stored adjacent to each other in memory because that's 
the most efficient for certain applications.

The fact that I access an element by an index is just a side effect of 
that.  In fact sometimes I don't use indices, I use pointers instead. 
Should 'x in array' check if the pointer value x is array's memory range?

Arrays, linked lists, sets -- for a lot of purposes they are basically 
interchangeable.  They're all just containers that hold values.  Which 
one you choose just depends on what operations on those values need to 
be fast for your application, and what sort of ordering matters to you. 
  In my experience it's much more common to start with an array then 
realize at some point that insertion matters to me more than random 
access, so I switch to a linked list.  In that case should 'x in 
container' change from querying if the index is in the container to 
querying if the value is in the container (which is the only logical 
thing for 'in' to do on a linked list)?  Seems 'generic programming 
concerns' in that case would be better served by having 'in' check values.

For practical purposes, arrays, lists, and sets are much more similar to 
each other than arrays and associative arrays.  So if there is any 
'generic programming concern' it should default to making the 
lists/array/set types be generically interchangeable, not arrays and 
associative arrays.

And that's all I'm gonna say about it.  There's reasonable arguments 
both ways and neither argument amounts to a hill of beans if Walter 
isn't interested.

--bb
Dec 07 2006