can we compare two integers without using relational operators

[Richard Heathfield]

Zara said:

Apart from the other comments, there is no function called 'unsigned' in C.

 

[Jordan Abel]

Of course, should this question really come up in a job interview, the
correct answer would be along the lines of "I'm sorry, but I don't want
to work here any more. I'd rather mow lawns than write that kind of
code. Goodbye, Mr. Ballmer."

But then he would F*ing Kill You [tm], He Has Done It Before And He
Will Do It Again - all kidding aside, it's an interview question,
not a serious proposed program design.

 

[Jordan Abel]

My current computer is a DS9001 ultra turbo, with the compiler ecc (evil c
compiler) version 11.7.8.5.1.3.

sizeof (char) = 1
CHAR_BITS = 11

The rightmost bit is a signbit, and the other 10 bits forms the value.
"Negative Zero" is the trap value of course.

1 is encoded as 00000 00001 0
-1 as 00000 00001 1

and so on...

(could the above conform to the standard?)

/Niklas Norrthon

No. -1 would have to be represented as any of the three:

10000000001 signed-magnitude
11111111110 ones complement
11111111111 twos complement

In general, the sign bit has to be at the 'left' (i.e MSB for unsigned)

 

[Skarmander]

I don't think that anyone else has yet pointed out that == and !=
are not relational operators, so there it is. (They are equality
operators.)

That's a nice gotcha. I see the standard defines them in exactly this
way. Mathematically, of course, equality and inequality are
relationships. The standard itself acknowledges this in 7.12.14, while
maintaining the terminology distinction.

Interestingly, the standard slips up in Appendix F: heading F.8.3 reads
"relational operators", but != and == are discussed. This should have
been "relational and comparison operators" for full consistency.

"Comparison operators" seems to be a reasonable name for both equality
operators and relational operators. Though, of course, this is all
nitpicking and nobody will be confused as long as you're spelling out
the operators, which will almost always be the case.

S.

 

[Richard Bos]

Of course, should this question really come up in a job interview, the
correct answer would be along the lines of "I'm sorry, but I don't want
to work here any more. I'd rather mow lawns than write that kind of
code. Goodbye, Mr. Ballmer."

But then he would F*ing Kill You [tm], He Has Done It Before And He
Will Do It Again - all kidding aside, it's an interview question,
not a serious proposed program design.

Yes, and all kidding aside, if a prospective employer thinks that this
is a question worth asking in a job interview I would think twice about
accepting a job there, because I would apparently have to work under a
management that does not understand what programming is about.

Richard

 

[Michael Mair]

No. -1 would have to be represented as any of the three:

10000000001 signed-magnitude
11111111110 ones complement
11111111111 twos complement

In C89, sign-(magnitude - 1) also is possible as any true binary
representation is allowed, so
10000000000
is in the game as well, as may be others.
C99 indeed restricts it to the three above.

Cheers
Michael

 

[Jordan Abel]

In C89, sign-(magnitude - 1) also is possible as any true binary
representation is allowed, so
10000000000
is in the game as well, as may be others.
C99 indeed restricts it to the three above.

On looking at "c88" [which is what i've decided to call the c89
draft that's floating around], it appears that nothing is specified
at all (the actual standard may specify, but the draft does not)
except for the presence of evidence that none of the committee had
even conceived of the possibility that the sign might be elsewhere
than at the left.

so in theory it could be something oddball like 11000000000 - the
only thing that appears to be specified about negative numbers is
that the MSB is 1.

 

[Keith Thompson]

Of course, should this question really come up in a job interview, the
correct answer would be along the lines of "I'm sorry, but I don't want
to work here any more. I'd rather mow lawns than write that kind of
code. Goodbye, Mr. Ballmer."

But then he would F*ing Kill You [tm], He Has Done It Before And He
Will Do It Again - all kidding aside, it's an interview question,
not a serious proposed program design.

Yes, and all kidding aside, if a prospective employer thinks that this
is a question worth asking in a job interview I would think twice about
accepting a job there, because I would apparently have to work under a
management that does not understand what programming is about.

I disagree. Obviously if I were asked to do such a thing in a real
program, I'd have serious questions. But it's a reasonable test of a
candidate's problem-solving ability. A good candidate should be able
both to explain that it's a stupid thing to do in real code *and* to
come up with at least a partial solution.

Any problem-solving exercise that can be stated briefly but that
doesn't have a simple solution is likely to be contrived. Someone who
can figure this one out is more likely to be able to solve real-world
problems of comparable difficulty that are too complex to go over in a
job interview.

 

[Dave Thompson]

On 2005-10-26, Niklas Norrthon <[email protected]> wrote:

No. -1 would have to be represented as any of the three:

10000000001 signed-magnitude
11111111110 ones complement
11111111111 twos complement

In general, the sign bit has to be at the 'left' (i.e MSB for unsigned)

Yes and no. All value (magnitude) bits of the signed representation
must must have the same weights in unsigned so that all positive
signed numbers have the same representation as unsigned. The bit that
is the sign in signed may go unused (padding) in unsigned. If it is
used it must be _more_ significant than the 'common' value bits; it
still need not be _most_ significant if there are padding bits unused
in signed but used for value in unsigned, but that seems perverse.

- David.Thompson1 at worldnet.att.net

 

[Jordan Abel]

Yes and no. All value (magnitude) bits of the signed representation
must must have the same weights in unsigned so that all positive
signed numbers have the same representation as unsigned. The bit that
is the sign in signed may go unused (padding) in unsigned. If it is
used it must be _more_ significant than the 'common' value bits; it
still need not be _most_ significant if there are padding bits unused
in signed but used for value in unsigned, but that seems perverse.

- David.Thompson1 at worldnet.att.net

The c89 standard, or at least the draft i have a copy of, is not
explicit about signed representation, but anywhere it talks about a bit
which may be a sign bit, it says "the high-order bit" - which tells me
that by 1988 nobody had thought of the possibility that signed values
might be represented in a way that had the sign bit anywhere other than
"the high-order bit".