Math.abs

M

markelmel

Why is Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE? By math
definition absolut value is always positive. In this case, Math.abs
returns negative value. Why it is implemented in Java in this way? Can
anybody explain me this?
 
D

Daniel Dyer

Why is Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE? By math
definition absolut value is always positive. In this case, Math.abs
returns negative value. Why it is implemented in Java in this way? Can
anybody explain me this?

This problem is mentioned in "Java Puzzlers" by Josh Bloch and Neal
Gafter. It's because it is not possible to represent the absolute value
of Integer.MIN_VALUE as a 32-bit integer (2147483647 is the highest
positive int, which is one less than the absolute value of the lowest
negative int, -2147483648).

So it is not possible for this method to return the right answer (unless
the answer was promoted to a long, but even then the long version of the
method still wouldn't work). It might be better if the method threw an
exception in this case rather than failing silently.

Dan.
 
T

Thomas Hawtin

Why is Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE? By math
definition absolut value is always positive. In this case, Math.abs
returns negative value. Why it is implemented in Java in this way? Can
anybody explain me this?

By maths, Integer.MAX_VALUE+1 > 0 as well.

If you were to write Math.abs, what value would return for
Integer.MIN_VALUE?

Tom Hawtin
 
R

Roedy Green

Why is Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE? By math
definition absolut value is always positive. In this case, Math.abs
returns negative value. Why it is implemented in Java in this way? Can
anybody explain me this?

because there is no corresponding +ve. The way it was defined, it can
be efficiently implemented without making a special case out of
MIN_VALUE.
 
T

Thomas G. Marshall

Thomas Hawtin coughed up:
By maths, Integer.MAX_VALUE+1 > 0 as well.

You mean, of course, by math as a /concept/ [only] that is true, right?
Just checking.....


If you were to write Math.abs, what value would return for
Integer.MIN_VALUE?

Tom Hawtin



--
Puzzle: You are given a deck of cards all face down
except for 10 cards mixed in which are face up.
If you are in a pitch black room, how do you divide
the deck into two piles (may be uneven) that each
contain the same number of face-up cards?
Answer (rot13): Sebz naljurer va gur qrpx, qrny bhg
gra pneqf naq syvc gurz bire.
 
R

Richard F.L.R.Snashall

Why is Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE? By math
definition absolut value is always positive. In this case, Math.abs
returns negative value. Why it is implemented in Java in this way? Can
anybody explain me this?
Get yourself a one's complement machine; it'll go away!;-)
 
T

Thomas G. Marshall

(e-mail address removed) coughed up:
Why is Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE? By math
definition absolut value is always positive. In this case, Math.abs
returns negative value. Why it is implemented in Java in this way? Can
anybody explain me this?


To help you understand what is going on here, let's make up a 3 bit signed
integer.

If it were unsigned, it would have as unsigned values, from 0 to 7:

000 001 010 011 100 101 119 111

Since it is signed, we need to have half of these represent negative
numbers. At first, you might think that this would be from -4 to +4, but
when including 0 this would be 9 values, and only 8 can fit in 3 bits. So
it goes from -4 to +3, as follows:

100 101 110 111 000 001 010 011

Notice that the most significant bit is the left most bit and is also called
the "sign bit" because if it's on, the number is negative.

Now given your example, look what would happen if we took the max value of
3....

011

and added 1 to it. The result would be a wraparound to -4!

100

Yikes. This means that your test of (max+1) is actually yielding a negative
number!
 
T

Thomas G. Marshall

Thomas G. Marshall coughed up:
(e-mail address removed) coughed up:


To help you understand what is going on here, let's make up a 3 bit
signed integer.

If it were unsigned, it would have as unsigned values, from 0 to 7:

000 001 010 011 100 101 119 111

Arg. clearly a quick typo. 119 is really 110. Figgers.
 
M

markelmel

Thanks very much.
I my opinion it would be better if the method threw an exception rather
then giving "wrong" answer.
 
R

Roedy Green

Thanks very much.
I my opinion it would be better if the method threw an exception rather
then giving "wrong" answer.

To do that would make abs take maybe 5 times longer for something that
almost never happens.
 
R

Roedy Green

To do that would make abs take maybe 5 times longer for something that
almost never happens.

if it is important to you, you can write your own abs or wrap Math.abs
that behaves the way you want.
 
B

Benji

Thanks very much.
I my opinion it would be better if the method threw an exception rather
then giving "wrong" answer.

But when you're working with ints, you fundamentally have to deal with
overflow problems. just like Math.abs(MIN_INT) should be a positive
number, MIN_INT-1 should be a negative number, but it's not. There are
some languages that allow mathmatical operations that never overflow
(at the expense of speed), but java is not one of them. It's very
consistent of the abs function to give a technically incorrect answer.
 
E

Eric Sosman

Why is Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE? By math
definition absolut value is always positive. In this case, Math.abs
returns negative value. Why it is implemented in Java in this way? Can
anybody explain me this?

"By math definition" there is no such thing as a
minimum integer at all. This should alert you to the
fact that a Java `int' is not a mathematical integer.
Knowing that, you should not expect an `int' to imitate
all properties of an integer with perfect fidelity.
 
E

Eric Sosman

Thanks very much.
I my opinion it would be better if the method threw an exception rather
then giving "wrong" answer.

