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

Groups > comp.lang.c > #385515 > unrolled thread

Interval Comparisons

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

Contents

  Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 07:14 +0000
    Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-04 10:58 +0200
      Re: Interval Comparisons Mikko <mikko.levanto@iki.fi> - 2024-06-04 12:13 +0300
        Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-04 13:02 +0200
          Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-04 12:23 +0100
            Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-04 15:24 +0200
              Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-04 15:16 +0100
                Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-04 17:40 +0200
              Re: Interval Comparisons scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 15:27 +0000
                Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-04 16:58 +0100
                  Re: Interval Comparisons Michael S <already5chosen@yahoo.com> - 2024-06-04 19:25 +0300
                    Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-04 17:54 +0100
            Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 03:29 +0000
          Re: Interval Comparisons Mikko <mikko.levanto@iki.fi> - 2024-06-04 16:11 +0300
        Re: Interval Comparisons Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-04 15:42 +0200
        Re: Interval Comparisons Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-04 14:04 -0700
    Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-04 11:39 +0100
    Re: Interval Comparisons Thiago Adams <thiago.adams@gmail.com> - 2024-06-04 08:32 -0300
      Re: Interval Comparisons Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-04 13:37 +0200
      Re: Interval Comparisons Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-04 15:29 -0700
    Re: Interval Comparisons Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-06-04 11:41 +0000
      Re: Interval Comparisons Michael S <already5chosen@yahoo.com> - 2024-06-04 15:17 +0300
      Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 23:12 +0000
        Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-05 00:22 +0100
          Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 01:30 +0000
            Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-06 19:48 +0100
              Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-06 22:54 +0000
                Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-07 01:52 +0100
                  Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 02:17 +0000
                    Re: Interval Comparisons Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-06 20:53 -0700
                      Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 04:25 +0000
                      Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-07 11:22 +0200
                        Re: Interval Comparisons Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-07 02:55 -0700
                          Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-07 13:04 +0200
                            Re: Interval Comparisons Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-07 11:57 -0700
                              Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-08 17:42 +0200
                        Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-07 11:28 +0100
                          Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 10:45 +0000
                            Re: Interval Comparisons Michael S <already5chosen@yahoo.com> - 2024-06-07 14:51 +0300
                          Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-07 13:17 +0200
                            Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-07 13:20 +0100
                              Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-09 13:26 +0200
                                Re: Interval Comparisons bart <bc@freeuk.com> - 2024-06-10 16:33 +0100
                                  Re: Interval Comparisons David Brown <david.brown@hesbynett.no> - 2024-06-10 17:56 +0200
                            Re: Interval Comparisons scott@slp53.sl.home (Scott Lurndal) - 2024-06-07 14:00 +0000
                        Re: Interval Comparisons Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 10:42 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#385536

Ignoring the concept of backcompat, operators as a concept are bad enough; 
i think that we need not worsen the matter with new ternary operators.



-- 
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
INVINCIBLE MOOSE NEXT FIVE KILOMETERS

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

#385537

On Tue, 4 Jun 2024 11:41:54 -0000 (UTC)
Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:

> operators as a concept are bad enough;
> 

Those are fighting words! Care to suggest an alternative?

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

#385564

On Tue, 4 Jun 2024 11:41:54 -0000 (UTC), Blue-Maned_Hawk wrote:

> i think that we need not worsen the matter with new ternary operators.

These are not ternary operators.

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

#385565

On 05/06/2024 00:12, Lawrence D'Oliveiro wrote:
> On Tue, 4 Jun 2024 11:41:54 -0000 (UTC), Blue-Maned_Hawk wrote:
> 
>> i think that we need not worsen the matter with new ternary operators.
> 
> These are not ternary operators.

So what are they?

I've implemented them several times, and found they really need to be 
treated as a special kind of n-ary opterator.

An AST node for A+B say would have single operator "+", and two operands.

One for "A<=B<=C" would have two operators "<=" and "<", and three operands.

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

#385566

On Wed, 5 Jun 2024 00:22:36 +0100, bart wrote:

