Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #96818 > unrolled thread

Re: True == 1 weirdness

Back to article view | Back to comp.lang.python

Contents

  Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-18 08:47 -0400
    Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-18 23:14 +1000
      Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-18 09:40 -0400
        Re: True == 1 weirdness Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-09-19 19:19 +1200
      Re: True == 1 weirdness Terry Reedy <tjreedy@udel.edu> - 2015-09-18 14:24 -0400
      Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-18 15:12 -0400
        Re: True == 1 weirdness Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-19 09:23 +0300
      Re: True == 1 weirdness Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-18 15:13 -0600
      Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-18 17:21 -0400

#96818 — Re: True == 1 weirdness

On Fri, Sep 18, 2015, at 08:30, Steven D'Aprano wrote:
> On Fri, 18 Sep 2015 07:26 am, Random832 wrote:
> 
> > I don't even think chaining should
> > work for all *actual* comparison operations.
> 
> I don't see why. Mathematicians chain comparisons all the time. If the
> language implements the same semantics as mathematicians already use, why
> do you dislike that?

Please provide a citation for this claim.
 
> Only if the comparisons are transitive, which they may not be. 

My *entire point* is that it *shouldn't be used* for non-transitive
comparisons!!!

[toc] | [next] | [standalone]

#96820

On Fri, 18 Sep 2015 10:47 pm, Random832 wrote:

> On Fri, Sep 18, 2015, at 08:30, Steven D'Aprano wrote:
>> On Fri, 18 Sep 2015 07:26 am, Random832 wrote:
>> 
>> > I don't even think chaining should
>> > work for all *actual* comparison operations.
>> 
>> I don't see why. Mathematicians chain comparisons all the time. If the
>> language implements the same semantics as mathematicians already use, why
>> do you dislike that?
> 
> Please provide a citation for this claim.

Really? You're disputing that chained comparisons are a standard maths
notation?

https://en.wikipedia.org/wiki/Inequality_(mathematics)#Chained_notation

Mathworld, for example, says:

    Solutions to the inequality |x-a|<b consist of the set {x:-b<x-a<b},
    or equivalently {x:a-b<x<a+b}.

http://mathworld.wolfram.com/Inequality.html


>> Only if the comparisons are transitive, which they may not be.
> 
> My *entire point* is that it *shouldn't be used* for non-transitive
> comparisons!!!

And my point is that there is no good reason for such a restriction, even if
it were technically possible to enforce (which it is not).

The mathematical chained notation doesn't rely on, or imply, transitivity.
Given a < b < c, *if* the operator is transitive, then AND ONLY THEN can
you conclude that a < c, but that's not implied by the chaining. It happens
to be true for real numbers, but it isn't necessarily true.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#96821

On Fri, Sep 18, 2015, at 09:14, Steven D'Aprano wrote:
> On Fri, 18 Sep 2015 10:47 pm, Random832 wrote:
> 
> > On Fri, Sep 18, 2015, at 08:30, Steven D'Aprano wrote:
> >> On Fri, 18 Sep 2015 07:26 am, Random832 wrote:
> >> 
> >> > I don't even think chaining should
> >> > work for all *actual* comparison operations.
> >> 
> >> I don't see why. Mathematicians chain comparisons all the time. If the
> >> language implements the same semantics as mathematicians already use, why
> >> do you dislike that?
> > 
> > Please provide a citation for this claim.
> 
> Really? You're disputing that chained comparisons are a standard maths
> notation?

I'm disputing that chained comparisons are used for the particular
combinations that I am actually arguing should not be used in python.
Such as a < b > c or a != b != c [whereas a may or may not be equal to
c] or a in b in c. Your claim seemed to be that these combinations *are*
used, since you claimed that python implements the *same* semantics.

[toc] | [prev] | [next] | [standalone]

#96845

Random832 wrote:
> I'm disputing that chained comparisons are used for the particular
> combinations that I am actually arguing should not be used in python.
> Such as a < b > c or a != b != c  [whereas a may or may not be equal to
> c]

I can't remember offhand seeing a != b != c written by a
mathematician, but if I did, I would suspect that he
*intended* it to imply a != c, even if that's not a strict
logical consequence of the notation.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#96830

On 9/18/2015 9:40 AM, Random832 wrote:

> I'm disputing that chained comparisons are used for the particular
> combinations that I am actually arguing should not be used in python.

You are free to dislike certain combinations, not use them yourself, and 
even request others not to use them (all in Python code).  But claiming 
that they have never been used in math is quite different.

> Such asa < b > c

If a, b, c are members of a totally ordered set, so that < is 
transitive, this is equivalent to max(a,c) < b.  But the latter makes an 
irrelevant comparison between a and c.

If they are only partially ordered, so that a and c are not necessarily 
comparable, then the above is the most concise way to way what it says. 
  I believe I have seen such.

> or a != b != c [whereas a may or may not be equal to c]

a != b != c != a says that all three are unequal to any of the other 
two.  I believe I have seen such, with '!=' replaced with the single 
'not equal' character.

or a in b in c.

If b and c are collections, such as sets, this is perfectly sensible. 
With 'in' replaced with the epsilon 'set membership' character, I may 
have seen such.  If 'a in b in c', then 'a in Union(c)', where Union is 
the union of all collections in c.  One might call this 
quasi-transitive.  In reverse, 'a in Union(c)' implies 'exists b, a in b 
in c'. Similarly, if 'a in b for all b in c' is equivalent to 'a in 
Intersection(c)'.

