• strtr <strtr spam.com> Jan 22 2010
• BCS <none anon.com> Jan 22 2010
• strtr <strtr spam.com> Jan 22 2010
• "Simen kjaeraas" <simen.kjaras gmail.com> Jan 22 2010
• strtr <strtr spam.com> Jan 22 2010
• =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> Jan 25 2010
• strtr <strtr spam.com> Jan 25 2010
• =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> Jan 25 2010
• "Simen kjaeraas" <simen.kjaras gmail.com> Jan 25 2010
• "Simen kjaeraas" <simen.kjaras gmail.com> Jan 25 2010
• "Nick Sabalausky" <a a.a> Jan 25 2010
• =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> Jan 26 2010
• bearophile <bearophileHUGS lycos.com> Jan 26 2010
• "Nick Sabalausky" <a a.a> Jan 26 2010
• BCS <none anon.com> Jan 26 2010
• bearophile <bearophileHUGS lycos.com> Jan 26 2010
• "Nick Sabalausky" <a a.a> Jan 26 2010
• bearophile <bearophileHUGS lycos.com> Jan 26 2010
• "Nick Sabalausky" <a a.a> Jan 26 2010
• Rainer Deyke <rainerd eldwood.com> Jan 26 2010
• Bill Baxter <wbaxter gmail.com> Jan 26 2010
• Bill Baxter <wbaxter gmail.com> Jan 26 2010
• Robert Clipsham <robert octarineparrot.com> Jan 26 2010

strtr <strtr spam.com> writes:

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) )

BCS <none anon.com> writes:

Hello Strtr,

 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) )
 


bool B;
switch(var) { case a,b,c,d: B = true; break; default B = false; break; }
if(B)

or you can put the then/else parts right in the switch

strtr <strtr spam.com> writes:

BCS Wrote:

 Hello Strtr,
 
 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) )
 


 bool B;
 switch(var) { case a,b,c,d: B = true; break; default B = false; break; }
 if(B)
 
 or you can put the then/else parts right in the switch
 


Not really what I had in mind, but works yes.

"Simen kjaeraas" <simen.kjaras gmail.com> writes:

On Fri, 22 Jan 2010 22:55:45 +0100, strtr <strtr spam.com> 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) )


bool anySame( T, U... )( T arg1, U args ) {
   foreach ( arg; args ) {
     if ( arg1 == arg ) {
       return true;
     }
   }
   return false;
}

bool allSame( T, U... )( T arg1, U args ) {
   foreach ( arg; args ) {
     if ( arg1 != arg ) {
       return false;
     }
   }
   return true;
}

Not tested, but they should work:

if ( anySame( var, a, b, c, d ) ) {
}

if ( allSame( var, a, b, c, d ) ) {
}

-- 
Simen

strtr <strtr spam.com> writes:

Simen kjaeraas Wrote:

 
 Not tested, but they should work:
 
 if ( anySame( var, a, b, c, d ) ) {
 }
 
 if ( allSame( var, a, b, c, d ) ) {
 }
 


A lot prettier.
I thought there would be a generic (basic) solution to this which I just didn't
know about but maybe I actually do know the basics by now :)
 -- 
 Simen

=?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:

On 01/23/2010 12:29 AM, strtr wrote:
 Simen kjaeraas Wrote:

 Not tested, but they should work:

 if ( anySame( var, a, b, c, d ) ) {
 }

 if ( allSame( var, a, b, c, d ) ) {
 }


 A lot prettier.
 I thought there would be a generic (basic) solution to this which I just
didn't know about but maybe I actually do know the basics by now :)
 --
 Simen





if (var in [a, b, c, d]) {
}

Which I find a lot prettier.

strtr <strtr spam.com> writes:

Simen kjaeraas Wrote:

 On Mon, 25 Jan 2010 09:59:42 +0100, Pelle MÃ¥nsson  
 <pelle.mansson gmail.com> wrote:
 
 On 01/23/2010 12:29 AM, strtr wrote:
 Simen kjaeraas Wrote:

 Not tested, but they should work:

 if ( anySame( var, a, b, c, d ) ) {
 }

 if ( allSame( var, a, b, c, d ) ) {
 }


 A lot prettier.
 I thought there would be a generic (basic) solution to this which I  
 just didn't know about but maybe I actually do know the basics by now :)
 --
 Simen





 if (var in [a, b, c, d]) {
 }

 Which I find a lot prettier.


 Is this good enough?
 
 struct CheckIf( T ) {
    T payload;
    bool opIn( T[] rhs ) {
      foreach ( e; rhs ) {
        if ( e == payload ) {
          return true;
        }
      }
      return false;
    }
 }
 
 CheckIf!( T ) checkIf( T )( T rhs ) {
    return CheckIf!( T )( rhs );
 }
 
 if ( checkIf( true ) in [ false, true, false ] ) {
 }
 
 -- 
 Simen


