Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Interval Comparisons
Date: Mon, 10 Jun 2024 16:33:12 +0100
Organization: A noiseless patient Spider
Lines: 158
Message-ID: <v476bo$h1eu$1@dont-email.me>
References: <v3merq$b1uj$1@dont-email.me>
 <pan$63fde$3c88716e$c61af1ee$d0a27c97@invalid.invalid>
 <v3o706$kfrm$2@dont-email.me> <v3o7jr$ki9u$1@dont-email.me>
 <v3of4h$pbb1$1@dont-email.me> <v3t0aa$1k8ck$2@dont-email.me>
 <v3tene$1n5ge$1@dont-email.me> <v3tlkj$1of9j$1@dont-email.me>
 <v3tqji$1t2fv$1@dont-email.me> <87bk4dz9ve.fsf@nosuchdomain.example.com>
 <v3ujg5$20s0s$1@dont-email.me> <v3unc7$20up1$1@dont-email.me>
 <v3uq8u$21i37$2@dont-email.me> <v3utuh$22afr$1@dont-email.me>
 <v443gb$3f1d5$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 10 Jun 2024 17:33:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b8a301eea9614dff910c6cbcaf87417e";
	logging-data="558558"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19JceVhpRiFSqhcQB6jt5Vl"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MynEimGvQ6RD/CdlnXeMcbDWStA=
In-Reply-To: <v443gb$3f1d5$1@dont-email.me>
Content-Language: en-GB
Bytes: 6874

On 09/06/2024 12:26, David Brown wrote:
> On 07/06/2024 14:20, bart wrote:
>> On 07/06/2024 12:17, David Brown wrote:
>>> On 07/06/2024 12:28, bart wrote:
>>>> On 07/06/2024 10:22, David Brown wrote:
>>
>>>>  >  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.
>>
>> ("you don't"?)
> 
> Yes, sorry about that!
> 
>>
>> That's not quite the intent of my examples, which is:
>>
>> (1) That x.tag/y.tag or a/b are equal to each other
>>
>> (2) That they also have a particular value
>>
> 
> If that is your intent, then fair enough.  But I think that is an 
> unusual intent.

Really,  checking that A and B both have the same value X is that unusual?

> Of course, I have no idea what "x.tag" or "ti64" 
> represent,

Here .tag contains type info, and it is checking that objects x and y 
both have type i64.

> and if I had, the code might have made more sense to me.
> 
> At least for the second example, if you did not have chaining equality, 
> I think you would have preferred to write :
> 
>      if (a = 0) and (b = 0) ...
> 
> rather than
> 
>      if (a = b) and (b = 0) ...

I think both alternates are fine if you did not have the feature being 
discussed. Although you might prefer the first if b was a more elaborate 
expression than is shown here.

It does put the onus on the compiler to ensure that repeated terms 
(there are four rather than three) is coded efficiently.

Not that the chained version can also be expressed as 'if a = 0 = b' for 
a 3-way comparison.

> If that is indeed the case, then IMHO the chaining version is less clear.
> 
>>
>>> 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 ...
>>
>> Here that connection is lost. You might infer it, but you don't know 
>> whether, at some point, the program could be changed to require 3 red 
>> balloons, while still needing 2 yellow ones.
>>
>> Or someone could just write 3 by mistake. By repeating such terms, 
>> there is more opportunity for mistakes, and the connection between 
>> terms is looser.
> 
> Sure.  If this is a risk, use a separate constant (with appropriate 
> name) for the numbers you want, and write that name rather than the 
> number 2.

If you have several such names, you can still write the wrong one!

Where you have a relationship that naturally involves 3 terms, and you 
express it with 4, then one of them needs to be repeated. But the 
language cannot enforce that extra term being one of the first three.

The programmer also now has to deal with a repeated time that might have 
side-effects.


> 
> There comes a point when a function called "all_equal", or "rising", is 
> the right choice.  How those functions might be implemented is a matter 
> of language, and also whether you want them to work with a variable 
> parameter list or over arrays, lists, slices, or whatever the language 
> supports.  High-level functions like map and reduce could be part of 
> this, along with folds.  For example, in C++ 17 (which supports a fold 
> syntax), you might write :
> 
>      template <typename H1>
>      constexpr bool rising(H1)
>      {
>          return true;
>      }
> 
>      template <typename H1, typename H2, typename ... T>
>      constexpr bool rising(H1 head1, H2 head2, T... tail)
>      {
>          return head1 <= head2 && rising(head2, tail...);
>      }
> 
> 
> Then
> 
>      rising(a, b, c, d)
> 
> is interpreted as
> 
>      a <= b && rising(b, c, d)
> 
> and so on.
> 
> 
> I don't think it is fair to claim particular ways of writing these 
> things are always clearer, or better, or uglier, or unclear - it will 
> depend on the rest of the language, and how the code is used.  But in 
> general I think it helps to write code that follows the logic of what 
> the writer really means, rather than alternative constructions that give 
> the same result.

Using function-like syntax is OK when you have the same operator between 
multiple terms. 'rising' could have '<' or '<='.

All-equal would have the same operator too, but it looks clunkier, and a 
bit over-the-top:

    a = b                2 terms
    all_equal(a, b, c)   3 terms using your feature
    a = b = c            3 terms using chained ops

    rising(a, b, c)      Using your other feature
    a <= b <= c          Using the same chained-op feature

Your solution requires a heavyweight language feature. It also looks 
like it will generate a lot of intermediate code that will need a 
heavyweight optimiser to tear down again.