Re: [Edu-sig] Truth values and comparisons
Scott David Daniels wrote: Though I guess we are all allowed to define sound programming for ourselves. With the exception you pointed out about space shuttles. if sum(abs(the_array)) != 0: go ahead Am I still blowing up anything, potentially?? Still preferring something along these lines in the context in which I am working. any may be more readable (it is certainly more succinct).to the knowing reader, but less so to the less knowing. But it is hard to separate readability from some concept of who your readers might be, and overall context. It also allows me to switch easily to the concept of zero for practical purposes as opposed to true/false. if sum(abs(the_array)) EPS: go ahead OTOH, I am the one always fighting condescension. I can see it be argued (my own objection to some of the arguments against int/int = int, always , was something along these lines) that my approach - in a pedagogical settings - effectively avoids an opportunity to elucidate something that should be elucidated. Probably no way to win in any black and white sense with these kinds of issues. Think I'll go with any in the end, unless there is a real reason to believe that zero for practical purposes is or might come into play. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Truth values and comparisons
Arthur wrote: some code with an issue addressed by Dan Crosta ... Is concerning myself with this distinction sound programming, or is the hard core answer more to the effect what works works, what doesn't doesn't - and one should focus only on that, and perhaps the performance impact of available alternatives? For my money (and that of most professional programmers I don't revile), it is _vital_ to concern yourself with such distinctions. Writing code should be an exercise in how do I express this the most clearly, not how can I make it run as fast as possible. Code first must be correct, then obviously correct, then fast enough (which in some special cases is as fast as possible). Clearly correct can either come from how the code itself is written, or (if necessary hen getting the speed up) through comments that help the reader understand why it is correct. Though I guess we are all allowed to define sound programming for ourselves. With the exception you pointed out about space shuttles. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Truth values and comparisons
[EMAIL PROTECTED] wrote: I've not used .any or .all, but having just taught my CS1 students about boolean operators, I was reminded that Python works as the following example describes: x = a and b # if both a and b are true, x is assigned b, otherwise x is assigned a x = 2 and 3 # x is assigned 3 x = 0 and 2 # x is assigned 0 x = a or b # if a is true, x is assigned a, if a is true, x is assigned a, if a is false and b is true, x is assigned b, if both a and b are false, x is assigned False You need to determine what should make vertex_map[tp] be true... thanks, but having some trouble: import Numeric as N a=N.array([0,0,0]) b=N.array([0,0,1]) a and b array([0, 0, 0]) b and a array([0, 0, 0]) Can this be? Either both a and b are true, or they are not, so can it be returning the a in both cases? Something screwy, other than my comprehension here? Same problem with a or b array([0, 0, 1]) b or a array([0, 0, 1]) OTOH, this makes sense to me - with 0 being False any(a) False all(a) False any(b) True all(b) False Though anyone growing up with the Python boolean operator might wonder why it is as it is - i.e. when 0 was the way to spell False this behavior is fairly well expected. Now that False is spelled False, having 0 any less true than 1, when thinks one is dealing with numbers as numbers, is likely to catch the less geeky unaware, IMO. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Truth values and comparisons
On Monday 30 October 2006 10:49 am, Arthur wrote: [EMAIL PROTECTED] wrote: I've not used .any or .all, but having just taught my CS1 students about boolean operators, I was reminded that Python works as the following example describes: x = a and b # if both a and b are true, x is assigned b, otherwise x is assigned a x = 2 and 3 # x is assigned 3 x = 0 and 2 # x is assigned 0 x = a or b # if a is true, x is assigned a, if a is true, x is assigned a, if a is false and b is true, x is assigned b, if both a and b are false, x is assigned False You need to determine what should make vertex_map[tp] be true... thanks, but having some trouble: import Numeric as N a=N.array([0,0,0]) b=N.array([0,0,1]) a and b array([0, 0, 0]) This tells me that a zero array is being treated as False (the logical extension to arrays of 0 being false. b and a array([0, 0, 0]) Right. In both cases, the answer is False, which Python gives to you by handing you the first False expression. In either case the false part of the and is the 0 array, while the other is True (a non-zero array). You can check this out: not(a) True not(b) False Can this be? Either both a and b are true, or they are not, so can it be returning the a in both cases? Something screwy, other than my comprehension here? Because a is False ;-). They're not both true. Same problem with a or b array([0, 0, 1]) b or a array([0, 0, 1]) This works the same way, but returns the first True expression as the value of True. any(a) False all(a) False any(b) True all(b) False Though anyone growing up with the Python boolean operator might wonder why it is as it is - i.e. when 0 was the way to spell False this behavior is fairly well expected. Now that False is spelled False, having 0 any less true than 1, when thinks one is dealing with numbers as numbers, is likely to catch the less geeky unaware, IMO. This is why in teaching I prefer to use explicit tests: if x != 0: do something Rather than if x: do something --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer ScienceWaverly, IA [EMAIL PROTECTED] (319) 352-8360 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Truth values and comparisons
John Zelle wrote: On Monday 30 October 2006 10:49 am, Arthur wrote: thanks, but having some trouble: import Numeric as N a=N.array([0,0,0]) b=N.array([0,0,1]) a and b array([0, 0, 0]) This tells me that a zero array is being treated as False (the logical extension to arrays of 0 being false. b and a array([0, 0, 0]) Right. In both cases, the answer is False, which Python gives to you by handing you the first False expression. Ah. that is what I was missing, returns the first *False* expression. I was interpreting Dave to say that it returns the first expression, period. With that, things fall into place. Thanks, Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Truth values and comparisons
John Zelle wrote: This is why in teaching I prefer to use explicit tests: if x != 0: do something Rather than if x: do something Yeah, so in the case I am looking at there is a branching based on whether either of 2 arrays are all zeros. So to achieve numpy compatibility, and to make the code more understandable to folks (like myself) who have some trouble in switching gears between numbers being used as numbers and at the same time being used for their truth values (kind of a trick really), I might do if sum(x) !=0: use this array else: use other array. kind of thing. The case here being distinguishable, in my mind, from the situation where one purposefully fills an array with 0's and 1's, with the intention of representing truth values. In *that* case the if sum(x) !=0 would work just as well, but now would seem to be the trick solution rather than the elegant one. Interesting how context matters in these kind of styling questions. Assuming I am making sense... Is concerning myself with this distinction sound programming, or is the hard core answer more to the effect what works works, what doesn't doesn't - and one should focus only on that, and perhaps the performance impact of available alternatives? Though I guess we are all allowed to define sound programming for ourselves. Art Art --John ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Truth values and comparisons
Arthur wrote: if sum(x) !=0: use this array else: use other array. be careful: a = [1, 0, -1] if a: print true true if sum(a) != 0: print true that's why it's probably safer and more readable to use any() and all(), which i believe were both introduced to __builtin__ in py2.5. - d ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
