Math.min and Math.max for byte / short

[Philipp]

Hello,
Why is there no Math.min(byte,byte) and Math.max(byte,byte) (and
equivalent for short) ?

This results in casting all the time... beuh.
Phil

 

[conrad]

The casting is inevitable.  The '<' operator is not defined for
anything smaller than int, so the compiler will widen any byte or
short operands to int anyway.

Also, OP, why does the casting bother you? It takes no additional
source code and doesn't have a speed penalty.

For further insight, check out the JLS on numeric promotions and
binary numeric conversions.

 

[Roedy Green]

Also, OP, why does the casting bother you? It takes no additional
source code and doesn't have a speed penalty.

Would you not write

byte c = (byte) Math.min ( a, b );

How do you pull it off without additional source code, namely the
(byte)?

 

[Lew]

Would you not write

byte c  = (byte) Math.min ( a, b );

How do you pull it off without additional source code, namely the
(byte)?

Very good point, if you are assigning the result back to a byte
variable.

However, for other uses you might not need the cast back to byte. For
example, if the result is used in another step then it likely would be
widened to int again anyway, so you'd leave it there.

E.g.,
if ( Math.min( a, b ) > 0 ) ...

In this case, you would not bother casting the 'min()' result back to
byte.

 

[Philipp]

     The inventors of java.lang.Math *could* have provided
byte-valued overloads of min, max, etc:
     I guess they just didn't feel it was important enough.

Hmm. Oh well. They provided it for double float int and long. I guess
they could have made the effort to type the three missing ones eh?

If they were wrong in the O.P.'s view, he can always write
his own min/max methods for byte and short.

That's what I obviously did.

Thanks for your asnwers anyway.
(I thought there was some more elaborate logic below this than "they
didn't feel like it")
Phil

 

[Patricia Shanahan]

Hmm. Oh well. They provided it for double float int and long. I guess
they could have made the effort to type the three missing ones eh?

I think it may be a matter of consistency with arithmetic promotion. The
four types that are supported are the four types in which a Java
implementation does arithmetic.

Patricia

 

[Daniel Pitts]

I guess they just didn't feel it was important enough.
If they were wrong in the O.P.'s view, he can always write
his own min/max methods for byte and short. For char and
boolean, too, if it suits his fancy (can't use `<' and `>'
on booleans, but Java has other operators to fill the bill).

public static boolean min(boolean a, boolean b) { return a & b; }
public static boolean max(boolean a, boolean b) { return a | b; }

The usefulness of this? I don't know. Actually, technically, boolean
values don't have an intrinsic ordering.
B={tautology, contradiction} isn't an ordered set.

 

[Mark Space]

Would you not write

byte c = (byte) Math.min ( a, b );

How do you pull it off without additional source code, namely the
(byte)?

I think it's been mentioned here on this list that the JVM and the
language spec require bytes to be promoted to ints for any kind of
arithmetic or logical operation. The Java language merely implements
what is possible on current JVMs in this respec. There is no operation
for comparing bytes in JVMs, so you might as well promote then cast it,
because that's what the JVM is going to do.

Whether it's truly correct for Java to follow the JVM capabilities so
closely in this regard is another debate. I think that's why there are
no byte or char versions of min or max.

 

[Mark Space]

Unnh, what? The result of the comparison is not an int,
but a boolean, and you almost certainly don't want to cast the
boolean to something else.

Oops, yeah I totally missed that. Thanks.

 

[Mark Space]

"Alligator sandwich, and make it sn..." (courtesy of Terry Pratchett)

rossum

I could really murder a curry right now.