www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - boolean over multiple variables

reply 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) )
Jan 22 2010
next sibling parent reply 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
Jan 22 2010
parent 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.
Jan 22 2010
prev sibling next sibling parent reply "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
Jan 22 2010
parent reply 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
Jan 22 2010
parent reply =?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 we get opIn_r for arrays, you can do

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

Which I find a lot prettier.
Jan 25 2010
parent reply "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 we get opIn_r for arrays, you can do

 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
Jan 25 2010
next sibling parent 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 we get opIn_r for arrays, you can do

 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 :)
Jan 25 2010
prev sibling parent reply =?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 we get opIn_r for arrays, you can do

 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 ] ) {
 }


Interesting solution! Very clever!

I still think opIn_r should be defined for arrays, though. :)
Jan 25 2010
parent "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
Jan 25 2010
prev sibling next sibling parent reply "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.
Jan 25 2010
parent reply =?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.


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.
Jan 26 2010
next sibling parent 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
Jan 26 2010
prev sibling parent reply "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.
Jan 26 2010
next sibling parent 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.
 


 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><
Jan 26 2010
prev sibling parent reply 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
Jan 26 2010
next sibling parent reply 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=




ble?

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


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


form a linear search, it uses a much smarter search that has a complexity l=
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=


ut having a item in items is nicer.

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


able 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 inconsisten=




t

 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 se=
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
Jan 26 2010
parent reply "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.
Jan 26 2010
parent 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=






on

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






nd

 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=


o

 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=


ld

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


h

 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, declar=


e

 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=


hey

 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.



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
Jan 26 2010
prev sibling next sibling parent reply "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.
Jan 26 2010
parent 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
Jan 26 2010
prev sibling parent 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
Jan 26 2010
prev sibling parent 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)
      * {
      *    ...
      * }
      */
   }
}
Jan 26 2010