Sometimes code just makes me smile :)

=?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:

On 01/25/2010 10:28 AM, Simen kjaeraas wrote:
 On Mon, 25 Jan 2010 09:59:42 +0100, Pelle MÃ¥nsson
 <pelle.mansson gmail.com> wrote:

 On 01/23/2010 12:29 AM, strtr wrote:
 Simen kjaeraas Wrote:

 Not tested, but they should work:

 if ( anySame( var, a, b, c, d ) ) {
 }

 if ( allSame( var, a, b, c, d ) ) {
 }


 A lot prettier.
 I thought there would be a generic (basic) solution to this which I
 just didn't know about but maybe I actually do know the basics by now :)
 --
 Simen





 if (var in [a, b, c, d]) {
 }

 Which I find a lot prettier.


 Is this good enough?

 struct CheckIf( T ) {
 T payload;
 bool opIn( T[] rhs ) {
 foreach ( e; rhs ) {
 if ( e == payload ) {
 return true;
 }
 }
 return false;
 }
 }

 CheckIf!( T ) checkIf( T )( T rhs ) {
 return CheckIf!( T )( rhs );
 }

 if ( checkIf( true ) in [ false, true, false ] ) {
 }



I still think opIn_r should be defined for arrays, though. :)

"Simen kjaeraas" <simen.kjaras gmail.com> writes:

On Mon, 25 Jan 2010 09:59:42 +0100, Pelle M=C3=A5nsson  =

<pelle.mansson gmail.com> wrote:

 On 01/23/2010 12:29 AM, strtr wrote:
 Simen kjaeraas Wrote:

 Not tested, but they should work:

 if ( anySame( var, a, b, c, d ) ) {
 }

 if ( allSame( var, a, b, c, d ) ) {
 }


 A lot prettier.
 I thought there would be a generic (basic) solution to this which I  =




 just didn't know about but maybe I actually do know the basics by now=




 --
 Simen





 if (var in [a, b, c, d]) {
 }

 Which I find a lot prettier.


Is this good enough?

struct CheckIf( T ) {
   T payload;
   bool opIn( T[] rhs ) {
     foreach ( e; rhs ) {
       if ( e =3D=3D payload ) {
         return true;
       }
     }
     return false;
   }
}

CheckIf!( T ) checkIf( T )( T rhs ) {
   return CheckIf!( T )( rhs );
}

if ( checkIf( true ) in [ false, true, false ] ) {
}

-- =

Simen

"Simen kjaeraas" <simen.kjaras gmail.com> writes:

Pelle M=C3=A5nsson <pelle.mansson gmail.com> wrote:

 Interesting solution! Very clever!


Thank you.

 I still think opIn_r should be defined for arrays, though. :)


Yeah, but currently, 'a in b' means '(=E2=88=83b[a])', that is,
'is a a valid index in b'.
This means having 'a in b' mean '(=E2=88=83i)( b[i] =3D a )', that is,
'is there such an i that b[i] =3D=3D a' would introduce
inconsistencies.

While I do agree it would, I do see reasons for including such
a thing to the language, especially seeing how often just that
question arises, and how rarely the first meaning is actually
useful.

-- =

Simen

"Nick Sabalausky" <a a.a> writes:

"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. 

=?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:

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.


in a regular array.

This is how it works in python.

bearophile <bearophileHUGS lycos.com> writes:

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

"Nick Sabalausky" <a a.a> writes:

"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.

BCS <none anon.com> writes:

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.
 


 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><

bearophile <bearophileHUGS lycos.com> writes:

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

"Nick Sabalausky" <a a.a> writes:

"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.

bearophile <bearophileHUGS lycos.com> writes:

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

"Nick Sabalausky" <a a.a> writes:

"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.34.1264542189.4461.digitalmars-d-learn puremagic.com...
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.)


Even looking at function rather than form, I still think its innacurate to 
consider the keys to be the elements of an AA. In most uses of an AA, the 
key is primarily something convenient with which to look up data. They hold 
significance, but typically not as much as the data that is looked up with 
it. What you've described is very much like (and quite literally the same 
as, in the case of many dynamic languages) thinking of a variable's name as 
the actual data, and thinking of the value it holds merely as "ancillary 
data".

Keep in mind too, even with a regular array, the index can still hold 
significance as data. For instace, I could have an array of Foo's, declare 
that any element with an odd index has property 'A' and any with an even 
index has property 'B', and treat them as such. May seem strange at a 
glance, but such things are common in low-level, low-resoruce and 
performance-oriented code. Bottom line, though, is that "Property 'A' or 
'B'" is data that now been encoded in the array's index, but despite that, 
the indicies still aren't considered the array's elements. And the data they 
lookup still isn't considered "ancillary data".

