Absolute value of signed 32-bit random integer

[Marcin Rzeźnicki]

I agree.


But Java in general does not do that.


I very much doubt that *all* CPU's have that.

Arne

It seems we have all been missing 'checked'/'unchecked', as introduced
by C#. I really hope (in vain) that this feature makes its way to the
next version of Java

 

[Arne Vajhøj]

It seems we have all been missing 'checked'/'unchecked', as introduced
by C#. I really hope (in vain) that this feature makes its way to the
next version of Java

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.

Arne

 

[Arne Vajhøj]

It seems to not have a condition code register at all, for "speed."
That's the problem with RISC, they don't count all the instructions you
have to execute just to get a meaningful result. With no condition code
register the problem of even finding an overflow goes up.

*shrug* it was released in 1994, and abandoned in 2001. That's a pretty
old CPU.

It runs Java and systems are still used in many places.

I would be surprised if it is the only one that does
not have those registers, but I know it better that Power
and Sparc.

Arne

 

[Arne Vajhøj]

Arne Vajhøj wrote:
[...]
A negative number is _clearly_ an
incorrect result of taking the absolute value of some number.

It is not really incorrect. It works as specified in the documentation.

You misunderstand my words. Mathematically, the absolute value of
some number is always non-negative. A negative result is "clearly
incorrect".
[..]
But the fact remains, if one is _actually_ taking the absolute value
of some number, it's an incorrect result to produce a negative
number. That's fundamental to the concept of "absolute value".

Programming is programming. Code that works as it is intended is
correct code.

I'm not sure how many times I need to write "you misunderstand my words"
before you realize that you misunderstand my words. I suppose I'll keep
trying though.

"...taking the absolute value of some number" isn't something that Sun
or anyone else has the luxury of redefining. It has a single, specific,
mathematical definition, completely independent of the Java specifications.

Nowhere in my statement that I ever mention the word "code". But yes,
code that _claims_ to be producing the absolute value of some number but
which can return a negative result is incorrect code.

No.

Math defines abs for Z and R.

Java specs define abs for Java.

It is a misunderstanding that the Java specs should follow the math.

It's not an "assumption". It's an assertion that a particular kind of
behavior, one more in line with the actual mathematical definition of
"absolute value", is less "broken".

Things are broken if they do not work as they were designed.

Things are not broken if they do not work as someone think they should
have been designed.

For very good reason.

Assuming the spec is good, then it is well-defined what they should do
according to the spec.

It is not well defined what the best design would be - there will be X %
meaning A and 100-X % meaning B. Because they prioritize readability,
execution speed, portability, similarity with math, usefulness for
for scientific computations etc. differently.

Nowhere did I ever say I (or rather, John) "found a bug in Math.abs()".

Let us know when you're done playing with the strawmen...it's easy
enough for you to disprove something you've arbitrarily set up as
disprovable. But it doesn't make for interesting conversation.

Just replace "bug" with "incorrect behavior" in the above.

Arne

 

[Arne Vajhøj]

[...]

But in the sense that it's "no more and no less incorrect" of one or
the other, then yes...they are both incorrect behavior.

If they work like described in JLS and JVM spec, then they are correct.

Sorry Arne...you don't just get to pick your context arbitrarily. You
have to stick with the context intended by the author of the words on
which you're commenting.

Let me see - I actually quoted 14 lines.

You removed them can complains that I pick context arbitrarily ????

Arne

 

[Arne Vajhøj]

Frankly, I don't need you to tell me how to "look at it". I am already
quite aware of a number ways to "look at" the issue such that one can
consider the behavior of Math.abs() to be "correct".

But the only way to look at it that is relevant to my statement is as an
actual mathematical function. And with that view, Math.abs() is incorrect.

Nothing in Java arithmetic is following math arithmetic for Z and R.

I don't think any programming language arithmetic does that.

Why should Math.abs follow math ?

You don't get to go around "extending" mathematical definitions. The
absolute value function is well-defined, and does not allow for the
result to be negative. Any other function is not actually "the absolute
value function" from the mathematical point of view.

Of course not.

Similar to all the other arithmetic problems mentioned.

But so what?

There is a spec of how things work in Java and if follows those
specs it is correct.

Arne

 

[Lew]

So sure, if you want to go finite set theory and define a mapping from
each of the 2^32 elements to a new element within the same set, you can
arbitrarily decide that just as 0 and the positive integers map to
themselves, so does -2^31 map to itself. But that mapping is a whole
new function, and is _not_ the absolute value function.

You're absolutely correct. In order to ensure that one does not confuse this
"whole new function" with the absolute value function, we'll name it "abs"
instead of "absoluteValue".

 

[Marcin Rzeźnicki]

"All"?  Speak for yourself.    I mentioned that fact hours ago, in
reply to Thomas's essay on computational arithmetic.

Pete

If I could only find that...

 

[Marcin Rzeźnicki]

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.

It is not a compile-time pragma but rather language syntactic
construct. Introducing it to the language would not change anything
till you actually use it. So I understand this is perfectly safe.
Peter Duniho claims to have been writing on this subject but I cannot
find his post )

 

[Arne Vajhøj]

You're absolutely correct. In order to ensure that one does not confuse
this "whole new function" with the absolute value function, we'll name
it "abs" instead of "absoluteValue".

But we could of course rename the class from Math to NotMath, so
that no one thought that all these functions returned mathematical
correct values, because most of them don't (none using irrational
numbers).

Arne

 

[Arne Vajhøj]

It is not a compile-time pragma but rather language syntactic
construct. Introducing it to the language would not change anything
till you actually use it. So I understand this is perfectly safe.

Ah.

@CheckOverflow
int v;

?

I guess that would be safe.

Limited in scope but safe.

