On Sep 11, 4:27*pm, (E-Mail Removed) (Gordon Burditt) wrote:

> >http://stackoverflow.com/questions/1...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.