On 8/19/2011 13:04, Shay wrote:
> bool_a = len(A[0]) == 2
> bool_b = min([A[2] == x[2] for x in A[1:])
> bool_c = ccw_angle(*A)<  pi
>
> bool_b will not work if bool_a is true

bool_b = bool_a ? min(...) : false

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Fri, 19 Aug 2011 13:49:01 -0700, Darren New wrote:

> On 8/19/2011 13:04, Shay wrote:
>> bool_a = len(A[0]) == 2
>> bool_b = min([A[2] == x[2] for x in A[1:]) bool_c = ccw_angle(*A)<  pi
>>
>> bool_b will not work if bool_a is true
> 
> bool_b = bool_a ? min(...) : false

Beautiful, but that doesn't seem to be valid Python. However, a bit of 
guess-work reveals that:

bool_b = False if bool_a else min(...)

does work. So, I learned something there.


Thanks.
 -Shay

Post a reply to this message

On 8/20/2011 22:52, Shay wrote:
> On Fri, 19 Aug 2011 13:49:01 -0700, Darren New wrote:
>
>> On 8/19/2011 13:04, Shay wrote:
>>> bool_a = len(A[0]) == 2
>>> bool_b = min([A[2] == x[2] for x in A[1:]) bool_c = ccw_angle(*A)<   pi
>>>
>>> bool_b will not work if bool_a is true
>>
>> bool_b = bool_a ? min(...) : false
>
> Beautiful, but that doesn't seem to be valid Python.

OK. I had assumed python had that operator. It's the same as

if bool_a then bool_b = min(...) else bool_b = false;

> bool_b = False if bool_a else min(...)
> does work. So, I learned something there.

I think you *might* have the condition reversed on that. That looks like 
it's saying you don't evaluate bool_b if bool_a is true.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Sun, 21 Aug 2011 08:00:28 -0700, Darren New wrote:

> On 8/20/2011 22:52, Shay wrote:
>> On Fri, 19 Aug 2011 13:49:01 -0700, Darren New wrote:
>>
>>> On 8/19/2011 13:04, Shay wrote:
>>>> bool_a = len(A[0]) == 2
>>>> bool_b = min([A[2] == x[2] for x in A[1:]) bool_c = ccw_angle(*A)<  
>>>> pi
>>>>
>>>> bool_b will not work if bool_a is true
>>>
>>> bool_b = bool_a ? min(...) : false
>>
>> Beautiful, but that doesn't seem to be valid Python.
> 
> OK. I had assumed python had that operator. It's the same as
> 
> if bool_a then bool_b = min(...) else bool_b = false;
> 
>> bool_b = False if bool_a else min(...) does work. So, I learned
>> something there.
> 
> I think you *might* have the condition reversed on that. That looks like
> it's saying you don't evaluate bool_b if bool_a is true.

That's what I want. I mistyped a portion of my example

bool_b = min([A[2] == x[2] for x in A[1:])

should have been

bool_b = min([A[0][2] == x[2] for x in A[1:])

bool_b tests if all of the [2]s are equal. If bool_a is true, there are 
no [2]s.

Thanks for the help.

 -Shay

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> bool_b = bool_a ? min(...) : false

  That seems to have redundancy. How about:

bool_b = bool_a || min(...);

-- 
                                                          - Warp

Post a reply to this message

On 8/22/2011 8:04, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> bool_b = bool_a ? min(...) : false
>
>    That seems to have redundancy. How about:
>
> bool_b = bool_a || min(...);
>

More efficient perhaps, but less readable IMO. You don't really want to set 
bool_b to the value of bool_a, so this I would consider misleading. There's 
an implication that the value of bool_a propagates, whereas in actuality 
it's more a gating value.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 8/22/2011 8:04, Warp wrote:
> > Darren New<dne### [at] sanrrcom>  wrote:
> >> bool_b = bool_a ? min(...) : false
> >
> >    That seems to have redundancy. How about:
> >
> > bool_b = bool_a || min(...);
> >

  Btw, I made a mistake above. Obviously it should have been:

bool_b = bool_a && min(...);

  (Yes, I understand the irony that you not catching this mistake is a
tell-tale sign of the obfuscatory nature of the expression. I still prefer
it, though.)

> More efficient perhaps, but less readable IMO. You don't really want to set 
> bool_b to the value of bool_a, so this I would consider misleading. There's 
> an implication that the value of bool_a propagates, whereas in actuality 
> it's more a gating value.

  You are not setting bool_b the value of bool_a. You are making a boolean
'and', and assigning the result of that to bool_b. The shortcut evaluation
of operator && is being (ab)used here to avoid evaluating the min(...)
expression in case bool_a is false. The advantage of this is that it
avoids the redundancy of the "else false" branch. (It's a bit like that
annoying "else break;" at the end of a loop, only in this case it's easily
avoidable.)

  This is, btw, a common tactic used in unix shell scripts. There the
&& operator can be used for a very similar purpose: If the command at the
left hand side succeeds, the command at the right hand side is executed.
The value of the expression is that of the first command that didn't
succeed, or success if they all succeeded.

  This means that rather than having to do something like

    if [ command1 ]; then if [ command2 ]; then command3; fi; fi

you can do it like:

    command1 && command2 && command3

  This is handy to execute several commands in succession, but have the
entire thing immediately stop if any of the commands fails. (This in
contrast with "command1; command2; command3" which will not stop if any
of those fails.)

-- 
                                                          - Warp

Post a reply to this message

On 8/26/2011 7:48, Warp wrote:
>    You are not setting bool_b the value of bool_a.

And that's exactly my complaint. The value of bool_b is dependent on bool_a, 
but not really assigned from it. I'm sure you see what I mean.

> You are making a boolean
> 'and', and assigning the result of that to bool_b.

But when the first expression indicates the second can't be evaluated, 
there's no reason to assign the first expression to bool_b, semantically 
speaking. I.e., it looks to me like it's tying the two too closely.

> avoids the redundancy of the "else false" branch.

True. On the other hand, the value of bool_b is never used if bool_a is 
wrong, so unless your language insists it be assigned before use and doesn't 
initialize it for you, there's no real reason to assign to it at all if 
bool_a indicates the value is invalid.

> (It's a bit like that
> annoying "else break;" at the end of a loop, only in this case it's easily
> avoidable.)

I can see your point.

>    This is, btw, a common tactic used in unix shell scripts.

Yeah, but IME it's usually used *only* to short circut the evaluation, not 
to actually use the result. YMMV.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 8/26/2011 7:48, Warp wrote:
> >    You are not setting bool_b the value of bool_a.

> And that's exactly my complaint. The value of bool_b is dependent on bool_a, 
> but not really assigned from it. I'm sure you see what I mean.

  Not really.

> > You are making a boolean
> > 'and', and assigning the result of that to bool_b.

> But when the first expression indicates the second can't be evaluated, 
> there's no reason to assign the first expression to bool_b, semantically 
> speaking. I.e., it looks to me like it's tying the two too closely.

  bool_a is not being assigned to bool_b. The result of the expression
"something && something_else" is being assigned to bool_b.

  I don't even understand what is it that you don't like about this.

> >    This is, btw, a common tactic used in unix shell scripts.

> Yeah, but IME it's usually used *only* to short circut the evaluation, not 
> to actually use the result. YMMV.

  It may be *common* for the result to be discarded, but it's perfectly
possible to take the result into account for subsequent decisions. The
advantage of using a sequence of commands separated by && is that you
don't need to put an 'if' after each of the commands, if you want to
react to one of them failing. You only need to use one 'if' to catch any
of them failing.

-- 
                                                          - Warp

Post a reply to this message

On 8/27/2011 7:14, Warp wrote:
>    bool_a is not being assigned to bool_b. The result of the expression
> "something&&  something_else" is being assigned to bool_b.
>
>    I don't even understand what is it that you don't like about this.

If bool_a is false, then bool_a is being assigned to bool_b. This implies in 
a vague sense that bool_b is false when bool_a is false. In reality, bool_b 
is *undefined* when bool_a is false. One assigns it "false" not because 
bool_a is false, but because one must assign something in that statement, 
and it doesn't matter what gets assigned.

In other words, in a language that supported tri-value logic (like PHP, 
perhaps), I'd say
   bool_b = bool_a ? min(...) : undefined
to make it clear.

>    It may be *common* for the result to be discarded, but it's perfectly
> possible to take the result into account for subsequent decisions. The
> advantage of using a sequence of commands separated by&&  is that you
> don't need to put an 'if' after each of the commands, if you want to
> react to one of them failing. You only need to use one 'if' to catch any
> of them failing.

Sure. And if the person wrote
   bool_a = big_long_expression_one(alpha,beta,gamma)
   bool_b = big_long_expression_one(alpha,beta,gamma) && min(...)
then I would agree that would be the right expression.

Again, it's a matter of taste. Written with the boolean, I'd have to stop 
and look at the rest of the code to see if, for example, there's a
    bool_b == bool_a
kind of expression somewhere later to try to understand what the bools meant.

Of course, picking better names for the bools would obviate the entire 
debate. :-)

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message