Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #139167
| Subject | Re: Range-aware modulo operator -% |
|---|---|
| Newsgroups | comp.lang.c, comp.lang.c++ |
| References | <q040h4$bie$1@dont-email.me> <tGoVD.88490$Ck1.46277@fx18.am4> <q057a5$1pr$1@dont-email.me> |
| From | Richard Damon <Richard@Damon-Family.org> |
| Message-ID | <rfrVD.120946$gU6.41087@fx33.iad> (permalink) |
| Organization | Forte - www.forteinc.com |
| Date | 2018-12-28 10:25 -0500 |
Cross-posted to 2 groups.
On 12/28/18 8:10 AM, Rick C. Hodgin wrote:
> On 12/28/2018 7:29 AM, Bart wrote:
>> On 28/12/2018 02:09, Rick C. Hodgin wrote:
>>> 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.
>>>
>>> A range-aware modulo operator would know that it should always be
>>> in the range 0..9 (from the example above), and also that it should
>>> continue the pattern seen in the positive integers, such that when
>>> given a negative input value, it handles the processing differently:
>>>
>>> // v=value, m=modulo number
>>> int range_modulo(int v, int m)
>>> {
>>> if (v >= 0) return (v % m);
>>> else return ((m + (v % m)) % m);
>>> }
In my mind, a cleaner (and actually working) version would be more like:
int modulo(int v, int m) {
int mod = v % m;
if (mod < 0) mod += m;
return mod;
}
This will work even if v is less than -m and not need multiple divide
operations. (For machines with fast divide but bad behavior for
branching, your expression (m + (v % m) % m could also be used all the
time, if you are going to use the conditional, you don't need the second
% if you do it right.
Neither of these work 'right' if m can be negative, and for that we need
to come up with a real definition of what it means to have a negative
modulus.
>>>
>>> int i;
>>> for (i = 12; i >= -12; --i)
>>> printf("%d --> mod 10 = %d\n", i, range_modulo(i, 10));
>>>
>>> -----
>>> I propose the -% symbol for the operator.
>>>
>>> It would allow things that are sometimes needed in video games,
>>> as just one example, when a player hits the left button instead
>>> of the right button, and you need it to go the other way, AND you
>>> want it to just work while using the same math.
>>
>> I used this loop to better show the differences:
>>
>> for (i = 12; i >= -12; --i) {
>> if (i==0) puts("");
>> printf("rmod(%3d,10) = %3d, %3d%%10 = %3d\n", i,
>> range_modulo(i, 10),i,i%10);
>> if (i==0) puts("");
>> }
>>
>> The % operator [which in my language is called 'rem'] shows
>> symmetrical behaviour around zero, while your range_modulo doesn't.
>>
>> Both behaviours are useful for different purposes. But the simplest
>> thing to do is to just keep it as a function, as like that it will
>> work /now/ on a hundred compilers.
>
> I think -% is a truly fundamental operation and should have operator
> support. It has utility in various cases.
There are LOTS of operations that could be argued are worthy of operator
support for some applications. There actually is a language that tried
to give them all operator symbols, the language APL. Many consider APL a
write only language, because it can be nearly impossible to read and
understand a program written in APL if you didn't just write it recently.
Rather than create a bunch of new symbols as part of the language, I
have thought it would be interesting if C++ allowed the creation of new
operators with NAMES, like operator mod(int v, int m) so you could say
something like v mod m. You would need to be able to define their
'precedence' so the compiler would know how to parse the expression, the
simplest would likely be to define them to act like and existing type of
operator, so
>
>> "-%" is unlikely to ever work on any. Apart from which, there's
>> already enough confusion as to exactly what "%" does, let alone "-%",
>> especially with the /four/ combinations of negative operands.
>>
>> (Note that when m is negative, eg. i/(-10), then both appear to have
>> the same behaviour. The modulo nature of your range_modulo disappears.
>> You may wish to use abs(m) inside that function, and perhaps re-apply
>> the sign to the result, if that is important.)
>
> Interesting. I've never used a negative value that way, so it never
> occurred to me.
>
Let me make a small comment about what I see in CAlive. It seems that
you are trying to define what you want to call a 'Language' by going
something (a bit crudely) like:
Lets start with something like C (which I don't really fully
understand), and then remove these features that don't make sense to me
so I could never make them work right.
Lets then mix in some bits of C++, but not too much, because that
langauge is so complicated that I can't understand it much of it.
Lets then add in all sorts of nifty little micro-tricks that I wish were
in C and/or C++, not worrying about how they might interact.
I can't understand formal documentation, so I can't write anything like
that myself, so I will document the language as with just a list of the
Hodge-podge rules that I built it with, but that's ok, the formal
specification will be the program I will eventually write (which I guess
means there can't be problems in the language definition, as the
language definition will be exactly as what that implementation did)
I have nothing against the idea that you want to create this new
programming environment with all the nifty bells and whistles that you
want. When (and if) it is done, it may even be useful to others, IF you
are able to produce a coherent set of documentation that tells people
how to use it. What does bother me a bit is the idea that you have that
this is somehow something very important (or should be to others). From
what I have heard you describe, your Grand Design is enormous, and very
likely beyond your reach and ability.
There actually isn't anything wrong with aiming for something you likely
can't reach, as long at the journey to it is something that can be
worthwhile (as in the story of Don Quixote). The issues come when you
try to insist that others need to follow or value your efforts.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web