Absolute value of signed 32-bit random integer

[Arne Vajhøj]

It might not be that bad I suppose - if 'checked'/'unchecked' came as
a big, advertised language feature there would be strong pressure on
vendors to comply (in open-source field inertia is not that strong so
libraries might take even quicker to update). Currently I do not see
better solution unfortunately.

I think that is overly optimistic.

We have seen plenty of examples of libraries not being updated.

Arne

 

[Marcin Rzeźnicki]

[...]
It needs not to know how it is called - it is only affecting VM to
check for overflow flag, I think that managed code is not concerned in
any way. As far as I remember MSIL there is appropriate instruction
emitted by a compiler to 'switch' VM to the desired mode.

That's dangerous thinking, IMHO.  For better or (mainly) worse, that
assumes a method produces no side-effects.  There are already too many
examples of software doing weird things because at the hardware level,
the FPU state is modified.

The last thing we need is for Java (or any framework) to allow methods
compiled in the past, without a mandate to stipulate checked or
unchecked, to now be subjected to the whim of the caller with respect to
whether its calculations are checked or not.

On this point, I'm definitely in agreement with Arne.  There may be code
depending on the overflow, and you can't have callers just turning that
off and throwing exceptions instead based on some random change in the
client code.

It may not be as bad as it sounds - let's not forget that:
- problem is, IMO, mostly limited to some libraries doing lot of math
and/or depending on such libraries. This is actually minority of stuff
out there,
- even if there is a problem it manifests itself as an exception so
it can be easily tested and verified whether problem strikes us or not
- depending on the outcome pressure on vendors will be created to
comply,
- even if previous do not hold, solution is not invasive, if you have
problems then you still can choose to not use this feature - then
semantics will be left unchanged

 

[Arne Vajhøj]

Arne Vajhøj wrote:
[...]
Why should Math.abs follow math ?

Because it feasibly can.

Since it also feasible can not, then that is not an argument
for either or.

Sorry, should have phrased it better: "because it MORE feasibly can".
It's feasible either way. But an implementation that more closely
parallels the true mathematical behavior is better from a
code-correctness point of view.

Code correctness is entirely a matter of matching the spec.

Which again means that it is ridiculous to consider a Java
method incorrect because it does nor follow normal math. [...]

Since the method is described as producing an "absolute value", and
since that term is not a Java term, but rather a math term, and since
the method does not actually produce a true absolute value per the math
definition of the math term used by the documentation, the method is
"incorrect" as considered in the context of the math term.

But the method is not described as producing an absolute value.

The docs says:

<quote>
Returns the absolute value of an int value. If the argument is not
negative, the argument is returned. If the argument is negative, the
negation of the argument is returned.

Note that if the argument is equal to the value of Integer.MIN_VALUE,
the most negative representable int value, the result is that same
value, which is negative.
</quote>

Which in math terms would be something like:

n for n >= 0
f(n) = -n for n < 0 and n != MIN_VALUE
n for n = MIN_VALUE

It is well defined and described in detail.

People that only reads the first sentence of the description and
assumes that words has the same meaning as in math should get a job
flipping burgers.

Docs exist to be read.

You can talk about the specification all you like, it still won't make
it relevant to what I actually wrote.

As long as the code follow the specification it is not incorrect.

Arne

 

[Marcin Rzeźnicki]

I think that is overly optimistic.

We have seen plenty of examples of libraries not being updated.

It may as well be overly optimistic. Still, all changes I am proposing
are not intrusive, you may 'opt out' if you find that your code base
is not prepared to use new feature (as problem manifests itself with
exception it should be easy to catch all offending bugs before serious
damage is done). I am just thinking that it is better to have any
solution than not - even if you for some perfectly valid reason choose
to ignore it.

 

[Arne Vajhøj]

[...]
It needs not to know how it is called - it is only affecting VM to
check for overflow flag, I think that managed code is not concerned in
any way. As far as I remember MSIL there is appropriate instruction
emitted by a compiler to 'switch' VM to the desired mode.

That's dangerous thinking, IMHO. For better or (mainly) worse, that
assumes a method produces no side-effects. There are already too many
examples of software doing weird things because at the hardware level,
the FPU state is modified.

The last thing we need is for Java (or any framework) to allow methods
compiled in the past, without a mandate to stipulate checked or
unchecked, to now be subjected to the whim of the caller with respect to
whether its calculations are checked or not.