Very limited in scope, because it could not propagate
to methods in other classes (at least not without a lot
of work by the JIT).

Arne

 

[Marcin Rze¼nicki]

If I could only find that...

Ok, got that:

<Peter>
In any case, as for the question of "incoherence", somehow C#/.NET
gets
away with the more sensible "incoherent" solution without anyone
complaining about it, or it causing any problems. Of course, in C#
you
can optionally force all run-time arithmetic computations to be
checked
for overflow too, for those who insist on 100% consistent behavior
(i.e
you get your "design #2" instead of a hybrid approach).
</Peter>

Right, and I believe this is the way to go - to retain current
semantics so existing code will not be broken, but to introduce
additional construct to enable overflow detection.
So, we 'all' 've been missing... )

 

[Marcin Rzeźnicki]

Ah.

@CheckOverflow
int v;

?

More or less but rather expression-scoped than bound to particular
variable. They do it more or less like:

checked {
....
}
Any overflowing operation within checked block throws appropriate
exception

I guess that would be safe.

Limited in scope but safe.

Very limited in scope, because it could not propagate
to methods in other classes (at least not without a lot
of work by the JIT).

Not automatically probably, but still you have that degree of control,
albeit manual - you just place checked block somewhere high in the
methods call tree.

 

[Arne Vajhøj]

More or less but rather expression-scoped than bound to particular
variable. They do it more or less like:

checked {
...
}
Any overflowing operation within checked block throws appropriate
exception


Not automatically probably, but still you have that degree of control,
albeit manual - you just place checked block somewhere high in the
methods call tree.

And if some of the library code called actually were
using overflow as a feature ??

Arne

 

[Marcin Rzeźnicki]

To be clear: my comments were with respect to the existing C# feature
simply as a matter of comparison, not that I suggested it would be
feasible to retroactively add the behavior to Java.

In C#, it works well because non-intrinsic calculations are already
"checked".  So the compile-time setting (based on "checked"/"unchecked")
need not affect anything other than the code local to the use of the
keyword.

As long as you omit compile-time setting and limit the scheme to
checked blocks only it is not unsafe, I believe.

It would be a lot more complicated to introduce "checked" into Java,
while still providing for consistent behavior from the library itself
(e.g. if you're in a "checked" section of code, Math.abs() should throw
an exception, but how should _it_ know it's being called from a
"checked" section of code...not intractable, but certainly a significant
complicating factor, and the solution for which may not be desirable in
Java).

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.

 

[Marcin Rzeźnicki]

And if some of the library code called actually were
using overflow as a feature ??

Then I guess they would place their code in an 'unchecked' block -
like in

int z = unchecked((short)(x + y));

According to MSDN:
In an unchecked context, if an expression produces a value that is
outside the range of the destination type, the result is truncated.

 

[Arne Vajhøj]

[...]
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.

[...]

You don't get to go around "extending" mathematical definitions. The
absolute value function is well-defined, and does not allow for the
result to be negative. Any other function is not actually "the
absolute value function" from the mathematical point of view.

Of course not. [...]

Then why respond to my previous statement at all, never mind imply a
disagreement that apparently doesn't exist at all?

Then I think you need to reread my posts.

And almost everybody else's as well.

The claim is not that Math.abs follow normal math.

The claim is that normal math does not apply to Java (and
other programming languages for that matter).

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

Normal math being 10-12th grade regular Z and R math.

In real math you define an algebra and integer and floating
point can be considered an algebra.

Arne

 

[Arne Vajhøj]

Then I guess they would place their code in an 'unchecked' block -
like in

int z = unchecked((short)(x + y));

According to MSDN:
In an unchecked context, if an expression produces a value that is
outside the range of the destination type, the result is truncated.

They could, but it would take a decade before all existing
libraries were updated.

At that time we may all code in Scala and Groovy ....

Arne

 

[Marcin Rzeźnicki]

They could, but it would take a decade before all existing
libraries were updated.

At that time we may all code in Scala and Groovy ....

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.

 

[Arne Vajhøj]

[...]

It's not an "assumption". It's an assertion that a particular kind
of behavior, one more in line with the actual mathematical definition
of "absolute value", is less "broken".

Things are broken if they do not work as they were designed.

That's _your_ definition of "broken", independent of the true context
and literal meaning of what I actually wrote.

Things are not broken if they do not work as someone think they should
have been designed.

Again, your definition. Completely irrelevant in the context of
replying to the statement I made.

Not my definitions. The definitions used in the IT industry.

You are _redefining_ "broken" arbitrarily, and then attempting to
"disprove" my own use of the word "broken" on that basis. More tautology.

Not arbitrarily.

Concepts as correct and incorrect code has a specific meaning in the
IT industry.

[...]
It is not well defined what the best design would be

Agreed. So? I'm not allowed to have an opinion on what design is
preferable?

Sure you are.

But it would ease communication if you used normal terms (in software
development) to describe what you mean.

Incorrect code is one thing. Bad design is something else.

You could even call it bad code, because that is so broad that
it could could cover both.

[...]

You have not found a bug in Math.abs - you have found something
you want changed.

Nowhere did I ever say I (or rather, John) "found a bug in Math.abs()".

Let us know when you're done playing with the strawmen...it's easy
enough for you to disprove something you've arbitrarily set up as
disprovable. But it doesn't make for interesting conversation.

Just replace "bug" with "incorrect behavior" in the above.

"Bug" != "incorrect behavior". The two are related, but not identical
in meaning. And as should be obvious in this case: you can have a
bug-free piece of code that, through virtue of complying with an
incorrect specification, produces incorrect behavior.

No.

Correct behavior of code is always that it behaves according to
specification.

The concept of formal verification of correctness of code is
only possible due to that.

Arne