And yes, a Hashed Set may likely be *implemented* as an AA with just keys, 
but that's just form, it doesn't imply a similarity in regard to function. 
The *function* of a HashSet is that of an unordered array that's been 
optimized for "contains X / doesn't contain X" on large data sets.

Containers and their functions:
- AA: Store A's with label B, A is fairly important, B may or may not be.
- Array: Store A's with label B, A is fairly important, B may or may not be, 
B has certain restrictions, container overall has different performance 
characteristacs from an AA.
- Hashed Set: Store A's.

Rainer Deyke <rainerd eldwood.com> writes:

bearophile 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.


I would add to that:
4) Because 'in' is an operator, and operators are expected to bear a
greater weight than ordinary functions.

If 'in' was an ordinary method, say 'a.contains(b)', then I would choose
different method names for searching an array for a value and searching
an associative array for a key.  Probably something like:
  array.contains(value)
  associative_array.containsKey(key)

However, since 'in' already is an infix operator, it should have the
most widely applicable semantics.  Operators are heavyweight syntactic
sugar for function calls.  There is no room in D for operators that are
only rarely useful.


-- 
Rainer Deyke - rainerd eldwood.com

Bill Baxter <wbaxter gmail.com> writes:

On Tue, Jan 26, 2010 at 1:21 PM, bearophile <bearophileHUGS lycos.com> wrot=
e:
 Nick Sabalausky:
 Aside from that being how Python does it, why do you see that as prefera=




 Because:
 1) linear searches in an array are damn common. I don't remember the resu=


-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 per=


ower 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, b=


 3) You can use the same syntax to search into anything that's lazily iter=


 So having a single syntax work on the outputs for
 regular arrays, but then on the inputs for AAs, seems highly inconsisten=




 and error-prone to me.


 I have followed many Python newbies personally, I am following the Python=


en many different kinds of bugs, I have not seen a significant amount of bu=
gs 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

Bill Baxter <wbaxter gmail.com> writes:

On Tue, Jan 26, 2010 at 6:16 PM, Nick Sabalausky <a a.a> wrote:
"Bill Baxter" <wbaxter gmail.com> wrote in message
news:mailman.34.1264542189.4461.digitalmars-d-learn puremagic.com...
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 Pyth=






 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=






 little different in this regard. At the same way they learn that a set
 and a dict are different data structures, with different capabilities a=






 usages.


It's not even really =A0inconsistent 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. =A0"O in Array" means
"is O in that set of things"
An AA is a set of things that also have some associated data. =A0"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.)


 Even looking at function rather than form, I still think its innacurate t=


 consider the keys to be the elements of an AA. In most uses of an AA, the
 key is primarily something convenient with which to look up data. They ho=


 significance, but typically not as much as the data that is looked up wit=


 it. What you've described is very much like (and quite literally the same
 as, in the case of many dynamic languages) thinking of a variable's name =


 the actual data, and thinking of the value it holds merely as "ancillary
 data".

 Keep in mind too, even with a regular array, the index can still hold
 significance as data. For instace, I could have an array of Foo's, declar=


 that any element with an odd index has property 'A' and any with an even
 index has property 'B', and treat them as such. May seem strange at a
 glance, but such things are common in low-level, low-resoruce and
 performance-oriented code. Bottom line, though, is that "Property 'A' or
 'B'" is data that now been encoded in the array's index, but despite that=


 the indicies still aren't considered the array's elements. And the data t=


 lookup still isn't considered "ancillary data".

 And yes, a Hashed Set may likely be *implemented* as an AA with just keys=


 but that's just form, it doesn't imply a similarity in regard to function=


 The *function* of a HashSet is that of an unordered array that's been
 optimized for "contains X / doesn't contain X" on large data sets.


 Containers and their functions:
 - AA: Store A's with label B, A is fairly important, B may or may not be.
 - Array: Store A's with label B, A is fairly important, B may or may not =


 B has certain restrictions, container overall has different performance
 characteristacs from an AA.
 - Hashed Set: Store A's.



All I am trying to say is that there are multiple ways of looking at
the functionality offered by different containers.
And there exists a way of looking at it where the Python-style 'in'
operator can be seen as behaving consistently.

You asserted it is inconsistent.  I'm just saying it's only
inconsistent if you insist that one particular way of looking at the
containers is the "right" way.

--bb

Robert Clipsham <robert octarineparrot.com> writes:

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)
      * {
      *    ...
      * }
      */
   }
}