On this point, I'm definitely in agreement with Arne. There may be code
depending on the overflow, and you can't have callers just turning that
off and throwing exceptions instead based on some random change in the
client code.

It may not be as bad as it sounds - let's not forget that:
- problem is, IMO, mostly limited to some libraries doing lot of math
and/or depending on such libraries. This is actually minority of stuff
out there,

Only breaking a few apps is not good enough.

- even if there is a problem it manifests itself as an exception so
it can be easily tested and verified whether problem strikes us or not
- depending on the outcome pressure on vendors will be created to
comply,

Stuff breaking and requiring being cost money.

- even if previous do not hold, solution is not invasive, if you have
problems then you still can choose to not use this feature - then
semantics will be left unchanged

Sure, but that just pushes the problem on to those calling my code.

Arne

 

[Marcin Rzeźnicki]

Marcin Rzeźnicki wrote:
[...]
It needs not to know how it is called - it is only affecting VM to
check for overflow flag, I think that managed code is not concerned in
any way. As far as I remember MSIL there is appropriate instruction
emitted by a compiler to 'switch' VM to the desired mode.
That's dangerous thinking, IMHO.  For better or (mainly) worse, that
assumes a method produces no side-effects.  There are already too many
examples of software doing weird things because at the hardware level,
the FPU state is modified.
The last thing we need is for Java (or any framework) to allow methods
compiled in the past, without a mandate to stipulate checked or
unchecked, to now be subjected to the whim of the caller with respect to
whether its calculations are checked or not.
On this point, I'm definitely in agreement with Arne.  There may be code
depending on the overflow, and you can't have callers just turning that
off and throwing exceptions instead based on some random change in the
client code.

It may not be as bad as it sounds - let's not forget that:
 - problem is, IMO, mostly limited to some libraries doing lot of math
and/or depending on such libraries. This is actually minority of stuff
out there,

Only breaking a few apps is not good enough.

Sure, but current state of affairs is not any better IMO.

Stuff breaking and requiring being cost money.

Well, yes, I agree - but philosophically speaking - every improvement
'costs' something, no free lunch here. I believe that the 'market'
would sort it out. If this change turned out to be too expensive to
comply it then would end up being ignored which would not make matters
better or worse.

Sure, but that just pushes the problem on to those calling my code.

Right, as above, there is probably no 'right' answer which could not
be questioned. But IMO it is better to have this as an option.

 

[Lew]

The statement I made that you take issue with has nothing to do with
Java, except inasmuch as Java claims to be producing an "absolute value"
with this method.

Really, Java is not making that claim. It makes the claim that for all 'int'
values but one, it produces an absolute value, and for that one it does not.

Which again means that it is ridiculous to consider a Java
method incorrect because it does nor follow normal math. [...]

Since the method is described as producing an "absolute value", and

That is not accurate. It only partly claims that it "[r]eturns the absolute
value of an int value", but goes on to state "that if the argument is equal to
the value of Integer.MIN_VALUE, the most negative representable int value, the
result is that same value, which is negative".

since that term is not a Java term, but rather a math term, and since
the method does not actually produce a true absolute value per the math
definition of the math term used by the documentation, the method is
"incorrect" as considered in the context of the math term.

You can talk about the specification all you like, it still won't make
it relevant to what I actually wrote.

What you actually wrote, and I quoted here, is that

the method is described as producing an "absolute value"

but that's only part of the claim for 'Math#abs(int)'. You left out the other
part. IOW, you are basing your argument on an incomplete description of what
is claimed. To be fair, you should base your argument on the entirety of what
is claimed for that method.

It is more than a little disingenuous to claim that people are arguing against
you based on a misquote of what you wrote when you are arguing against the
Java API based on a misquote of what it claims.

 

[Lew]

Frankly, the name of the method isn't terribly important. But the
documentation should not say that the method named "abs" "Returns the
absolute value of an int value".

You misrepresent what is claimed for the method then excoriate the claims as
you have misrepresented them. That's a classic straw-man fallacy.

 

[Arne Vajhøj]

