S
santosh
Barry said:I nominate this for best typo of the year. Do I hear a second?
Poor Flash, unfortunately, grammar checkers aren't useful yet!
Barry said:I nominate this for best typo of the year. Do I hear a second?
Poor Flash,
unfortunately, grammar checkers aren't useful yet!
Actually, the shift operator is defined in terms of division or
multiplication, IIRC. This is just one more reason it should not
be used on negative values. Use of unsigned is safe.
Shifting left (mult) seems to be well defined for both signed andCBFalconer said:Actually, the shift operator is defined in terms of division or
multiplication, IIRC. This is just one more reason it should not
be used on negative values. Use of unsigned is safe.
All of my C implementations over the years preserve the sign on
right-shifting a signed integer. Are there any that don't?
Joe Wright said:Shifting left (mult) seems to be well defined for both signed and
unsigned integers. It is shifting right (div) which is proplematic for
negative signed integers. The question is whether the implementation
copies the sign bit into the msb of the signed value.
Consider:
11111100 a signed char with value -4
Shifting it left with yield
11111000 a signed char with value -8
Joe said:CBFalconer wrote:
.... snip ...
Shifting left (mult) seems to be well defined for both signed and
unsigned integers. It is shifting right (div) which is proplematic
for negative signed integers. The question is whether the
implementation copies the sign bit into the msb of the signed value.
Joe Wright said:Shifting left (mult) seems to be well defined for both signed and
unsigned integers.
It is shifting right (div) which is proplematic for negative signed
integers. The question is whether the implementation copies the sign
bit into the msb of the signed value.
Overflow on right shift? I expect right shift of signed integers toCBFalconer said:What about overflow during integer shifts? Not all right shifts
are arithmetic, some are also logical. Another flavor (not seen in
C systems) is through the carry.
Joe said:.... snip ...
Overflow on right shift?
I expect right shift of signed integers to preserve the sign bit.
Unsigned integers will have 0 shifted into the msb. I do miss the
carry bit from ASM days.
as noted, if that number is an integer.
I personally regard integers and non-integers as different concepts, with
different behaviors, semantics, and rules.
after all, with integers, 3/4==0, but with non-integers or reals, the answer
is 0.75...
likewise I consider reals and complexes to be different concepts.
I write whatever I write really.
Obviously.
in the past, I have never really seen any major problem with it.
if there were some problem, as I percieve it, then I probably would have
changed it long ago (before writing many hundreds of kloc using these kind
of conventions).
lengths are reals, often.
sizes of arrays are not.
counting is not.
we don't say '3.85 apples' because one of them is small, or '4.25' because
one is large...
the count is 4 apples.
I do this often as well.
for example, I have a good deal of packed-integer based types which I modify
via masks and shifts...
yes, this was a faulty thought, something I would have likely noticed and
fixed later for looking stupid...
I think it was because I was thinking of percentages, and this is the
typical way I manipulate things via percentages.
'17% of i' => '(i*17)/100'.
"i's percentage of j" '((i*100)/j)'.
would probably not say it as such, but mentally I often use shifting in
performing calculations, as I find it easier than multiplication or
division.
a buffer's size, however, is naturally constrained to being a positive
integer.
maybe...
however, I reason, almost none of my crap is ever likely to be run on
something non-x86-based, much less something so far reachingly different,
which I would unlikely even consider coding for, assuming I ever even
encountered such a beast...
the operations make sense to humans as well, if they know them...
was never saying it provably worked on negative integers.
however, it does work in what compilers I am fammiliar with.
theoretical argument, maybe, but IMO of little practical concern. I don't
think binary will go away anytime soon, as doing so would break much of the
software in existence at this point, and assuming such a change occures, it
will not matter since the mass of software would have been being
rewritten/replaced anyways.
I say though, not only is it valid for computers, but also humans...
naturally, I wouild have thought in one of the options I originally provided
'((i*81)/100)'.
why: because this value, as it so happens, does not have an integer
reciprocal.
ok, abstraction failing, it uses a 16 bit int.
very often, this is how I reason about some things.
'unsigned integer' is longer to type, however in context I repeatedly
indicate that the numbers are positive, an indication that, whether the
storage is an integer or unsigned integer, the value is constrained to be
positive.
'23>>1' is '11' regardless of it being an int or uint.
well, this is usenet, not ones' codebase.
x^2 is a curve.
2^x is a curve.
x^0.5 is a curve.
x is not, it is linear, and thus not a curve.
I was talking about fractions or rationals here.
humans have a convention that division of 2 integers leads to a non-integer
rather than an integer, and that computers do not is a difference. it shows
that integers are not numbers in a strictly traditional sense, because the
behavior is different.
representation is value, and implementation is definition...
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.