Even-Odd sorting

[Jerry Coffin]

Re: Even-Odd sorting

In article <MPG.22a1d098f0 1bef2989cdd@new s.sunsite.dk>,
jcoffin@taeus.c om says...

[ one's complement, two's complement, sign/magnitude and 'i&1' ]

It's always true in those three representations .

Thinking about it a moment longer, that's not true. It works on
sign/magnitude and two's complement, but breaks on one's complement.

So, the original suggestion breaks on two's complement, and my version
breaks on one's complement. At least for me, one's complement machines
fall into that category that I feel fairly safe ignoring -- and I'm one
of probably fewer than a half dozen regular participants here who's
actually worked on a machine that used one's complement for integers.

In theory, I can also see the remote possibility of a biased
representation, in which the bias was odd, where it would also break. I
can't quite imagine anybody doing that though: given the requirement
that non-negative signed numbers and unsigned numbers have the same
representation, you'd need to use the same bias on unsigned numbers as
well, and making math on those work correctly seems a bit cumbersome
(about the only obvious way I can think of would be to remove the bias,
do the math, then reapply the bias). Of course, such a representation
isn't allowed under either C99 or C++ 0x (except under the as-if rule,
if the implementation made it always act like an allowed representation,
of course).

--
Later,
Jerry.

The universe is a figment of its own imagination.

[jason.cipriani@gmail.com]

Re: Even-Odd sorting

On May 24, 4:14 am, Dario Saccavino <kath...@gmail. comwrote:

Some people in this thread have suggested comparison operators that
rely on the result of (i%2) being either 0 or 1, but this may be false
in case the number is negative.

Victor Bazarov's:

and an alternative suggested by Jerry Coffin:

What am I, chopped liver? :_(

<g>

Jason

[Aitch]

Re: Even-Odd sorting

On May 25, 4:02 am, "jason.cipri... @gmail.com"
<jason.cipri... @gmail.comwrote :

On May 24, 4:14 am, Dario Saccavino <kath...@gmail. comwrote:
>

Some people in this thread have suggested comparison operators that
rely on the result of (i%2) being either 0 or 1, but this may be false
in case the number is negative.
Victor Bazarov's:
and an alternative suggested by Jerry Coffin:

>
What am I, chopped liver? :_(
>
<g>
>
Jason

try this
class EvenOddSorting {
public:
bool operator()(cons t int i, const int j) const {
return (i % 2 == 0 && j % 2 != 0) || ((i + j) % 2 == 0 && (i
< j));
}

};

btw:
the original code have some problem when gcc compile it. output is 10,
7, the size of intSet is 2.
I guess that the gcc's set implementation compare number i and j by
if(!( compare(i,j) && compare(j,i) ) return; so 10 == 18, and 3 == 5
== 7 under the comparator.

[Daniel Pitts]

Re: Even-Odd sorting

Jerry Coffin wrote:

In article <odd-20080524104954@ ram.dialup.fu-berlin.de>, ram@zedat.fu-
berlin.de says...
>
[ ... ]
>

> A function to tell whether a number is odd, might be written
> as follows.
>>
>inline odd( int const i ){ return( i >= 0 ? i : -i )% 2; }
>>
> or
>>
>inline odd( int const i ){ return( i >= 0 ? i : -i )& 1; }
>>
> As you wrote, whether one of them is faster can only be
> determined relative to a specific environment by a
> measurement.

>
Yes, but it might also be written as:
>
inline odd(int i) { return i & 1; }
>
IMO, this is simpler and more readable than either of the previous
possibilities -- and given the requirements of both C and C++, it's just
as dependable and portable as the alternatives.
>
As an aside, I'd note that all of these need a return type added --
either bool or int would work, though given the name you've chosen, bool
would be the obvious choice.
>

It might also be more correctly written as
template<typena me T>
inline bool even(const T t) { return (t % 2) == 0; }

template<typena me T>
inline bool odd(const T t) { return !even(t); }

--
Daniel Pitts' Tech Blog: <http://virtualinfinity .net/wordpress/>