www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: In expression for array

reply bearophile <bearophileHUGS lycos.com> writes:
kede wrote:
  if ('i' in eyes)
  ...
 
 as a simple replacement for the more verbose
  foreach(c; eyes)
    if (c == 'i')
      ...

I want to add few things to this discussion: - D already has opIn and opIn_r, so it's just a matter of using it. - If you use a language with the in built in (D has it already, but I meant for arrays), like Python, you can quickly understand why it's very good to have it built-in. (Generally if you come from a language that lacks something, then it becomes less easy to see why/where it's useful. I know some things aren't good if you put them in another language, but it's not this situation, I think). - Using the foreach(c; eyes) if (c == 'i'){} pattern is bad because you always use a O(n) scan regardless what that "eyes" is. But maybe "eyes" is an object with a opIn_r method that is O(ln n) or O(1), and you miss it. Instead if you use "in" (that is you use opIn_r) you always use the faster way of finding the presence of an item the object allows you to (if no opIn_r is defined, but opApply is defined, then the "in" operator must automatically call opApply to perform a scan). - So using "in" makes code shorter, more flexible, more type-agnostic (generic), simpler to read, potentially faster and more standard :-) Bye, bearophile
Jan 24 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On Jan 25, 2008 7:25 AM, bearophile <bearophileHUGS lycos.com> wrote:
 - So using "in" makes code shorter, more flexible, more type-agnostic
(generic), simpler to read, potentially faster and more standard :-)

All good points. But I know that part of the reason it's a no-go is consistency. "in" has to scan the keys, not the values, or it would be inconsistent with AAs. Personally I wouldn't mind dropping "in" in favor of two new infix functions "contains" and "containsKey", which would disambiguate the two cases (and give extra functionality for AAs). But it's probably too late to change things now, so forget I said anything. :-)
Jan 25 2008
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Janice Caron wrote:
 On Jan 25, 2008 7:25 AM, bearophile <bearophileHUGS lycos.com> wrote:
 
- So using "in" makes code shorter, more flexible, more type-agnostic
(generic), simpler to read, potentially faster and more standard :-)

All good points. But I know that part of the reason it's a no-go is consistency. "in" has to scan the keys, not the values, or it would be inconsistent with AAs.

Which doesn't stop Python from doing it this way. And it makes perfect sense. In an AA, you are typically concerned with whether a given key exists in the container. With an array, you are typically concerned with whether a given item is somewhere in the array. Arrays and associative arrays are fundamentally different, and I'm not sure this consistency actually buys us anything. And, obviously, using 'in' to check whether a given index is in an array is basically useless. Using it as a containment check is /much/ more useful. So what if arrays and AAs act differently? You can't assign to an arbitrary non-existent index in an array, or append to an AA, either. They are not substitutes for each other.
 Personally I wouldn't mind dropping "in" in favor of two new infix
 functions "contains" and "containsKey", which would disambiguate the
 two cases (and give extra functionality for AAs). But it's probably
 too late to change things now, so forget I said anything. :-)

These can already be done as library functions, if there's that much concern about it. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jan 25 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
bearophile wrote:
 kede wrote:
  if ('i' in eyes)
  ...

 as a simple replacement for the more verbose
  foreach(c; eyes)
    if (c == 'i')
      ...

I want to add few things to this discussion: - D already has opIn and opIn_r, so it's just a matter of using it. - If you use a language with the in built in (D has it already, but I meant for arrays), like Python, you can quickly understand why it's very good to have it built-in. (Generally if you come from a language that lacks something, then it becomes less easy to see why/where it's useful. I know some things aren't good if you put them in another language, but it's not this situation, I think). - Using the foreach(c; eyes) if (c == 'i'){} pattern is bad because you always use a O(n) scan regardless what that "eyes" is. But maybe "eyes" is an object with a opIn_r method that is O(ln n) or O(1), and you miss it. Instead if you use "in" (that is you use opIn_r) you always use the faster way of finding the presence of an item the object allows you to (if no opIn_r is defined, but opApply is defined, then the "in" operator must automatically call opApply to perform a scan). - So using "in" makes code shorter, more flexible, more type-agnostic (generic), simpler to read, potentially faster and more standard :-) Bye, bearophile

bool has(T)(T[] arr, T elem) { foreach (a; arr) if (a == elem) return true; return false; } if (myarray.has(3)) { // ... } Just as good, imhoe. You can't avoid a linear scan unless you know whether the array is sorted.
Jan 25 2008