It would be easy to add a test to Math.abs(), but that
wouldn't even scratch the surface of the "wrong answer" issue.
What about `Integer.MIN_VALUE * 42'? Or what about `i + j'?

Computers that trap on integer overflow have been built,
but they seem to have fallen out of fashion. Lacking hardware
support, I put it to you that adding overflow-detecting code
to every `int' calculation would slow every program down
enormously. (Perhaps an optimizer could eliminate some of
the checking, but I bet an awful lot would remain.) Also,
since Java mostly lacks the `unsigned' types found in some
other languages, Java relies on "silent overflow" to obtain
some of their benefits.
 
R

Richard F.L.R.Snashall

Eric said:
"By math definition" there is no such thing as a
minimum integer at all. This should alert you to the
fact that a Java `int' is not a mathematical integer.
Knowing that, you should not expect an `int' to imitate
all properties of an integer with perfect fidelity.
Sure there is. The definition of the "integers" is simply
a particular set of integers. The math operations of
+ and * are the inherited operations. What isn't inherited
is the closed-ness of those operations.
 
E

Eric Sosman

Richard F.L.R.Snashall wrote On 11/10/05 13:42,:
Eric Sosman wrote:

"By math definition" there is no such thing as a
minimum integer at all. This should alert you to the
fact that a Java `int' is not a mathematical integer.
Knowing that, you should not expect an `int' to imitate
all properties of an integer with perfect fidelity.

Sure there is. [...]

Care to write it out for us? (When you've finished,
I'll tack on a `- 1' at the end.)
 
R

Richard F.L.R.Snashall

Eric said:
Richard F.L.R.Snashall wrote On 11/10/05 13:42,:
Eric Sosman wrote:


"By math definition" there is no such thing as a
minimum integer at all. This should alert you to the
fact that a Java `int' is not a mathematical integer.
Knowing that, you should not expect an `int' to imitate
all properties of an integer with perfect fidelity.

Sure there is. [...]


Care to write it out for us? (When you've finished,
I'll tack on a `- 1' at the end.)

For a two's complement machine, the machine integers are
simply the intersection of the integers with the half-open
interval [-2^(n-1),2^(n-1)), where n is the number of bits in
the particular integer type. As such, a + and a * can be
derived from those of the integers (or real numbers),
provided the result is within the set. It's only when the
"mathematical" answer is not in the set that we end up
with all this nonsense and are forced to go to new definitions.
 
O

Oliver Wong

Richard F.L.R.Snashall said:
Eric said:
Richard F.L.R.Snashall wrote On 11/10/05 13:42,:
Eric Sosman wrote:

"By math definition" there is no such thing as a
minimum integer at all. This should alert you to the
fact that a Java `int' is not a mathematical integer.
Knowing that, you should not expect an `int' to imitate
all properties of an integer with perfect fidelity.


Sure there is. [...]


Care to write it out for us? (When you've finished,
I'll tack on a `- 1' at the end.)

For a two's complement machine, the machine integers are
simply the intersection of the integers with the half-open
interval [-2^(n-1),2^(n-1)), where n is the number of bits in
the particular integer type. As such, a + and a * can be
derived from those of the integers (or real numbers),
provided the result is within the set. It's only when the
"mathematical" answer is not in the set that we end up
with all this nonsense and are forced to go to new definitions.

So obviously the argument over whether or not there is a minimum integer
arose because of a misunderstanding of what one meant by "integer" (i.e. was
it the mathematical concept or the computer-science concept?)

What I wanted to bring up is that we don't need to "go to new
definitions" in the case of the + (and -) operations if we consider the
"machine-integers" to form a group.

I haven't examined it rigorously, but I believe all 3 (and a half)
properties of a group hold:

1) Associativity: for all a, b, c in our group G: (a + b) + c = a + (b +
c)

Trivially (?) true.

2) Identity: There is an element e such that for all a, e + a = a + e =
a

In our case, e = 0.

3) Inverse element: For all a in G, there is an element b such that a +
b = b + a = e.

This trivially is true for all elements greater than
Integer.MIN_INTEGER. (i.e. if a != Integer.MIN_INTEGER, then the inverse of
a is -a). I believe Integer.MIN_INTEGER is it's own inverse. Consider a
2-bit architecture, so the integers are -2, -1, 0 and 1. -2 + -2 is -2
decremented twice. -2 decremented once becomes 1. -2 decremented a second
time becomes 0, which is e.

3.5) Closure: For all a and b in G, a + b is in G.

This is true assuming we allow standard Java overflow/underflow
behaviour.

It seems that the integers and the multiplication does NOT form a group,
as we don't have closure.

- Oliver
 
C

Chris Uppal

Eric said:
Lacking hardware
support, I put it to you that adding overflow-detecting code
to every `int' calculation would slow every program down
enormously.

Probably not "enormously". "Measurably", I think, is a fairer description.
There are programming languages which don't suffer from integer overflow, and
they are not hugely slower than Java.

It's waaaay too late now, but I think that using primitive types /by default/
was a mistake in Java's design (possibly swayed by a desire to run on
resource-limited devices). "Proper", non-overflowing, real object, integers
can be implemented pretty efficiently (as has been known for decades). And if
the Java guys had wanted to allow primitive types /too/, as an optimised form
available to careful and knowledgable programmers, then I don't see much wrong
with that.

-- chris
 

Ask a Question

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.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top