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

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

New C operator -- would it be a good idea?

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

Contents

  New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-10 12:48 -0700
    Re: New C operator -- would it be a good idea? "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2012-09-11 14:27 -0400
      Re: New C operator -- would it be a good idea? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-09-11 16:53 -0700
    Re: New C operator -- would it be a good idea? Kaz Kylheku <kaz@kylheku.com> - 2012-09-11 19:24 +0000
      Re: New C operator -- would it be a good idea? "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2012-09-11 15:56 -0400
        Re: New C operator -- would it be a good idea? Keith Thompson <kst-u@mib.org> - 2012-09-11 14:15 -0700
        Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-11 15:56 -0700
          Re: New C operator -- would it be a good idea? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-12 00:56 -0700
            Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-12 10:55 +0100
              Re: New C operator -- would it be a good idea? "io_x" <a@b.c.invalid> - 2012-09-13 07:47 +0200
                Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-13 10:47 +0100
      Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-11 15:25 -0700
        Re: New C operator -- would it be a good idea? David Brown <david@westcontrol.removethisbit.com> - 2012-09-12 09:39 +0200
          Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-12 08:33 -0700
            Re: New C operator -- would it be a good idea? David Brown <david@westcontrol.removethisbit.com> - 2012-09-13 09:53 +0200
      Re: New C operator -- would it be a good idea? falk@rahul.net (Edward A. Falk) - 2012-09-12 17:43 +0000
        Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-12 15:35 -0700
        Re: New C operator -- would it be a good idea? Ike Naar <ike@iceland.freeshell.org> - 2012-09-13 06:34 +0000
          Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-13 11:47 +0100
        Re: New C operator -- would it be a good idea? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-13 23:52 -0700
          Re: New C operator -- would it be a good idea? Ike Naar <ike@iceland.freeshell.org> - 2012-09-14 07:53 +0000
            Re: New C operator -- would it be a good idea? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-14 11:46 +0100
              Re: New C operator -- would it be a good idea? JohnF <john@please.see.sig.for.email.com> - 2012-09-14 13:17 +0000
            Re: New C operator -- would it be a good idea? John Bode <jfbode1029@gmail.com> - 2012-09-14 11:35 -0700
          Re: New C operator -- would it be a good idea? Keith Thompson <kst-u@mib.org> - 2012-09-14 02:04 -0700
          Re: New C operator -- would it be a good idea? Kaz Kylheku <kaz@kylheku.com> - 2012-09-14 21:11 +0000
        Re: New C operator -- would it be a good idea? Ben Pfaff <blp@cs.stanford.edu> - 2012-09-14 11:39 -0700
    Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-11 22:32 +0100
      Re: New C operator -- would it be a good idea? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-11 15:19 -0700
    Re: New C operator -- would it be a good idea? gordonb.22y0w@burditt.org (Gordon Burditt) - 2012-09-11 17:27 -0500
      Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-11 18:51 -0700
        Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-12 10:49 +0100
        Re: New C operator -- would it be a good idea? Greg Martin <greg@softsprocket.com> - 2012-09-12 23:23 -0700
          Re: New C operator -- would it be a good idea? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-13 12:08 +0100
            Re: New C operator -- would it be a good idea? Keith Thompson <kst-u@mib.org> - 2012-09-13 15:20 -0700
        Re: New C operator -- would it be a good idea? gordonb.h093l@burditt.org (Gordon Burditt) - 2012-09-14 15:13 -0500
    Re: New C operator -- would it be a good idea? Rui Maciel <rui.maciel@gmail.com> - 2012-09-14 20:38 +0100

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

#26333