> On 05/06/2024 00:12, Lawrence D'Oliveiro wrote:
>
>> On Tue, 4 Jun 2024 11:41:54 -0000 (UTC), Blue-Maned_Hawk wrote:
>> 
>>> i think that we need not worsen the matter with new ternary operators.
>> 
>> These are not ternary operators.
> 
> So what are they?

A special case in the syntax rules for the comparison operators
<https://docs.python.org/3/reference/expressions.html#comparisons>.

> I've implemented them several times, and found they really need to be
> treated as a special kind of n-ary opterator.

Remember, Python allows users to define custom overloads for the standard 
operators. For comparisons, these functions always take two operands, and 
the compiler takes care of invoking them correctly to handle interval 
comparisons.

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

#385638

On 05/06/2024 02:30, Lawrence D'Oliveiro wrote:
> On Wed, 5 Jun 2024 00:22:36 +0100, bart wrote:
> 
>> On 05/06/2024 00:12, Lawrence D'Oliveiro wrote:
>>
>>> On Tue, 4 Jun 2024 11:41:54 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>
>>>> i think that we need not worsen the matter with new ternary operators.
>>>
>>> These are not ternary operators.
>>
>> So what are they?
> 
> A special case in the syntax rules for the comparison operators
> <https://docs.python.org/3/reference/expressions.html#comparisons>.
> 
>> I've implemented them several times, and found they really need to be
>> treated as a special kind of n-ary opterator.
> 
> Remember, Python allows users to define custom overloads for the standard
> operators. For comparisons, these functions always take two operands, and
> the compiler takes care of invoking them correctly to handle interval
> comparisons.


Well, for these 3 lines in my scripting language:


   if a = b then end             # universal
   if a = b < c then end         # chained (like Python, unlike C)
   if (a = b) < c then end       # emulate C behaviour

These are the ASTs produced (2: is the empty True branch; 3: would be 
for the 'else' branch, not present here):

- 1 if:
- - 1 eq:
- - - 1 name: a
- - - 2 name: b
- - 2 block:

- 1 if:
- - 1 cmpchain: eq lt
- - - 1 name: a
- - - 1 name: b
- - - 1 name: c
- - 2 block:

- 1 if:
- - 1 lt:
- - - 1 eq:
- - - - 1 name: a
- - - - 2 name: b
- - - 2 name: c
- - 2 block:

Notice the middle one is one linear group with N operands and N-1 
comparisons.

No operator overloads are allowed, but if they were, it would still 
work, but a comparison operator would be required to return True or 
False from its two operands. It would be unwise for it to return a 
string for example.

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

#385652

On Thu, 6 Jun 2024 19:48:42 +0100, bart wrote:

>    if a = b then end             # universal if a = b < c then end      

Really?? You allow that?

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

#385659

On 06/06/2024 23:54, Lawrence D'Oliveiro wrote:
> On Thu, 6 Jun 2024 19:48:42 +0100, bart wrote:
> 
>>     if a = b then end             # universal if a = b < c then end
> 
> Really?? You allow that?

