The >> operator

aw, come on, (1 | x >> 31) is classic... just don't do it with a logical shift.

Absolutely. THAT would make it "arithmetic"; the fact that it pays attention to the MEANING and FORMAT of the "number".



FIPS FS-1037C:

"Arithmetic shift: A shift, applied to the representation of a number in a fixed radix numeration system and in a fixed-point representation system, and in which only the characters representing the fixed-point part of the number are moved. An arithmetic shift is usually equivalent to multiplying the number by a positive or a negative integral power of the radix, except for the effect of any rounding; compare the logical shift with the arithmetic shift, especially in the case of floating-point representation."

Otherwise, what the hell is the point in 1) calling it "arithmetic", and 2) differentiating it from "logical"? What is "arithmetic" about -1 >> 1 == -1? or -1073741825(0xBFFFFFFF) << 1 == 2147483646(0x7FFFFFFE)? Simply put: It isn't. It's just a carry-over that we've had to deal with (by essentially NOT using it for anything but whole number representations, and EXTREMELY carefully with integers).

I'd eat someone for writing code like that on my dime. :E

Your definition for the "real meaning of arithmetic shift" is pretty damn recent. Give me something from the '60s.

Arithmetic just means that sign is preserved in the absence of overflow.

There's no point in even HAVING a shift operator except for when you're dealing with the actual bits.

Why is the 60s any more correct than "recent" (considering that FS-1037 was first drafted in 1980)?



Correct, for INTEGERS, the meaning and format of the non-numeric parts of the number is preserved for the ARITHMETIC operation being performed. Except in the case of -1 being right shifted.



So, multiplying by the radix of a number to a power in a nice, compact instruction isn't useful? O.o

Because the term had a specific meaning that was already in use before that definition was created, and that definition doesn't match what's actually in use. It's a humpty-dumpty definition.
Sure it is, but it's not a *shift*, except for the specific case of 2s complement integers in the absence of carry. If you're dealing with 1s complement, it's a mask-and-shift, for example. For floating point it's a mask-an-addition (if you don't want to end up with something like a denormalized number).

Maybe that means that what is in use is "traditional" versus "correct". Vernacular may win in the former sense, but it isn't always so in the latter. That, and we all pay the price for it in the long run with having to work around the imprecision in formal languages, such as programming languages.



What else would you call it? It is a "shift" by its very definition. You're describing what the implementations are; I'm talking about the MATH description; ie, mathematical rules, formulae, equations, proofs, etc.

What's in use is useful.

The only mathematical definition of shift is in the theory of algorithms and involves operations on a string of symbols. The mathematical term is "multiplication by an exponent of an integer".

It's not the only thing that is useful, otherwise, we'd still be using switches, vacuum tubes, and relays. Things progress from less useful to more useful over time, ya know.



A shift operation is, in its most generic sense, a serial movement of symbols some distance about its origin. In a "computer logic" or "Logical" sense, that means moving binary digits some positional distance in one of two directions. In an Arithmetic or Mathematical sense, it means moving a number some functional distance along its domain. That "function" is not specifically defined; it could be an additive shift, a multiplicative shift, an exponential shift, whatever. The effect is similar, but not identical to the "Logical" shift.

Technical language is not a vacuum tube or a relay. It's a tool for describing reality. A definition that doesn't match reality is useless.

I have never seen it used in any arithmetical sense other than when a number is being treated as a series of symbols, and the operation happens to map to a mathematical operation... and that is only used when the mapping between the symbols and the mathematical operation happens to be mathematically interesting or useful. For an extremely simple example, the mapping of numbers to a string of numerals allows you to use shifts to perform base-ten multiplication in elementary school. But you wouldn't use "shifts" to refer to modifying the exponent of a number expressed in scientific notation, even though that operation maps into the same numerical operation.

om nom nom. (not gonna have the portability debate again)

No, but technical language evolves to create better descriptions and representations of reality, just as vacuum tubes and relays gave way to transistors and integrated circuits. Better definitions and more advanced tools that give you the ability to better (and more accurately) describe reality ARE useful.



..yet programmers use it all the time in a arithmetical / mathematical sense; you can't multiply symbols, you multiply numbers. Incorrect representation and handling of numbers in a mathematical sense is an error, be it by design or use, it doesn't matter; it still is an error.

Unless you actually change the reality changing the language is pointless at best and actively dangerous at worst. "How many fingers does a man have if you call a nose a finger"? "Ten, calling a nose a finger doesn't make a nose a finger".

Where? Shift is an operation on bits. That operation happens to correspond to a mathematical transformation when those bits correspond to a single twos-complement integer, but not when those bits correspond to packed BCD symbols, to packed bytes, or to a floating point number. I can not comprehend the confusion in the mind that would lead a competent professional programmer to lose track of this fundamental fact.

Stop being obtuse. I'm not talking about redefinition, I am talking about REFINING definition. There's a big goddamned difference, ya know.



j = i << 12; // Multiply by the page size to get size in bytes

That occurs all over the effin' place, from applications, to operating systems. Shift used in a MATHEMATICAL CONTEXT. Christ.



Yes, if you are encrypting data, or shoving it out a bit at a time over a serial interface, or any number of other situations where the data is treated as NOTHING MORE than a friggin' series of symbols. Durr.

HOWEVER, if you are treating it as a MATHEMATICAL OPERATION (also known as ARITHMETIC, for those who are hard-of-thinking here), then it DOESN'T WORK RIGHT IN ALL CASES. Hence, it is ERRONEOUS.



I am not going to dignify this kind of moronic ad hominem with any further response. You wanna go at me on a personal level, take it private.

If your refined definition doesn't match the reality that people are actually working with, you're redefining language.

The purpose of this kind of comment is to indicate that the shift by 12 bits is being used to perform a multiplication, BECAUSE a shift is not automatically an arithmetic operation. You don't write "i = i + 1; // Increment i".

Incidentally, this kind of thing is often a premature optimization, and can be a sign of a sloppy programmer... as is the use of a magic number (12). I would write this as:

j = i * PAGE_SIZE;

or, if it turned out that shifting was preferable for some reason, I would write it as:

j = i << PAGE_SIZE_SHIFT;

Generally, it would be more likely to be a worthwhile optimization if it was a right-shift, if you have a particularly primitive compiler or if the shift factor was not a constant.

Note carefully, that right shift rounds to -infinity and division (in most languages) rounds towards zero:

-3 >> 1 == -2
-3 / 2 == -1 (except in some control system languages Forth77, where division is defined to always round towards -inf)