On 2012-09-14, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> ?????? ??? ?????, 12 ??????? 2012 18:43:10 UTC+1, ??? Edward A. Falk:
>> (Although I wouldn't mind built-in abs(), min(), and max() functions, I admit
>> it's too late for even those.)
>> 
> You could have |x| syntax. That would look a bit more mathematical. 

In combination with the '|' and '||' operators it would lead
to ambiguous syntax, e.g.

  |x||y||z|

could parse as

  abs(x || y || z)

or as

  abs(x) | y | abs(z)

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

#26340

Ike Naar <ike@iceland.freeshell.org> writes:

> On 2012-09-14, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>> ?????? ??? ?????, 12 ??????? 2012 18:43:10 UTC+1, ??? Edward A. Falk:
>>> (Although I wouldn't mind built-in abs(), min(), and max() functions, I admit
>>> it's too late for even those.)
>>> 
>> You could have |x| syntax. That would look a bit more mathematical. 
>
> In combination with the '|' and '||' operators it would lead
> to ambiguous syntax, e.g.
>
>   |x||y||z|
>
> could parse as
>
>   abs(x || y || z)
>
> or as
>
>   abs(x) | y | abs(z)

Not if they were treated like other C tokens.  C has a rule that causes
its lexer to recognise the longest sequence of characters that make up a
valid token.  Thus |x||y||z| must be seen as this sequence of tokens: |,
x, ||, y, ||, z, and |.  Depending on the syntax, that would either be
an error (if |...| expressions can't not contain || operators) or it
would parse as your first example.

-- 
Ben.

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

#26344

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Ike Naar <ike@iceland.freeshell.org> writes:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>>> 
>>> You could have |x| syntax. That would look a bit more mathematical. 
>>
>> In combination with the '|' and '||' operators it would lead
>> to ambiguous syntax
> 
> Not if they were treated like other C tokens.  C has a rule that causes
> its lexer to recognise the longest sequence of characters that make up a
> valid token.

This just wasn't a great idea in the first place.
Even mathematical notation usually doesn't split
a single operator into two pieces. Besides |x|
(and ||x|| if you think that's different), nothing
else is occurring to me, offhand. abs( ) is way better.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#26354

On Friday, September 14, 2012 2:53:15 AM UTC-5, Ike Naar wrote:
> On 2012-09-14, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> > ?????? ??? ?????, 12 ??????? 2012 18:43:10 UTC+1, ??? Edward A. Falk:
> >> (Although I wouldn't mind built-in abs(), min(), and max() functions, I admit
> >> it's too late for even those.)
> >> 
> > You could have |x| syntax. That would look a bit more mathematical. 
> 
> In combination with the '|' and '||' operators it would lead
> to ambiguous syntax, e.g.
> 
>   |x||y||z|
> 
> could parse as
> 
>   abs(x || y || z)
> 
> or as
> 
>   abs(x) | y | abs(z)

Well, there's the question of where |x| would fit in the expression hierarchy; 
should it be classed as primary expression, postfix expression, cast 
expression, what?  That would determine how it would be parsed.

C just wasn't designed with an eye towards mathematical notation, though. 
I agree with Keith; use a keyword as the operator, and then it would
slip in very nicely with other unary operators:

unary-expression:
    postfix-expression
    '++' unary-expression
    '--' unary-expression
    unary-operator cast-expression
    'sizeof' unary-expression
    'sizeof' '(' type-name ')'
    '_Alignof' '(' type-name ')'
    'abs' unary-expression

It's just a question of how much demand there would be for such a feature.  

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

#26334

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> בתאריך יום רביעי, 12 בספטמבר 2012 18:43:10 UTC+1, מאת Edward A. Falk:
>> In article <20120911115303.248@kylheku.com>,
>> (Although I wouldn't mind built-in abs(), min(), and max() functions,
>> I admit it's too late for even those.)
>> 
> You could have |x| syntax. That would look a bit more mathematical. 

I doubt that it would be possible to add that syntax without
conflicting with the existing "|" and "||" operators.  I'm nearly
certain that it would, at the very least, cause confusion.

There's no reason you couldn't add new operators whose symbols happen
to be keywords.  "sizeof", at least when applied to an expression,
is a unary operator like "-", "~", or "!".

For example, a "min" operator might have the syntax `x min y`.
To apply it to multiple values, just write `x min y min z`, which
would be equivalent to `(x min y) min z`.  "abs" could be a unary
operator rather than a built-in function; in that case, both `abs x`
and `abs(x)` would be valid.

Presumably the new keywords would have to be something like _Abs,
_Min, and _Max, with a new header defining appropriate macros.

I'm not necessarily saying these *should* be added to the language,
just speculating about a way it could be done.

-- 
Keith Thompson (The_Other_Keith) kst-u@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]

#26368

On 2012-09-14, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> בתאריך יום רביעי, 12 בספטמבר 2012 18:43:10 UTC+1, מאת Edward A. Falk:
>> In article <20120911115303.248@kylheku.com>,
>> 
>> 
>> (Although I wouldn't mind built-in abs(), min(), and max() functions, I admit 
>> it's too late for even those.)
>> 
> You could have |x| syntax. That would look a bit more mathematical. 

Yes, nothing is more important than /looking/ mathematical, even while the
underlying semantics of the expression blows up whenever something hits
INT_MAX.

How about |x|, where x == INT_MIN, and INT_MIN is something like -32768 under
a 16 bit int. Oops!

Looking mathematical, very funny!

You know, none of these idiotic operators being proposed are going to make
one iota of difference to the overall productivity of C development.
These are just syntactic sugars that operate on a microscopic scale.

Language features which can make some kind of game changing difference
are those which reshape the organization of the program on a larger scale.

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

#26355

falk@rahul.net (Edward A. Falk) writes:

> (Although I wouldn't mind built-in abs(), min(), and max() functions, I admit
> it's too late for even those.)

Old versions of GNU C++ had <? and >? operators for min and max,
though they've been removed from current versions.

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

#26223

"mike3" <mike4ty4@yahoo.com> wrote in message 
news:fe55af6c-8fd3-4130-9a6e-6838ff600111@q7g2000pbj.googlegroups.com...
> Hi.
>
> I was wondering about this. I saw this posting on this site:
>
> http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-operator
>
> where they were mentioning a fake "operator", an artifact of how the C
> language is interpreted, that looked like it caused the value of a
> variable to "go to" another. Namely, "x --> 0" in the code was just
> "x-- > 0", giving it the appearance of having the effect of
> "incrementing x toward 0". Now, I was wondering: would this be a good
> idea for a new real operator for the C language? Namely, "a -->
> b" (and "b <-- a") as real operators that could increment a toward b.
> Or would it be pretty worthless?

Why do you need two versions? (Namely, --> and <--).

Do you mean the operator increments an lvalue so that it converges towards 
another given value?

This can be done using:

 a += sign(b-a);

where sign() returns (-1,0,1) depending on whether it's argument is 
negative, zero or positive.

I doubt whether sign() is already lurking in the standard library somewhere 
(a version that takes an integer argument), but if not, that sounds a far 
more useful addition. And using function syntax, can also easily be added as 
a user function without having to hang about a couple of decades until it's 
part of the language (or, more likely, until it's not).

-- 
Bartc 

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

#26225

בתאריך יום שלישי, 11 בספטמבר 2012 22:33:30 UTC+1, מאת Bart:
> "mike3" <mike4ty4@yahoo.com> wrote in message 
> 
> I doubt whether sign() is already lurking in the standard library somewhere 
> 
It's a missing macro. min, max, PI, uniform, clamp, lerp and round should all 
have been inthe original language, along with sign.

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

#26227

> http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-operator
> 
> where they were mentioning a fake "operator", an artifact of how the C
> language is interpreted, that looked like it caused the value of a
> variable to "go to" another. 

You mean, like an assignment statement?

> Namely, "x --> 0" in the code was just
> "x-- > 0", giving it the appearance of having the effect of
> "incrementing x toward 0". 

That doesn't make a lot of sense.  What's the difference
between "incrementing x toward 0" and "decrementing x toward 0",
and if there is no difference, why not?  And what's the difference
between either of them and "decrementing x toward Paris, France"?

> Now, I was wondering: would this be a good
> idea for a new real operator for the C language? 

No.  a-->b already has a defined meaning.  An important consideration
for standards is not breaking existing code.

As far as I know, nothing conflicts with using :=: as an operator,
as in:
	b :=: a;
which might or might not mean to take the reciprocal of the
base-pi logarithm of each value, then swap them.  How did we
possibly get along without that?

> Namely, "a -->
> b" (and "b <-- a") as real operators that could increment a toward b.

Please define "increment a toward b", without using the phrases
"increment toward", "decrement toward", or "crement toward" (which
I'll assume mean "a suffusion of Ankylosaurus poop") in the
definition.  What happens if a and b are equal?  What happens if b
is NaN?  (I am assuming this operator can apply to floating-point
numbers as well).  What happens if a = 1.25 and b = 1.0?  Does a
become 0.25?  (increment a toward *and possibly past* b)?  What
happens if b is +Inf (and floating-point) and a is INT_MAX (and
of type int?)

> Or would it be pretty worthless?

There are very few places I can think I'd want to use this,
even if it didn't break existing code.

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

#26230

On Sep 11, 4:27 pm, gordonb.22...@burditt.org (Gordon Burditt) wrote:
> >http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-o...
>
> > where they were mentioning a fake "operator", an artifact of how the C
> > language is interpreted, that looked like it caused the value of a
> > variable to "go to" another.
>
> You mean, like an assignment statement?
>

No, more like causing the value of one to change incrementally toward
that of another (though in this case, the second "operand" was a
constant integer literal and not a variable...).

> > Namely, "x --> 0" in the code was just
> > "x-- > 0", giving it the appearance of having the effect of
> > "incrementing x toward 0".
>
> That doesn't make a lot of sense.  What's the difference
> between "incrementing x toward 0" and "decrementing x toward 0",
> and if there is no difference, why not?  And what's the difference
> between either of them and "decrementing x toward Paris, France"?
>

True, my wording isn't quite right. Think about "stepping x closer to
0".

> > Now, I was wondering: would this be a good
> > idea for a new real operator for the C language?
>
> No.  a-->b already has a defined meaning.  An important consideration
> for standards is not breaking existing code.
>

So we could use "==>" instead.

> As far as I know, nothing conflicts with using :=: as an operator,
> as in:
>         b :=: a;
> which might or might not mean to take the reciprocal of the
> base-pi logarithm of each value, then swap them.  How did we
> possibly get along without that?
>

So you've never encountered a situation in which you have to step
the value of a variable closer to that of another?

Oen situation, and the one that inspired this post, along with the
discusson on stackoverflow, is that of looping or moving between two
coordinate points. Suppose you have coordinates x0 and x1 and want to
move between them. Let x be your current position. To move in a unit
step
toward x1:

x --> x1; (or x ==> x1;)

To move the other way, toward x0:

x --> x0; (or x ==> x0;)

or, perhaps if you think of this as "backwards" movement,

x0 <-- x; (or x0 <== x;)

Note that with this, the order of x0 and x1 does not matter,
which is the point here. You don't have to swap them or check
their order or something like that in order to move x toward
one or the other. E.g. if x1 > x0 you can move toward x0
with the same operator as if x1 were < x0, regardless of the
value of x.

> > Namely, "a -->
> > b" (and "b <-- a") as real operators that could increment a toward b.
>
> Please define "increment a toward b", without using the phrases
> "increment toward", "decrement toward", or "crement toward" (which
> I'll assume mean "a suffusion of Ankylosaurus poop") in the
> definition.  What happens if a and b are equal?  What happens if b
> is NaN?  (I am assuming this operator can apply to floating-point
> numbers as well).  What happens if a = 1.25 and b = 1.0?  Does a
> become 0.25?  (increment a toward *and possibly past* b)?  What
> happens if b is +Inf (and floating-point) and a is INT_MAX (and
> of type int?)
>

crement a toward b :)

Heh. What it means is to step a by a unit step, same size as ++
or -- (i.e. by 1), in the direction that brings the value of a
closer to the value of b, or leaves a unchanged if a == b.

I suspect it wouldn't work so well for floats, and would probably
have to be limited to integer types. Though I suppose one could
make it so that in your example if we took a --> b we'd get
a = 1.0 at the end, i.e. step by 1s, but if the result is within
1 of b, then make the result equal to b. Though what to do if a
is an integer??? Perhaps make it so that a can be stepped to within
1 of b, and then it stops there just as if a == b. Though, I wonder,
how'd we handle something like b = 1.5e+9 and b is a 32-bit float?
Step to the rounded value of 1,500,000,000? And don't forget
issues related to the binary nature of the floats... Oy, this is
a problem. Perhaps it'd be best if it required a and b to be of the
same type.

And I suspect it wouldn't be as useful for floats as for integers
unless there were some way to control the size of the step.

> > Or would it be pretty worthless?
>
> There are very few places I can think I'd want to use this,
> even if it didn't break existing code.

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

#26234

"mike3" <mike4ty4@yahoo.com> wrote in message
news:139157db-a214-4080-9615-d521e06a773b@rq1g2000pbb.googlegroups.com...
> On Sep 11, 4:27 pm, gordonb.22...@burditt.org (Gordon Burditt) wrote:

>> As far as I know, nothing conflicts with using :=: as an operator,
>> as in:
>>         b :=: a;
>> which might or might not mean to take the reciprocal of the
>> base-pi logarithm of each value, then swap them.  How did we
>> possibly get along without that?
>>
>
> So you've never encountered a situation in which you have to step
> the value of a variable closer to that of another?

Hardly ever. More common is to have to choose between ++ and -- depending on
some condition known at runtime. And it's usually treated like this:

 incr = cond?1:-1;

 a += incr;

Not quite the same as your operator, as it doesn't check that it's reached
some limit and so stops incrementing/decrementing. But as part of a loop
that takes care of termination, it will be faster than yours. (Your operator
will anyway still need loop control to be added.)

> Oen situation, and the one that inspired this post, along with the
> discusson on stackoverflow, is that of looping or moving between two
> coordinate points. Suppose you have coordinates x0 and x1 and want to
> move between them. Let x be your current position. To move in a unit
> step
> toward x1:
>
> x --> x1; (or x ==> x1;)
>
> To move the other way, toward x0:
>
> x --> x0; (or x ==> x0;)
>
> or, perhaps if you think of this as "backwards" movement,
>
> x0 <-- x; (or x0 <== x;)

It's more likely that you'd want to move between two 2D points: if you have
two points (or vectors) p and q, and want a third point r to move from p to
q, one way is:

 r = p;
 incr = (q-p)/nsteps;    // obviously no longer C at this point

 r+=incr;  // repeated nsteps times

This would normally use floating point ; with integer arithmetic (discrete
pixels), then there are a bunch of other problems, because the pixel
increments will be uneven in x and y (it needs the line drawing algorithm).
That would make the use of "-->" awkward too:

 r --> q;  // won't work in C; q is a point

 r.x --> q.x;
 r.y --> q.y;

These latter two won't work, as there will be a different number of steps
for each (and r moves at 45 degree angles).

> And I suspect it wouldn't be as useful for floats as for integers
> unless there were some way to control the size of the step.

Actually it sounds like it could be more useful for floats, and vectors as
in my example. But inefficient compared with alternatives, because you'd
need to specify the step at each step.

It seems it ought to be part of a loop control, with having to specify what
looks like a terminating condition, and possibly a step, but without
actually having the power to break out of a loop. That means you'd need a
normal loop condition on top.

-- 
Bartc 

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

#26286

>
> crement a toward b :)
>
> Heh. What it means is to step a by a unit step, same size as ++
> or -- (i.e. by 1), in the direction that brings the value of a
> closer to the value of b, or leaves a unchanged if a == b.
>

If it ever came up this or some permutation would seem to work:

x < y ? --y : (x > y ? ++y : y);

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

#26296

Greg Martin <greg@softsprocket.com> writes:

>>
>> [in]crement a toward b :)
>>
>> Heh. What it means is to step a by a unit step, same size as ++
>> or -- (i.e. by 1), in the direction that brings the value of a
>> closer to the value of b, or leaves a unchanged if a == b.
>>
>
> If it ever came up this or some permutation would seem to work:
>
> x < y ? --y : (x > y ? ++y : y);

A much more useful fictitious operator was recently discussed: the
compare operator <>.  In terms of this, you'd just write

  x += y <> x;

-- 
Ben.

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

#26325

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Greg Martin <greg@softsprocket.com> writes:
>>> [in]crement a toward b :)
>>>
>>> Heh. What it means is to step a by a unit step, same size as ++
>>> or -- (i.e. by 1), in the direction that brings the value of a
>>> closer to the value of b, or leaves a unchanged if a == b.
>>>
>>
>> If it ever came up this or some permutation would seem to work:
>>
>> x < y ? --y : (x > y ? ++y : y);
>
> A much more useful fictitious operator was recently discussed: the
> compare operator <>.  In terms of this, you'd just write
>
>   x += y <> x;

Perl has this operator, but spells it <=>.  It's commonly referred to as
the "spaceship operator".  It yields -1, 0, or 1 depending on whether
it's left operand is less than, equal to, or greater than its right
operand.  (If either operator is a NaN, it yields undef, a false scalar
value distinct from 0; C doesn't have such a thing.)

-- 
Keith Thompson (The_Other_Keith) kst-u@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]

#26361

> So you've never encountered a situation in which you have to step
> the value of a variable closer to that of another?

Step *by 1*, I don't think so.  Step *halfway* has come up (binary
search).  And the case where the value doesn't change is something
that almost always needs to be carefully avoided as an error or
termination condition, otherwise the code will likely infinite loop.
Having to have a separate test somewhat reduces the utility of it
as a single operator.  And there's probably going to be two forms
of tests, one which lets the loop continue through a==b and one
which stops on the prior iteration.

It might be more useful if the value of the expression (not what
gets put in a) is 0 if a changed and 1 if not (floating point needs
a clearer termination condition here), thereby making
	while (a-->b) { ... }
useful.

>> Please define "increment a toward b", without using the phrases
>> "increment toward", "decrement toward", or "crement toward" (which
>> I'll assume mean "a suffusion of Ankylosaurus poop") in the
>> definition.  What happens if a and b are equal?  What happens if b
>> is NaN?  (I am assuming this operator can apply to floating-point
>> numbers as well).  What happens if a = 1.25 and b = 1.0?  Does a
>> become 0.25?  (increment a toward *and possibly past* b)?  What
>> happens if b is +Inf (and floating-point) and a is INT_MAX (and
>> of type int?)
>>
> 
> crement a toward b :)
> 
> Heh. What it means is to step a by a unit step, same size as ++
> or -- (i.e. by 1), in the direction that brings the value of a
> closer to the value of b, or leaves a unchanged if a == b.

That has interesting implications for floating-point values.
If a = 3.500001 and b = 3.0, then a-->b results in a being
2.500001 .  Do it again and a is, um, what?  3.0?  2.500001?
3.500001?  Having it bounce back and forth between two values due
to an unexpected rounding error somewhere else in the calculation
makes it hard to use correctly (for floats).

Also think about how it would work for pointers, although this
case isn't that different from integers.


> I suspect it wouldn't work so well for floats, and would probably
> have to be limited to integer types. Though I suppose one could
> make it so that in your example if we took a --> b we'd get
> a = 1.0 at the end, i.e. step by 1s, but if the result is within
> 1 of b, then make the result equal to b. Though what to do if a
> is an integer??? Perhaps make it so that a can be stepped to within
> 1 of b, and then it stops there just as if a == b. Though, I wonder,
> how'd we handle something like b = 1.5e+9 and b is a 32-bit float?

Well, b++ has the same problem.  It may not change the value of b
at all.

> Step to the rounded value of 1,500,000,000? And don't forget
> issues related to the binary nature of the floats... Oy, this is
> a problem. Perhaps it'd be best if it required a and b to be of the
> same type.

You still have many of the same issues if a and b are of the same
floating-point type, just very far apart.  a=1.5e+9 and b=0,
for example.

> And I suspect it wouldn't be as useful for floats as for integers
> unless there were some way to control the size of the step.

I think the step size issue is important for integers also.

>> > Or would it be pretty worthless?
>>
>> There are very few places I can think I'd want to use this,
>> even if it didn't break existing code.

There is a cost to extending C, getting it closer and closer to
the point where C has no possible syntax errors (because every
possible syntax error has been used as an extension).  It's paid
by people who don't want to use the extensions as well as those 
who do.

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

#26359

mike3 wrote:

> Now, I was wondering: would this be a good
> idea for a new real operator for the C language? Namely, "a -->
> b" (and "b <-- a") as real operators that could increment a toward b.
> Or would it be pretty worthless?

Your suggestion appears to be a solution looking for a problem.

If you wish to iterate through a statement based on how a couple of floating 
point values compare between themselves then you already have at least two 
concise ways of doing it: the while() statement and the for() statement.


Rui Maciel

[toc] | [prev] | [standalone]

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

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

csiph-web