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