Marcin Rzeźnicki wrote:
[...]
It needs not to know how it is called - it is only affecting VM to
check for overflow flag, I think that managed code is not concerned in
any way. As far as I remember MSIL there is appropriate instruction
emitted by a compiler to 'switch' VM to the desired mode.
That's dangerous thinking, IMHO. For better or (mainly) worse, that
assumes a method produces no side-effects. There are already too many
examples of software doing weird things because at the hardware level,
the FPU state is modified.
The last thing we need is for Java (or any framework) to allow methods
compiled in the past, without a mandate to stipulate checked or
unchecked, to now be subjected to the whim of the caller with respect to
whether its calculations are checked or not.
On this point, I'm definitely in agreement with Arne. There may be code
depending on the overflow, and you can't have callers just turning that
off and throwing exceptions instead based on some random change in the
client code.
It may not be as bad as it sounds - let's not forget that:
- problem is, IMO, mostly limited to some libraries doing lot of math
and/or depending on such libraries. This is actually minority of stuff
out there,

Only breaking a few apps is not good enough.

Sure, but current state of affairs is not any better IMO.

Correct apps are working fine.

Well, yes, I agree - but philosophically speaking - every improvement
'costs' something, no free lunch here. I believe that the 'market'
would sort it out. If this change turned out to be too expensive to
comply it then would end up being ignored which would not make matters
better or worse.

Not unnecessarily, because those carrying the cost and those making
the decision may not be the same company.

It is very difficult to change anything in Java that would break
existing stuff.

Next language !

Arne

 

[Marcin Rzeźnicki]

Correct apps are working fine.

So correct apps will be working fine.

Not unnecessarily, because those carrying the cost and those making
the decision may not be the same company.

It is very difficult to change anything in Java that would break
existing stuff.

Yes, but take a look at C#. They are faced with the same situation
(large codebases, adopted to enterprise) yet they manage to push new
features to the language (full-blown generics, linq, lambdas, type
inference). I think that Java suffers from too much conservatism.

Next language !

I wonder, what do you think it will be? Scala? Clojure?

 

[Arne Vajhøj]

So correct apps will be working fine.

Not necessarily if the changes are made.

Relying on overflow is correct behavior according to current spec.

Yes, but take a look at C#. They are faced with the same situation
(large codebases, adopted to enterprise) yet they manage to push new
features to the language (full-blown generics, linq, lambdas, type
inference). I think that Java suffers from too much conservatism.

Those changes did not break anything existing.

New generic classes were added instead of generifying the existing.

LINQ and lambda's are purely extras - it does not affect anything
existing.

I wonder, what do you think it will be? Scala? Clojure?

If Java based: Scala for backend stuff and and Groovy for frontend stuff.

Arne

 

[Arne Vajhøj]

Again, straw-man.

Core point of the discussion.

But the method is not described as producing an absolute value.

Yes, it is. You even quoted one such example (there is similar language
at the members-summary level of the docs):

The docs says:

<quote>
Returns the absolute value of an int value. [...]

Just because the docs later provide a completely different description
of the method doesn't mean that the docs don't describe the method as
producing an absolute value.

Of course it does.

The entire description need to be read.

Most of the methods in Math class has information about special
cases.

Arne

 

[Marcin Rzeźnicki]

Not necessarily if the changes are made.

Relying on overflow is correct behavior according to current spec.

We differ in the definition of correctness then. Relying on overflow
may be convenient for most, but apps that need to be mathematically
correct (I thought you were speaking of mathematical correctness) are
NOT relying on overflow, as this is clearly not correct. I believe
they have been doing some precautions against this, range checking and
such. So for really CORRECT apps this language addition won't impose
extensive changes, I believe.

Those changes did not break anything existing.

New generic classes were added instead of generifying the existing.

Generics did not break anything only because a lot of work had been
applied to ensure that (like aforementioned collections addition).
From the point of view of language it was non trivial addition which
Java designers/maintainers never really overtook

LINQ and lambda's are purely extras - it does not affect anything
existing.

Still, these have been serious changes of language/compiler which
never took place in Java world.

If Java based: Scala for backend stuff and and Groovy for frontend stuff.

Time will tell. Thx for your opinion.

 

[Tom Anderson]

On 11/07/2009 05:50 PM, Peter Duniho wrote:
Getting the _actual_ absolute value of some number will never correctly
return a negative result. So, either Math.abs() isn't really a function
returning the absolute value of the input, or it's not behaving
correctly.

By that argument, most of the operations in Java or almost every other
programming language are also not mathematically correct.

You're quite right. They aren't. We've mostly put up with it because we
don't know any better and we're terrified of the performance cost of doing
it right [1], but they're still wrong.

If they work as documented, then they are correct.

That's a pathetic, narrow-minded idea of 'correct'. We can do better.

tom

 

[Tom Anderson]

I wish that they had added it in 1.0.

I think there are too many problems introducing it now.