Which bit: The 'a=b' (that's equality); the 'a=b<c' (just like Python); 
or 'then end' (just an empty block)?

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

#385664

On Fri, 7 Jun 2024 01:52:34 +0100, bart wrote:

> The 'a=b' (that's equality)

Not in C it isn’t.

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

#385665

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 7 Jun 2024 01:52:34 +0100, bart wrote:
>> The 'a=b' (that's equality)
>
> Not in C it isn’t.

Of course not.  You snipped the part where Bart very clearly said that
he was talking about his own scripting language.  And we're talking
about a proposed new C feature, so I have no problem with references to
other languages.

And there's precedent in other languages (Python, as Bart already
pointed out) for `a == b < c` being equivalent to `a == b && b < c`,
but with b evaluated only once.

*If* C were to adopt chained comparisons, I would have no problem
with `a == b < c` being supported with the obvious meaning.
I dislike arbitrary restrictions.  (Though the fact that == and
< have different precedences would have to be resolved somehow.)
In principle it could quietly change the behavior of existing code,
but it's likely that most such code was already wrong.  I don't
advocate making such a change, and I don't think it's likely to
happen, I wouldn't object to it.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#385666

On Thu, 06 Jun 2024 20:53:41 -0700, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Fri, 7 Jun 2024 01:52:34 +0100, bart wrote:
>>> The 'a=b' (that's equality)
>>
>> Not in C it isn’t.
> 
> Of course not.  You snipped the part where Bart very clearly said that
> he was talking about his own scripting language.

Oh, sorry.

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

#385679

On 07/06/2024 05:53, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Fri, 7 Jun 2024 01:52:34 +0100, bart wrote:
>>> The 'a=b' (that's equality)
>>
>> Not in C it isn’t.
> 
> Of course not.  You snipped the part where Bart very clearly said that
> he was talking about his own scripting language.  And we're talking
> about a proposed new C feature, so I have no problem with references to
> other languages.
> 
> And there's precedent in other languages (Python, as Bart already
> pointed out) for `a == b < c` being equivalent to `a == b && b < c`,
> but with b evaluated only once.
> 
> *If* C were to adopt chained comparisons, I would have no problem
> with `a == b < c` being supported with the obvious meaning.
> I dislike arbitrary restrictions.  (Though the fact that == and
> < have different precedences would have to be resolved somehow.)
> In principle it could quietly change the behavior of existing code,
> but it's likely that most such code was already wrong.  I don't
> advocate making such a change, and I don't think it's likely to
> happen, I wouldn't object to it.
> 

While it is true that such an addition to C would be very unlikely to 
break existing code (any current code that uses "a == b < c" or "a < b < 
c" is probably incorrect), there is a potentially serious consequence 
that has not been considered here.

Suppose C26 allows "a < b < c" and "a == b < c" chains, like Python, and 
some people start using it in real code.  You are going to get two 
effects.  One is that some people will read that new code but not know 
the new interpretation.  They will think the code parses as "a == (b < 
c)", and is likely a mistake, or does something different from what it 
now actually does.

The other is that some people will get used to it and think this is how 
C treats chained operators.  The code or similar expressions will end up 
in C code that is compiled under different standards.  Old C standards 
are used all the time - there are still some people who seem to think 
new coding in C89/C90 is a /feature/, rather than historical 
re-enactment.  You would get code that is tested and correct in C26 used 
incorrectly as C23 or older.

There is also the C++ compatibility question.  C++ provides flexible 
operator overloading combined with a poverty of available operators, so 
the relational operators <, >, <= and >= are sometimes used for 
completely different purposes, similar to the >> and << operators. 
Chaining relational operators would complicate this significantly, I 
think.  If C++ adopted the feature it would be a mess to support 
overloading, and if they did not, "a < b < c" in C and C++ would be 
valid but with completely different semantics.  Neither option is good.

To me, this possibility, along with the confusion it would cause, 
totally outweighs any potential convenience of chained comparisons.  I 
have never found them helpful in Python coding, and I can't imagine them 
being of any interest in my C code.

Even in a new language, I would not want to see chained relational 
operators unless you had a strict requirement that relational operators 
evaluate to a boolean type with no support for relational operators 
between booleans, and no support for comparison or other operators 
between booleans and other types.  And even then, what is "a == b == c" 
supposed to mean, or "a != b != c" ?

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

#385683

David Brown <david.brown@hesbynett.no> writes:
> On 07/06/2024 05:53, Keith Thompson wrote:
[...]
>> *If* C were to adopt chained comparisons, I would have no problem
>> with `a == b < c` being supported with the obvious meaning.
>> I dislike arbitrary restrictions.  (Though the fact that == and
>> < have different precedences would have to be resolved somehow.)
>> In principle it could quietly change the behavior of existing code,
>> but it's likely that most such code was already wrong.  I don't
>> advocate making such a change, and I don't think it's likely to
>> happen, I wouldn't object to it.
>
> While it is true that such an addition to C would be very unlikely to
> break existing code (any current code that uses "a == b < c" or "a < b
> < c" is probably incorrect), there is a potentially serious
> consequence that has not been considered here.
>
> Suppose C26 allows "a < b < c" and "a == b < c" chains, like Python,
> and some people start using it in real code.  You are going to get two 
> effects.  One is that some people will read that new code but not know
> the new interpretation.  They will think the code parses as "a == (b < 
> c)", and is likely a mistake, or does something different from what it
> now actually does.

I don't think that's much of a problem.  For a lot of people, the
meaning of "a < b < c" is obvious (and not what C currently provides).
And people reading C26 code need to be familiar with the language.

But ...

> The other is that some people will get used to it and think this is
> how C treats chained operators.  The code or similar expressions will
> end up in C code that is compiled under different standards.  Old C
> standards are used all the time - there are still some people who seem
> to think new coding in C89/C90 is a /feature/, rather than historical 
> re-enactment.  You would get code that is tested and correct in C26
> used incorrectly as C23 or older.

That's an excellent point.  The fact that chained comparisons would only
be usable in C26 and later wouldn't be a big problem; most programmers
just wouldn't be able to use them until C26 support is widespread.  But
the fact that chained comparisons silently have different semantics in
earlier versions of C could become a rich source of errors.

Based on that, *maybe* some future C could support chained comparisons
with an incompatible syntax, but I don't think it would be worth the
effort.

> There is also the C++ compatibility question.  C++ provides flexible
> operator overloading combined with a poverty of available operators,
> so the relational operators <, >, <= and >= are sometimes used for 
> completely different purposes, similar to the >> and <<
> operators. Chaining relational operators would complicate this
> significantly, I think.  If C++ adopted the feature it would be a mess
> to support overloading, and if they did not, "a < b < c" in C and C++
> would be valid but with completely different semantics.  Neither
> option is good.

I mentioned earlier that someone did a study of open source C++ code and
found no occurrences of things like "a < b < c", except for 4 cases that
were intended to be chained but would behave incorrectly.  I presume
that this study would have covered overloaded operators.

> To me, this possibility, along with the confusion it would cause,
> totally outweighs any potential convenience of chained comparisons.  I 
> have never found them helpful in Python coding, and I can't imagine
> them being of any interest in my C code.

I agree.  I wouldn't mind being able to use the feature, and I think
I've actually used it in Python, but its lack isn't a big problem.

> Even in a new language, I would not want to see chained relational
> operators unless you had a strict requirement that relational
> operators evaluate to a boolean type with no support for relational
> operators between booleans, and no support for comparison or other
> operators between booleans and other types.

In Python, all comparison operators (<, >, ==, >=, <=, !=, is, is not,
in, not in) have the same precedence, and chained operations are
specified straightforwardly.  They evaluate to a bool result.  Boolean
values can be compared (False < True), which doesn't seem to cause any
problems.

https://docs.python.org/3/reference/expressions.html#comparisons

>                                              And even then, what is "a
> == b == c" supposed to mean, or "a != b != c" ?

"a == b && b == c", and "a != b && b != c", respectively, except that b
is only evaluated once.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#385690

On 07/06/2024 11:55, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 07/06/2024 05:53, Keith Thompson wrote:
> [...]

> 
>> There is also the C++ compatibility question.  C++ provides flexible
>> operator overloading combined with a poverty of available operators,
>> so the relational operators <, >, <= and >= are sometimes used for
>> completely different purposes, similar to the >> and <<
>> operators. Chaining relational operators would complicate this
>> significantly, I think.  If C++ adopted the feature it would be a mess
>> to support overloading, and if they did not, "a < b < c" in C and C++
>> would be valid but with completely different semantics.  Neither
>> option is good.
> 
> I mentioned earlier that someone did a study of open source C++ code and
> found no occurrences of things like "a < b < c", except for 4 cases that
> were intended to be chained but would behave incorrectly.  I presume
> that this study would have covered overloaded operators.
> 

You helpfully quoted from that study, and it included :

- Many instances of using successive comparison operators in DSLs that
   overloaded these operators to give meaning unrelated to comparisons.

So yes, it seems that overloading the relational operators for other 
purposes and then chaining them is a real thing.

>> To me, this possibility, along with the confusion it would cause,
>> totally outweighs any potential convenience of chained comparisons.  I
>> have never found them helpful in Python coding, and I can't imagine
>> them being of any interest in my C code.
> 
> I agree.  I wouldn't mind being able to use the feature, and I think
> I've actually used it in Python, but its lack isn't a big problem.
> 
>> Even in a new language, I would not want to see chained relational
>> operators unless you had a strict requirement that relational
>> operators evaluate to a boolean type with no support for relational
>> operators between booleans, and no support for comparison or other
>> operators between booleans and other types.
> 
> In Python, all comparison operators (<, >, ==, >=, <=, !=, is, is not,
> in, not in) have the same precedence, and chained operations are
> specified straightforwardly.  They evaluate to a bool result.  Boolean
> values can be compared (False < True), which doesn't seem to cause any
> problems.
> 
> https://docs.python.org/3/reference/expressions.html#comparisons
> 
>>                                               And even then, what is "a
>> == b == c" supposed to mean, or "a != b != c" ?
> 
> "a == b && b == c", and "a != b && b != c", respectively, except that b
> is only evaluated once.
> 

If "c" is a boolean, some might think the "natural" interpretation of "a 
== b == c" is "(a == b) == c" - it is the current semantics in C.  Some 
people may think that "a != b != c" should be interpreted as "(a != b) & 
(b != c) & (a != c)".

It's one thing to make a rigid definition of the meaning in a language, 
picking a consistent set of rules of precedence and syntax.  It is 
another thing to make sure it matches up with the interpretations people 
have from normal mathematics, natural language, and other programming 
languages.  When there is a mismatch, you need good reasons to accept 
the syntax as a good language design idea - the more likely the 
misunderstanding, the stronger reasons you need.

To me, the potential misunderstandings of including != in chains is far 
too high in comparison to the meagre benefits.  The use of == could be 
clear in some situations (combined with strong type checking to help 
catch mistakes) but not others.  I could see a chain of a mix of < and 
<= making sense, or of > and >=, and occasionally being useful.  I don't 
think there is a point in allowing more than that.

After all, if all you need is to avoid evaluating "b" more than once, 
you can just do:

	auto const b_ = b;

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

#385720

David Brown <david.brown@hesbynett.no> writes:
> On 07/06/2024 11:55, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 07/06/2024 05:53, Keith Thompson wrote:
>> [...]
>
>> 
>>> There is also the C++ compatibility question.  C++ provides flexible
>>> operator overloading combined with a poverty of available operators,
>>> so the relational operators <, >, <= and >= are sometimes used for
>>> completely different purposes, similar to the >> and <<
>>> operators. Chaining relational operators would complicate this
>>> significantly, I think.  If C++ adopted the feature it would be a mess
>>> to support overloading, and if they did not, "a < b < c" in C and C++
>>> would be valid but with completely different semantics.  Neither
>>> option is good.
>> I mentioned earlier that someone did a study of open source C++ code
>> and
>> found no occurrences of things like "a < b < c", except for 4 cases that
>> were intended to be chained but would behave incorrectly.  I presume
>> that this study would have covered overloaded operators.
>> 
>
> You helpfully quoted from that study, and it included :
>
> - Many instances of using successive comparison operators in DSLs that
>   overloaded these operators to give meaning unrelated to comparisons.
>
> So yes, it seems that overloading the relational operators for other
> purposes and then chaining them is a real thing.
>
>>> To me, this possibility, along with the confusion it would cause,
>>> totally outweighs any potential convenience of chained comparisons.  I
>>> have never found them helpful in Python coding, and I can't imagine
>>> them being of any interest in my C code.
>> I agree.  I wouldn't mind being able to use the feature, and I think
>> I've actually used it in Python, but its lack isn't a big problem.
>> 
>>> Even in a new language, I would not want to see chained relational
>>> operators unless you had a strict requirement that relational
>>> operators evaluate to a boolean type with no support for relational
>>> operators between booleans, and no support for comparison or other
>>> operators between booleans and other types.
>> In Python, all comparison operators (<, >, ==, >=, <=, !=, is, is
>> not,
>> in, not in) have the same precedence, and chained operations are
>> specified straightforwardly.  They evaluate to a bool result.  Boolean
>> values can be compared (False < True), which doesn't seem to cause any
>> problems.
>> https://docs.python.org/3/reference/expressions.html#comparisons
>> 
>>>                                               And even then, what is "a
>>> == b == c" supposed to mean, or "a != b != c" ?
>> "a == b && b == c", and "a != b && b != c", respectively, except
>> that b
>> is only evaluated once.
>> 
>
> If "c" is a boolean, some might think the "natural" interpretation of
> "a == b == c" is "(a == b) == c" - it is the current semantics in C.
> Some people may think that "a != b != c" should be interpreted as "(a
> != b) & (b != c) & (a != c)".

Yes, some people might be wrong.

> It's one thing to make a rigid definition of the meaning in a
> language, picking a consistent set of rules of precedence and syntax.
> It is another thing to make sure it matches up with the
> interpretations people have from normal mathematics, natural language,
> and other programming languages.  When there is a mismatch, you need
> good reasons to accept the syntax as a good language design idea - the
> more likely the misunderstanding, the stronger reasons you need.
>
> To me, the potential misunderstandings of including != in chains is
> far too high in comparison to the meagre benefits.  The use of ==
> could be clear in some situations (combined with strong type checking
> to help catch mistakes) but not others.  I could see a chain of a mix
> of < and <= making sense, or of > and >=, and occasionally being
> useful.  I don't think there is a point in allowing more than that.
>
> After all, if all you need is to avoid evaluating "b" more than once,
> you can just do:
>
> 	auto const b_ = b;

There are two separate issues here.

One is adding chained comparisons to C.  We both agree that this is
impractical because it would silently change the meaning of valid code.
(Changing the meaning of old code isn't likely to be much of an issue,
but any new code using the feature would quietly change behavior when
compiled under older C standards or when ported to C++.)

The other (arguably off-topic) is providing chained comparisons in other
languages.  Python does this well, in my opinion.  All comparison
operators have the same precedence, and the semantics of chained
comparisons are defined straightforwardly.  There are no arbitrary
restrictions, so you can write things that some people might find ugly
or confusing (if you have a language that bans ugly code, I'd like to
see it).  The meaning of `a =< b > c` or `a != b == c` is perfectly clear
once you understand the rules, and it doesn't change if any of the
operands are of type bool.  `a != b != c` *doesn't* mean
`a != b and a != c and b != c`.  (If you want to test whether all three
are unequal to each other, you can write `a != b != c != a`, though that
evalutes `a` twice.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#385766

On 07/06/2024 20:57, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 07/06/2024 11:55, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 07/06/2024 05:53, Keith Thompson wrote:
>>> [...]
>> >>
>> If "c" is a boolean, some might think the "natural" interpretation of
>> "a == b == c" is "(a == b) == c" - it is the current semantics in C.
>> Some people may think that "a != b != c" should be interpreted as "(a
>> != b) & (b != c) & (a != c)".
> 
> Yes, some people might be wrong.

While you should expect people reading code - and certainly those 
writing it - to be fairly familiar with the programming language in 
question, not everyone is an expert.  So when designing a language or 
considering its features, you have to look at what a significant 
fraction of users might get wrong.  I don't know how often people might 
get these cases wrong, but I think it has enough potential that I'd be 
very wary of allowing it - at least as an addition to C.

> 
>> It's one thing to make a rigid definition of the meaning in a
>> language, picking a consistent set of rules of precedence and syntax.
>> It is another thing to make sure it matches up with the
>> interpretations people have from normal mathematics, natural language,
>> and other programming languages.  When there is a mismatch, you need
>> good reasons to accept the syntax as a good language design idea - the
>> more likely the misunderstanding, the stronger reasons you need.
>>
>> To me, the potential misunderstandings of including != in chains is
>> far too high in comparison to the meagre benefits.  The use of ==
>> could be clear in some situations (combined with strong type checking
>> to help catch mistakes) but not others.  I could see a chain of a mix
>> of < and <= making sense, or of > and >=, and occasionally being
>> useful.  I don't think there is a point in allowing more than that.
>>
>> After all, if all you need is to avoid evaluating "b" more than once,
>> you can just do:
>>
>> 	auto const b_ = b;
> 
> There are two separate issues here.
> 
> One is adding chained comparisons to C.  We both agree that this is
> impractical because it would silently change the meaning of valid code.

Yes.

> (Changing the meaning of old code isn't likely to be much of an issue,
> but any new code using the feature would quietly change behavior when
> compiled under older C standards or when ported to C++.)
> 
> The other (arguably off-topic) is providing chained comparisons in other
> languages.

I agree that this is a different matter, and for languages that don't 
have the level of established history and practice that C does, it could 
be a lot less problematic to add chained relational operators.

>  Python does this well, in my opinion.  All comparison
> operators have the same precedence, and the semantics of chained
> comparisons are defined straightforwardly.  There are no arbitrary
> restrictions, so you can write things that some people might find ugly
> or confusing (if you have a language that bans ugly code, I'd like to
> see it).  The meaning of `a =< b > c` or `a != b == c` is perfectly clear
> once you understand the rules, and it doesn't change if any of the
> operands are of type bool.  `a != b != c` *doesn't* mean
> `a != b and a != c and b != c`.  (If you want to test whether all three
> are unequal to each other, you can write `a != b != c != a`, though that
> evalutes `a` twice.)
> 

Fair enough.

I /do/ find the chained relational operators (especially mixes of 
operators) ugly - or at least, I have not had occasion to write Python 
code myself where I thought a chain would look clearer than alternatives.

But "ugly" is obviously highly subjective.  The only way to ban ugly 
code is to do as Bart has done - develop your own language and tools for 
your own personal use, and never have to consider any one else's 
opinions or preferences!

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

#385684

On 07/06/2024 10:22, David Brown wrote:

> To me, this possibility, along with the confusion it would cause, 
> totally outweighs any potential convenience of chained comparisons.
> 
> Even in a new language, I would not want to see chained relational 
> operators unless you had a strict requirement that relational operators 
> evaluate to a boolean type with no support for relational operators 
> between booleans, and no support for comparison or other operators 
> between booleans and other types.


> And even then, what is "a == b == c" 
> supposed to mean, or "a != b != c" ?

Some combinations are confusing, and in my languages I would suggest 
they are avoided (but stop short of banning them).

Ones like 'a == b == c' are straightforward: you're testing that all a, 
b, c have the same value.

With relational ops like 'a < b <= c', that means:

    a < b' && b' << c

with b' representing the same copy of b (which can be an arbitrary term) 
should be used.

However, 'a > b <= c' is not clear. While the above indicate a 
relationship between a and c when the whole expression is True, here you 
can't deduce any such relationship; all of these could be True:

   a > c, a == c, a < c

And there was one more I'd forgotten about:

    a != b != c

This looks very much like the exact opposite of ' a == b == c', but it 
isn't! (I think it would need a != b != c != a).

So the restrictions I would suggest are:

* Not mixing <, <= with >, >= in the same chain (any angle brackets
   should point the same way)

* Not allowing != in the chain.


Such a chain also requires that all 6 (or 5) operators have the same 
precedence, as you can't have 'a = b <= c' mean 'a = (b <= c)'.


 >  I
 > have never found them helpful in Python coding, and I can't imagine them
 > being of any interest in my C code.

The most common uses for me are comparing that N terms are equal (here = 
means equality):

   if x.tag = y.tag = ti64
   if a = b = 0

I also used them for range-checking:

   if a <= b <= c

until I introduced 'if b in a..c' for that purpose. (However I would 
still need 'a <= b <= c' for floating point.)

What I might then suggest for C, as a first step, is to allow only 
chained '==' comparisons. That avoids those ambiguous cases, and also 
the problem with mixed precedence, while still providing a handy new 
feature.

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

#385686

On Fri, 7 Jun 2024 11:28:23 +0100, bart wrote:

> However, 'a > b <= c' is not clear.

One thing it would have been handy to have is some way of saying

    b < a or b > c

in a chained comparison somehow. In other words, “not (a < b < c)” without 
the negation and need for the parentheses (and correspondingly for the 
obvious usages of “<=” and “>=”).

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

#385694

On Fri, 7 Jun 2024 10:45:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Fri, 7 Jun 2024 11:28:23 +0100, bart wrote:
> 
> > However, 'a > b <= c' is not clear.  
> 
> One thing it would have been handy to have is some way of saying
> 
>     b < a or b > c
> 
> in a chained comparison somehow. In other words, “not (a < b < c)”
> without the negation and need for the parentheses (and
> correspondingly for the obvious usages of “<=” and “>=”).

"Out of range" expressed as negation of "in range" looks to me as least
confusing.

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

#385691

On 07/06/2024 12:28, bart wrote:
> On 07/06/2024 10:22, David Brown wrote:
> 


> So the restrictions I would suggest are:
> 
> * Not mixing <, <= with >, >= in the same chain (any angle brackets
>    should point the same way)
> 
> * Not allowing != in the chain.
> 

I think these are good ideas.

> 
> Such a chain also requires that all 6 (or 5) operators have the same 
> precedence, as you can't have 'a = b <= c' mean 'a = (b <= c)'.
> 
> 
>  >  I
>  > have never found them helpful in Python coding, and I can't imagine them
>  > being of any interest in my C code.
> 
> The most common uses for me are comparing that N terms are equal (here = 
> means equality):
> 
>    if x.tag = y.tag = ti64
>    if a = b = 0
> 

These do not correspond to what you want to say.

If someone has balloons, and you want to check that they have 2 red 
balloons and two yellow balloons, you do start off by checking if the 
number of red balloons is the same as the number of yellow balloons, and 
then that the number of yellow balloons is 2.

Code syntax should, where practical, reflect its purpose and intent. 
You should therefore write (adjusting to C, Python, or your own syntax 
as desired) :

	if red_balloons == 2 and yellow_balloons == 2 ...

If you don't want to write the "magic number" 2 twice, you give it a name :

	expected_balloons = 2
	if red_balloons == expected_balloons
		and yellow_balloons == expected_balloons...


> I also used them for range-checking:
> 
>    if a <= b <= c
> 
> until I introduced 'if b in a..c' for that purpose. (However I would 
> still need 'a <= b <= c' for floating point.)

Using "in" and a range or interval syntax would usually be clearer, and 
closer to the intended meaning, IMHO.

Both of these chained shortcuts are used in mathematics, so they are not 
unfamiliar.  But in writing mathematics, compared to programming, you 
have a lot more freedom to expect the reader to interpret things 
sensibly, and vastly more freedom in layout while also having an 
incentive to keep things compact.  Good or common mathematical syntax 
does not necessarily translate directly to good programming syntax.

> 
> What I might then suggest for C, as a first step, is to allow only 
> chained '==' comparisons. That avoids those ambiguous cases, and also 
> the problem with mixed precedence, while still providing a handy new 
> feature.
> 

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web