How to find minimum of two numbers.

[Ben Pfaff]

a < b

Isn't that simply a compare ? In other words an "if" statement at the
assembler level ?

It's not a conditional statement and it's not the conditional
operator (?, thus it fits the OP's criteria.

 

[Mark McIntyre]

| No, it evaluates to zero.
| Hint: We are talking about 1/2 == 0 (whereas 1/2.0 or 1.0/2
| is a completely different matter ;-))

Ah, I see your problem.

actually its /your/ problem...

You're assumming that I'm using a language that evaluates 1/2 to 0.

In C, this is a perfect assumption.

Well, mine doesn't. 1/2 = 0.5

You might want consider stopping crossposting to comp.lang.c then, where
integer division cannot result in floating point results.

 

[Skybuck Flying]

It's not a conditional statement and it's not the conditional
operator (?, thus it fits the OP's criteria.

Well hey says etc... so maybe this aint good as well.

It depends on what this code does at the asm level.

Is it a conditional at the asm level that's what's interesting to me

Probably for the cpu as well... if it's not conditional it might be faster


A conditional at asm level is probably something like

cmp
jmp,jne,jz, etc

Bye,
Skybuck.

 

[Bob Harris]

You might want consider stopping crossposting to comp.lang.c then, where
integer division cannot result in floating point results.

(chuckle) Well, Mark, then you certainly should stop crossposting to
alt.math.recreational, where unless otherwise stated division is expected to
behave as it does in mathematics.

Bob H

 

[Bob Harris]

min(a,b)=(1/2)*abs(a+b)-(1/2)*abs(a-b)

If abs() is allowed, and if overflow can be ignored, this should always
work:

min(a,b) = (a+b-abs(b-a))/2

If abs() is considered cheating, then |n| can easily be accomplished without
a compare if we know where the sign bit is in n. For 32-bit signed integers
|n| is n*(2*(n>>31)+1). I believe that will work for sign-magnitude as well
as the usual (these days) twos-complement. This of course has overflow
holes in it (e.g. if fails when n is -0x80000000 on a two's complement
machine). And it assumes that >> propagates sign. One could just as easily
use a mask to pick out the sign bit s, then compute u*s+v, where u and s are
chosen so that the two possible results are +1 and -1, then multiply that by
n.

Nearly all the overflow issues can be avoided if you first compute variables
to hold the signs of a and b (based on above technique) and then use these
to create a sum in which all subtotals are zero (because they are multiplied
by something that is zero) except the correct answer.

Bob H

P.S. Note that |n| is intended to mean 'absolute value of n'.

 

[Oppie]

Well, why not just take max(a,b) and then choose the other one!

If abs() is allowed, and if overflow can be ignored, this should always
work:

min(a,b) = (a+b-abs(b-a))/2

If abs() is considered cheating, then |n| can easily be accomplished without
a compare if we know where the sign bit is in n. For 32-bit signed integers
|n| is n*(2*(n>>31)+1). I believe that will work for sign-magnitude as well
as the usual (these days) twos-complement. This of course has overflow
holes in it (e.g. if fails when n is -0x80000000 on a two's complement
machine). And it assumes that >> propagates sign. One could just as easily
use a mask to pick out the sign bit s, then compute u*s+v, where u and s are
chosen so that the two possible results are +1 and -1, then multiply that by
n.

Nearly all the overflow issues can be avoided if you first compute variables
to hold the signs of a and b (based on above technique) and then use these
to create a sum in which all subtotals are zero (because they are multiplied
by something that is zero) except the correct answer.

Bob H

P.S. Note that |n| is intended to mean 'absolute value of n'.

--
Oppie the Bear
aka TOJ (The Other John)

'Remove' MYWORRIES to email me!

In the beginning, there was nothing.
And God said, 'Let there be Light.'
And there was still nothing,
but you could see a bit better.

 

[Mark McIntyre]

(chuckle) Well, Mark, then you certainly should stop crossposting to
alt.math.recreational,

Well, yes. But if I'd done that, you would not have seen my reply. The
point is, your answers were Just Plain Wrong (tm) in CLC so x-posting to
CLC was bound to raise heckles.

where unless otherwise stated division is expected to
behave as it does in mathematics.

Mayhap, tho personally I fundamentally disagree that integer maths should
EVER yield floating point results, and if you in AMR don't agree, you're
slightly strange mathematicians.

But then I didn't start the cross post so....

 

[Bob Harris]

Well, yes. But if I'd done that, you would not have seen my reply. The
point is, your answers were Just Plain Wrong (tm) in CLC so x-posting to
CLC was bound to raise heckles.

*My* answers? I didn't provide any answers prior to my post above.

 

[Albert van der Horst]

a < b

Isn't that simply a compare ? In other words an "if" statement at the
assembler level ?

Not on some modern architectures, like DEC Alpha and IA64.
This translates to a single instruction, setting a register
with a value derived from the values from two other registers.
Because jumps are avoided, pipe lines don't stall, and this may be
substantially faster. I speculate that this is the OP's intent
(if it is not a homework assignment.)

Back to the c-language. A compiler for such architecture will
probably recognize the idiomatic ( a<b ? a : b )
and compile it into a sequence without control instructions and
optimal speed.

Bye,
Skybuck.

--

 

[Frank J. Lhota]

(chuckle) Well, Mark, then you certainly should stop crossposting to
alt.math.recreational, where unless otherwise stated division is expected
to
behave as it does in mathematics.

And don't those Mathematicians realize that for unsigned integers, -1 > 0?