javac option - default on : will break some builds

javac option - default off : turning it on will have user code on and
libraries off

java option : could break something in libraries not intended for this

Not very attractive.

True. I imagine it would be done in exactly the same way as strictfp - a
keyword applied to classes or methods that has lexical scope.

I would go so far as to suggest that, as with strictfp, the default rule
should be changed and the keyword should enable the old behviour, so that
overflows would trigger exceptions unless the 'intlax' or whatever keyword
applied. I'd be tempted to say that code compiled under versions of java
prior to the change should be implicitly intlax. But by now we have a
really hairy situation, so maybe not.

tom

 

[Lew]

Really, it is making that claim.

Really, it is not. You cannot leave out part of their description and
excoriate them for what's left. That's intellectual dishonesty.

Yes, it is accurate.

No, it is not. It is an incomplete citation and leaves out the part that
invalidates what you say. That is dishonest.

It only partly claims that it "[r]eturns the absolute value of an int
value",

You left out the period. A very important typographical inclusion, it
means that the initial statement is intended as a standalone summary of
the method.

What a ridiculous assertion. It is not intended as a "stanalone summary" as
it appears in the same Javadocs with the part you want to leave out.

Such dishonesty.

You're right. The documentation contradicts itself. So?

It does not contradict itself. It says that there is one exceptional case,
thus it completes itself.

[...]
What you actually wrote, and I quoted here, is that

the method is described as producing an "absolute value"

but that's only part of the claim for 'Math#abs(int)'. You left out
the other part. IOW, you are basing your argument on an incomplete
description of what is claimed. To be fair, you should base your
argument on the entirety of what is claimed for that method.

Frankly, and this should have been clear from the outset to anyone
reading what I wrote, my complaint is that the behavior a method
expected to produce an absolute value does not in fact produce a true
absolute value.

If you expect it to produce what you call a "true" absolute value, then you
are not basing your expectations on the documentation, therefore it's your fault.

Everyone else expects the method to perform as documented.

The documentation really isn't relevant at all for judging that

Oh, come on!

The documentation isn't relevant?

That's it. Everything you say is trash if you claim the documentation isn't
relevant. There's no reason to respond any more to such dishonesty and
trollishness.

 

[Arne Vajhøj]

True. I imagine it would be done in exactly the same way as strictfp - a
keyword applied to classes or methods that has lexical scope.

That would work, but it would take a long time to succeed.

I would go so far as to suggest that, as with strictfp, the default rule
should be changed and the keyword should enable the old behviour, so
that overflows would trigger exceptions unless the 'intlax' or whatever
keyword applied. I'd be tempted to say that code compiled under versions
of java prior to the change should be implicitly intlax. But by now we
have a really hairy situation, so maybe not.

Changing semantics of code being recompiled with a newer Java version
is not good. It creates work for those upgrading.

Arne

 

[Lew]

That's a pathetic, narrow-minded idea of 'correct'. We can do better.

It's the relevant, useful idea of "correct" for APIs.

You want "correct" to mean "what I want the spec to be", but the API writer
cannot satisfy everyone on that count.

If the particular method doesn't do what you want to be "correct", use a
different method.

 

[Lew]

Actually, what would "ease communication" is if a person such as
yourself were not so eager to express disagreement with someone that

There's the pot calling the kettle black.

 

[Arne Vajhøj]

50 PM, Peter Duniho wrote:
Getting the _actual_ absolute value of some number will never
correctly
return a negative result. So, either Math.abs() isn't really a
function
returning the absolute value of the input, or it's not behaving
correctly.

By that argument, most of the operations in Java or almost every
other programming language are also not mathematically correct.

You're quite right. They aren't. We've mostly put up with it because
we don't know any better and we're terrified of the performance cost
of doing it right [1], but they're still wrong.

If they work as documented, then they are correct.

That's a pathetic, narrow-minded idea of 'correct'. We can do better.

/**
* Returns 2.
*/
public int getFoobar() {
return 2;
}

is correct. And it is verifiable that it is correct.

But let us say that Lew wrote that code, then you may consider:

public int getFoobar() {
return 1;
}

better and I may consider:

public int getFoobar() {
return 3;
}

better.

But it has nothing to do with correctness of the code. It is
a discussion about what behavior is "best".

It is not verifiable which one is best. In fact there may
not be "a" best, because it is perfectly valid that Lew, you and me
have different priorities that result in different conclusions
regarding what is best.

Arne