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

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

Range-aware modulo operator -%

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

Contents

  Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 21:09 -0500
    Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-27 21:34 -0500
      Re: Range-aware modulo operator -% "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2018-12-28 05:37 +0100
      Re: Range-aware modulo operator -% James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-29 16:04 -0500
        Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-29 19:13 -0500
    Re: Range-aware modulo operator -% Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-28 03:05 +0000
      Re: Range-aware modulo operator -% Robert Wessel <robertwessel2@yahoo.com> - 2018-12-27 21:31 -0600
        Re: Range-aware modulo operator -% Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-28 04:20 +0000
      Re: Range-aware modulo operator -% James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 19:32 -0800
        Re: Range-aware modulo operator -% Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-28 04:18 +0000
    Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-28 12:29 +0000
      Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 08:10 -0500
        Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-28 10:25 -0500
          Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-28 15:56 +0000
            Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-28 17:26 -0500
              Re: Range-aware modulo operator -% Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2018-12-28 23:45 +0100
          Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 11:44 -0500
          Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 12:16 -0500
            Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-28 17:08 -0500
              Re: Range-aware modulo operator -% Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-28 15:01 -0800
              Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-31 09:04 -0500
                Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 18:07 +0000
                  Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-31 14:22 -0500
                    Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 21:05 +0000
                      Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-31 16:32 -0500
                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 23:43 +0000
                          Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 16:44 -0800
                            Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-01 01:06 +0000
                              Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 19:06 -0800
                                Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-01 11:32 +0000
                                  Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-01 12:48 -0800
                                    Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-01 23:54 +0000
                                      Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-01 16:09 -0800
                                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-02 00:49 +0000
                                          Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-01 17:53 -0800
                                            Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-02 02:36 +0000
                                              Leader Kiki is not going to like this... (Was: Range-aware modulo operator -%) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-02 08:36 +0000
                                              Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-02 00:38 -0800
                                      Re: Range-aware modulo operator -% rbowman <bowman@montana.com> - 2019-01-01 22:40 -0700
                                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-02 12:12 +0000
                            Re: Range-aware modulo operator -% gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-01 01:53 +0000
                      Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-31 16:57 -0500
                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 22:33 +0000
                  Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 13:34 -0800
                    Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-31 16:43 -0500
                      Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 15:20 -0800
    Re: Range-aware modulo operator -% Eduardo <abdulai60@gmail.com> - 2018-12-28 07:18 -0800
      Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 11:45 -0500

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

#139315

In article <lnd0phmcjw.fsf@kst-u.example.com>,
Keith Thompson  <kst-u@mib.org> wrote:
>Bart <bc@freeuk.com> writes:
>[...]
>> If you write if(x), while(x), or for(;x;), then it automatically applies 
>> the effective equivalent of !! to give a true (x!=0) or false (x==0) 
>> result. (The same with (x && y) and any such combinations.)
>[...]
>
>That's one way to describe it.  It's now how the standard describes it.

That's good to know.  I assume it used to describe it some other way, but
it (the standard) has now seen the light of Bart's way.  That's good.

-- 
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof. 

    - John Kenneth Galbraith -

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

#139303

On 12/31/18 4:05 PM, Bart wrote:
> On 31/12/2018 19:22, Rick C. Hodgin wrote:
> Assuming you are still using * from C, that means that for dereferencing
> a pointer to struct member, you can use:
> 
>   (*p).m
>   p->m
>   m<-p
>   [p].m
>   p~~m
> 
> For dereferencing a double pointer to a struct member, the choices are:
> 
>   (*(*q)).m
>   (*q)->m
>   m<-(*q)
>   [[q]].m
>   [q]->m
>   m<-[q]
>   q~~m       # ???
> 
> You see the problem? The syntax I use has ONE way to dereference a
> pointer (postfix "^"), and ONE way to select a member ("."):
> 
> These examples must be written
> 
>      p^.m        # one pointer level, one ^
>      q^^.m       # two pointer levels, two ^
> 
> Both access one member, so both have one ".". Take out member select:
> 
>     p^           # access the whole struct
>     q^^
> 
> Try and take out the member select part of the 10 or 12 examples in your
> syntax; you can't just remove the ".m", because most of them don't use it.
> 
> C syntax has always been a mess that way. Your additions make it worse.
> 
> 

your syntax isn't that different than C in my view.

In C *p, in your p^
Both get you 'the object pointed to by p), to which you can add more
indirection of member selection.

C adds a 'shortcut' of p->m as the syntax sugar for (*p).m

