Short-circuit Logic

[Carlos Nepomuceno]

----------------------------------------
> From: steve+comp.lang.python at pearwood.info
> Subject: Re: Short-circuit Logic
> Date: Fri, 31 May 2013 08:45:13 +0000
> To: python-list at python.org
>
> On Fri, 31 May 2013 17:09:01 +1000, Chris Angelico wrote:
>
>> On Fri, May 31, 2013 at 3:13 PM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> What makes you think that the commutative law is relevant here?
>>>
>>>
>> Equality should be commutative. If a == b, then b == a. Also, it's
>> generally understood that if a == c and b == c, then a == b, though
>> there are more exceptions to that (especially in loosely-typed
>> languages).
>
> Who is talking about equality? Did I just pass through the Looking Glass
> into Wonderland again? *wink*
>
> We're talking about *approximate equality*, which is not the same thing,
> despite the presence of the word "equality" in it. It is non-commutative,
> just like other comparisons like "less than" and "greater than or equal
> to". Nobody gets their knickers in a twist because the>= operator is non-
> commutative.

Approximately equality CAN be commutative! I have just showed you that in the beginning using the following criteria:

|v-u| <= ε*max(|u|,|v|)

Which is implemented as fpc_aeq():

def fpc_aeq(u,v,eps=sys.float_info.epsilon):
    au=abs(u)
    av=abs(v)
    return abs(v-u) <= (eps*(au if au>av else av))  # |v-u| <= ε*max(|u|,|v|)


> Approximate equality is not just non-commutative, it's also intransitive.
> I'm reminded of a story about Ken Iverson, the creator of APL. Iverson
> was a strong proponent of what he called "tolerant equality", and APL
> defined the = operator as a relative approximate equal, rather than the
> more familiar exactly-equal operator most programming languages use.
>
> In an early talk Ken was explaining the advantages of tolerant
> comparison. A member of the audience asked incredulously,
> “Surely you don’t mean that when A=B and B=C, A may not equal C?”
> Without skipping a beat, Ken replied, “Any carpenter knows that!”
> and went on to the next question. — Paul Berry

That's true! But it's a consequence of floating points (discretes representing a continuous set -- real numbers).
Out of context, as you put it, looks like approximate equality is non-commutative, but that's wrong.

Did you read the paper[1] you have suggested? Because SHARP APL in fact uses the same criteria I have mentioned and it supports it extensively to the point of applying it by default to many primitive functions, according to Lathwell[2] wich is reference 19 of [1].

"less than                  a<b
less than or equal          a≤b
equal                       a=b
greater than or equal       a≥b
greater than                a>b
not equal                   a≠b
floor                       ⌊a
ceiling                     ⌈a
membership                  a∊b
index of                    a⍳b"


I'll quote Lathwell. He called "tolerant comparison" what we are now calling "approximate equality".

"Tolerant comparison considers two numbers to be equal if they are within some neighborhood. The neighborhood has a radius of ⎕ct times the larger of the two in absolute value."

He says "larger of the two" which means "max(|u|,|v|)". So, you reference just reaffirms what TAOCP have demonstrated to be the best practice.

I really don't know what the fuck you are arguing about?

Can you show me at least one case where the commutative law wouldn't benefit the use of the approximate equality operator?

[1] http://www.jsoftware.com/papers/APLEvol.htm
[2] http://www.jsoftware.com/papers/satn23.htm


> The intransitivity of [tolerant] equality is well known in
> practical situations and can be easily demonstrated by sawing
> several pieces of wood of equal length. In one case, use the
> first piece to measure subsequent lengths; in the second case,
> use the last piece cut to measure the next. Compare the lengths
> of the two final pieces.
> — Richard Lathwell, APL Comparison Tolerance, APL76, 1976
>
> See also here:
>
> http://www.jsoftware.com/papers/APLEvol.htm
>
> (search for "fuzz" or "tolerance".
>
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list