> Your claim seemed to be that these combinations *are*
> used, since you claimed that python implements the *same* semantics.

The semantics Python copies from math is "a op b op c == a op b and b op 
c", where 'op' is a binary predicate or comparison operator. I also 
happen to believe you are wrong in the specific examples. But the 
semantic copying would apply even if a particular combination had not 
yet ever been used.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#96832

On Fri, Sep 18, 2015, at 14:24, Terry Reedy wrote:
> If a, b, c are members of a totally ordered set, so that < is 
> transitive, this is equivalent to max(a,c) < b.  But the latter makes an 
> irrelevant comparison between a and c.

But *who would write that?* It's not a natural form of notation. I'm not
saying it doesn't mean anything in Python. Obviously everything that is
allowed means something. I'm saying no-one would write that in an
ordinary context of human communication and expect to be understood.

> > Your claim seemed to be that these combinations *are*
> > used, since you claimed that python implements the *same* semantics.
> 
> The semantics Python copies from math is "a op b op c == a op b and b op 
> c", 

I don't believe those *are* the semantics in math. I believe that in
math this notation is *specifically* meant to support "all of these
things are related to all of the others in ways that can be summarized
in a single expression" and that mixing operations in a way that does
not allow that is a misuse of the notation. In other words, any "a op b
op c" that does not allow you to make a statement on how a is related to
c is a *mistake*, because it means that you're welding together two
things that aren't logically connected to each other at all.

If there is no operator op3 where a op1 b op2 c implies a op3 c, then
you should not put a and c in the same inequality, full stop.

> where 'op' is a binary predicate or comparison operator. I also 
> happen to believe you are wrong in the specific examples. But the 
> semantic copying would apply even if a particular combination had not 
> yet ever been used.

[toc] | [prev] | [next] | [standalone]

#96844

Random832 writes:

> On Fri, Sep 18, 2015, at 14:24, Terry Reedy wrote:
>> If a, b, c are members of a totally ordered set, so that < is
>> transitive, this is equivalent to max(a,c) < b.  But the latter makes
>> an irrelevant comparison between a and c.
>
> But *who would write that?* It's not a natural form of notation. I'm
> not saying it doesn't mean anything in Python. Obviously everything
> that is allowed means something. I'm saying no-one would write that in
> an ordinary context of human communication and expect to be
> understood.

It might be natural when discussing partial orders, where (a < b > c) is
compatible with there not being any max(a, c) or even sup(a, c) at all.

Here's a class of strings ordered by inclusion as substrings. The
comparison (u in w != u) in __lt__ came naturally when I wrote this.

class S(object):
    def __init__(self, s):
        self.s = s
    def __lt__(self, other):
        return self.s in other.s != self.s
    def __eq__(self, other):
        return self.s == other.s
    def __str__(self):
        return 'S({})'.format(repr(self.s))

And here's looking for two distinct elements that have a common proper
upper bound in a given set.

data = ('a', 'oo', 'r', 'foo', 'bar')
print(*( (x.s, y.s)
         for x in map(S, data)
         for y in map(S, data)
         for m in map(S, data)
         if y != x < m > y != x  ),
       sep = '\n')

Output:
('a', 'r')
('r', 'a')

The question is whether some such conditions might, sometimes,
somewhere, in context, look natural. I says yes.

The condition as a whole states a verbalizable relation between x, y, m:
that m is a common upper bound of distinct x, y. It's not stated whether
x < y or x > y or neither.

[toc] | [prev] | [next] | [standalone]

#96836

On Fri, Sep 18, 2015 at 1:12 PM, Random832 <random832@fastmail.com> wrote:
> On Fri, Sep 18, 2015, at 14:24, Terry Reedy wrote:
>> The semantics Python copies from math is "a op b op c == a op b and b op
>> c",
>
> I don't believe those *are* the semantics in math. I believe that in
> math this notation is *specifically* meant to support "all of these
> things are related to all of the others in ways that can be summarized
> in a single expression" and that mixing operations in a way that does
> not allow that is a misuse of the notation. In other words, any "a op b
> op c" that does not allow you to make a statement on how a is related to
> c is a *mistake*, because it means that you're welding together two
> things that aren't logically connected to each other at all.
>
> If there is no operator op3 where a op1 b op2 c implies a op3 c, then
> you should not put a and c in the same inequality, full stop.

Whoever wrote the Wikipedia article disagrees:

https://en.wikipedia.org/wiki/Inequality_(mathematics)#Chained_notation

Although the reference to Python leads one to suspect that this could
be based more on Python's semantics than on actual mathematics.

[toc] | [prev] | [next] | [standalone]

#96837

On Fri, Sep 18, 2015, at 17:13, Ian Kelly wrote:
> Whoever wrote the Wikipedia article disagrees:
> 
> https://en.wikipedia.org/wiki/Inequality_(mathematics)#Chained_notation
> 
> Although the reference to Python leads one to suspect that this could
> be based more on Python's semantics than on actual mathematics.

Also, it says "different directions", but the provided example doesn't
actually *show* different directions (i.e. mixing less-operators with
greater-operators). The provided example "a < b = c <= d" does allow you
to infer relationships between all participants: a < b, a < c, a < d, b
= c, b <= d, c <= d.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web