Perhaps having the indirect operation being postfix instead of prefix
cleans up some issue with syntax, getting rid of some needs of parenthesis.

For C, with the need of the parenthesis, the shortcut seems useful, and
having 2 notations doesn't seem that bad.

Rick's multitude of options seems much less useful, and I suspect he is
going to run into parsing issues with his grammar.

...

>> All variables have an implicit underscore variable form unless there
>> is an explicitly created underscore variable name in scope.  If you
>> create "char* x" there's an implicit _x which is the unsigned integer
>> equivalent value that can be used.
> 
> Say again? I expected you to say that _x means *x, some syntactic sugar.
> You mean that _x means '*(unsigned char)x'?
> 

I think Rick means that _x is like (uintptr_t)x

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

#139306

On 31/12/2018 21:57, Richard Damon wrote:
> On 12/31/18 4:05 PM, Bart wrote:

>> C syntax has always been a mess that way. Your additions make it worse.
>>
>>
> 
> your syntax isn't that different than C in my view.
> 
> In C *p, in your p^
> Both get you 'the object pointed to by p), to which you can add more
> indirection of member selection.
> 
> C adds a 'shortcut' of p->m as the syntax sugar for (*p).m
> 
> Perhaps having the indirect operation being postfix instead of prefix
> cleans up some issue with syntax, getting rid of some needs of parenthesis.

That is the crucial part. It means pointers to arrays in C would have 
been more popular if accesses could be written A^[i] ('*' wouldn't work) 
instead of (*A)[i].

Pointers to struct members could be written consistently as P^.m instead 
of either (*P).m or P->m, while adding or removing an indirection is 
just adding or removing ^, instead of having to add or remove (*) or to 
transform between -> and (*) or between -> and . or between (*) and .

And calls via function pointers could be consistently written F^(x) 
instead of (*F)(x) or via the confusing F(x).

> For C, with the need of the parenthesis, the shortcut seems useful, and
> having 2 notations doesn't seem that bad.
> 
> Rick's multitude of options seems much less useful, and I suspect he is
> going to run into parsing issues with his grammar.

Almost certainly.

-- 
bart

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

#139300

Bart <bc@freeuk.com> writes:
[...]
> Looking through your CAlive newgroup articles, I can see these new 
> operators and symbols, in addition to those above:
[...]

Oh, there's a CAlive newsgroup?

Wouldn't that be a better place to discuss CAlive than comp.lang.c *and*
comp.lang.c++?

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#139301

On 12/31/18 4:34 PM, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Looking through your CAlive newgroup articles, I can see these new 
>> operators and symbols, in addition to those above:
> [...]
> 
> Oh, there's a CAlive newsgroup?
> 
> Wouldn't that be a better place to discuss CAlive than comp.lang.c *and*
> comp.lang.c++?
> 

It isn't a 'real' NNTP newsgroup, just one of the pseudo newsgroups on,
if I remember right, googlegroups (so accessible on web through it as if
it was a newsgroup, but doesn't leave google).

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

#139308

Richard Damon <Richard@Damon-Family.org> writes:
> On 12/31/18 4:34 PM, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Looking through your CAlive newgroup articles, I can see these new 
>>> operators and symbols, in addition to those above:
>> [...]
>> 
>> Oh, there's a CAlive newsgroup?
>> 
>> Wouldn't that be a better place to discuss CAlive than comp.lang.c *and*
>> comp.lang.c++?
>
> It isn't a 'real' NNTP newsgroup, just one of the pseudo newsgroups on,
> if I remember right, googlegroups (so accessible on web through it as if
> it was a newsgroup, but doesn't leave google).

My point stands.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#139166

El jueves, 27 de diciembre de 2018, 23:07:40 (UTC-3), Rick C. Hodgin  escribió:
> I think C/C++ needs to have a range-aware modulo operator that will
> continue ranging properly when it encounters negative values.
> 
> We have this:
>      i = (i + 1) % 10;   // Always ranges 0..9
> 
> But what if you try this when i = 0:
>      i = (i - 1) % 10;
> 
> It won't produce the same result in the same pattern seen when you
> started at a positive i and tended toward 0.  It begins a new trend,
> one which is useful, but not always desirable.

Why not i = (i + 9) % 10; for decrement ?

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

#139175

On 12/28/2018 10:18 AM, Eduardo wrote:
> Why not i = (i + 9) % 10; for decrement ?

What about i - n?

-- 
Rick C. Hodgin

[toc] | [prev] | [standalone]

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

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

csiph-web