«

Daniel Sjöblom wrote:

> Mark Thornton wrote:
>
>> Tor Iver Wilhelmsen wrote:
>>
>>> "John C. Bollinger" <> writes:
>>>
>>>> And, lest there be any confusion, the Java specs mandate the observed
>>>> behavior, regardless of what the underlying hardware may or may not do.
>>>
>>>
>>> Isn't that what the "strictfp" keyword is for though? To protect
>>> yourself from any anomalies in the underlying hardware?
>>
>>
>> No, even without strictfp, there remain quite tight rules on how Java
>> is permitted to behave.
>
>
> True. Strictfp only disallows using extended precision values for
> intermediate calculations. Non-strictfp code allows intermediate
> calculations in extended precision, but any assignments result in a
> conversion back to the standard precision value sets. Even without
> strictfp, the rules are quite strict, and are in conflict with the
> choices made in e.g. the x87 fpu (I seem to recall that the java
> floating point semantics are taken from some of Sun's fp implementations
> in software. Not surprising, really.).
>

Even without strictfp, extended precision is not permitted. What is
allowed is an extended range for the exponent so that intermediate
extreme values may avoid overflow/underflow. This means for example that
you can't use fused multiply/accumulate instructions.

Mark Thornton

Tor Iver Wilhelmsen <> wrote in message news:<>...
> (Razvan) writes:
>
> > I know that. My question was "why ?". Why we are treating
> > integers and floats differenntly ? Why integers don't have NaN
> > representions ? Certainly with integer operation you can get NaNs.
>
> Because the floating point representation has bit patterns that are
> set aside for the purpose. You cannot do the same for integers since
>
> 1) It would reduce the available value range.
>
> 2) You cannot reliably (except in Java, C# and the like) "know" how
> large an integer is. If you declare 0xffffffff to be positive (or
> negative?) infinity, you will run into trouble on machines with
> larger representations of ints. Also, integers are often either
> signed or unsigned - floating point is always signed.

Mmmmm... Such an algorithm can be implemented (sure why not ?!) but
its advantages will out weight the disadvantages – especially since
generation of programmers where educated in the C/C++ way of thinking.
As Stefan Schulz has noted, many algorithms will break and a new way
of thinking must replace the old one. This is a very slow process that
could slow down Java adoption.

Basically, 'trusted ways' and legacy algorithms are the reason for
this difference.

Stefan Schulz coughed up:
> On Tue, 28 Sep 2004 16:56:38 GMT, Thomas G. Marshall
> <. com> wrote:
>
>
>> I've often pondered on this for years. What is the advantage to
>> disallowing
>>
>> Double.Nan == Double.Nan
>>
>> aside from the (IMO unimportant) fact that it might be possible for
>> multiple bit representations to be NaN?
>
> The fact that it makes no sense logicwise. Is the natural Logarithm
> of -2 the
> same as the natural Logarithm of -5?

Yes IMO. And

sqrt(-10) ==should== sqrt(-20)

But it seems that I'm likely to be the minority here...


--
"Gentlemen, you can't fight in here! This is the War Room!"

"Boudewijn Dijkstra" <> wrote in message news:<41593fee$0$44078$ li.nl>...
> "Razvan" <> schreef in bericht
> news: om...
> > Hi !
> >
> >
> >
> >
> > I have noticed that the division by zero is handled differently for
> > integer and float types.
> > Let me explain better:
> >
> >
> > System.out.println("1f/0f = " + (1f/0f));
> > System.out.println("1 /0 = " + (1 /0 ));
> >
> > What is the reason for this behavior ? Why integers throw exceptions
> > when dividing by zero while floats just assumes the number is Infinity
> > (no exception is thrown) ?
>
> From a mathematical point of view, this is because integers are always exact
> and floating point numbers are not. The idea is that you 'never' know what
> was truncated to fit it in a finite number of bits.


I read your comment 5 times. I do not understand what you mean.
Both integers and floats have a finite number of bits.

"Thomas G. Marshall" <. com> writes:

> Yes IMO. And
>
> sqrt(-10) ==should== sqrt(-20)
>
> But it seems that I'm likely to be the minority here...

It would be a bad idea to have an equality that didn't hold when you
extend the operation to complex/imaginary numbers. So count me
against

/L
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Dimitri Maziuk <dima@127.0.0.1> writes:

> E.g. you have to call ResultSet.wasNull() after ResultSet.getXXX(),
> and ResultSet has to have an extra boolean flag to support that.

That has nada to do with integers supporting NaN. For instance, a
getString() can return "" and wasNull() return true, because the
implementation (say, Oracle) considers the empty string equivalent to
null. Having it return a constant String representing null instead of
using wasNull() is semantics (like your use of 0xffffffff for int),
but has the drawback that there's now one less String that can
reliably be put into a database.

> E.g. array search has to return -n for "not found", which means you
> can't have an array [-n..m]. A function that returns a signed
> integer cannot return an error value, ever. Etfc.

Actual errors should be exceptions anyway. Or you couls argue for
adding by-reference parameters and using HRESULT equivalents.

> The $15 question is whether the savings we get from having a simpler
> adder outweigh the costs of extra complexity in the software.

Yes it does.

Now, if primitives were objects, you could have constant values for
"actual" nulls, but then you are letting database semantics dictate a
language that isn't SQL.

"Thomas G. Marshall" <. com> writes:

> sqrt(-10) ==should== sqrt(-20)

No; For instance sqrt(-9) = 3i and sqrt(-100) = 10i; both are existing
(complex) numbers, they simply cannot be represented as reals.

On 28 Sep 2004 13:59:38 -0700, Razvan <> wrote:

>> From a mathematical point of view, this is because integers are always
>> exact
>> and floating point numbers are not. The idea is that you 'never' know
>> what
>> was truncated to fit it in a finite number of bits.
>
>
> I read your comment 5 times. I do not understand what you mean.
> Both integers and floats have a finite number of bits.

Any in-range Integer operation will alway yield the exact result.

However, look at the output of this little Program, and weep:

public class Numbers {

public static void main(String [] argv){
System.out.println(.1 * .1 == .01);
}
}


--

Whom the gods wish to destroy they first call promising.

Tor Iver Wilhelmsen wrote:

> > sqrt(-10) ==should== sqrt(-20)
>
> No; For instance sqrt(-9) = 3i and sqrt(-100) = 10i; both are existing
> (complex) numbers, they simply cannot be represented as reals.

I say yes, i.e. I agree with Thomas.

The NaN result is saying "this calculation has no defined result", or -- if you
prefer to invoke the complex plane -- "this calculation has two values neither
of which can be approximated as floating point". I prefer the first
formulation, not least because we are /not/ working in the complex plane[*].

([*] Remember that the complex plane is not the only mathematical abstraction
that can be considered to embed the real line, and in which sqrt() is defined
for all real values)

So the NaN result is a meta-level assertion shoe-horned into IEEE FP
representation. It would obviously be better -- in general -- to throw an
exception (perhaps a resumable one), but IEEE doesn't have language-specific
concepts like that (AFAIK), so all it can do is represent the meta-linguistic
assertion as a special reserved bit pattern.

There are only a handfull of such meta-lingistic concepts needed to cover the
failure modes of fp calculations. I presume that IEEE have done their
homework, and have covered all the bases, and so that all the meaningfull
assertions of the form "this calculation has no result because..." have been
given NaN values or similar.

Now, I don't see any semantic utility in distinguishing between "sqrt(-1) has
no defined result" and "sqrt(-1 has no defined value" -- in fact I think they
are the /same/ assertion (especially since IEEE NaN does not preserve the
expression that could not be computed), i.e. I think that "this calculation has
no defined result" /should/ be treated as equal to "this calculation has no
defined result" -- indeed I'd say that it's /obvious/ that they should be
equal.

That isn't to say that I'd want to make all the different kinds of NaN equal.
And it may be that that is the motivation behind making none of them equal, not
even to themselves. Since Java has no clear concept of the different kinds of
NaN as first-class primitive values (e.g there are no float/double literals for
them).

Alternatively, it may be -- as a pragmatic matter -- that generations of
experience in "real" FP work by numerical programmers have found that the
semantically impure device of treating all NaNs as unequal results in simpler,
clearer, or faster expression of important caclulations, and that Java is just
following that. It sounds plausible to me, but I don't know (I'm /not/ a
numerical programmer -- I'm pleased to say

-- chris

"Chris Uppal" <> wrote in message
newsZqdnSav7qLx8cfcRVn-...

[snip]
>
> That isn't to say that I'd want to make all the different kinds of NaN
> equal.
> And it may be that that is the motivation behind making none of them
> equal, not
> even to themselves. Since Java has no clear concept of the different
> kinds of
> NaN as first-class primitive values (e.g there are no float/double
> literals for
> them).
>

I'd say that the rationale behind NaN not being equal to itself has less to
do with different types of NaN and just a simple desire to ensure that the
result of any floating point operation involving one or more NaN is also
NaN, and the logical extension of that to boolean operations is that they
should fail, when normally they would be true. i.e. if (a == a) should be
true for any value other than a NaN (including +/-inf) but false for NaN.

> Alternatively, it may be -- as a pragmatic matter -- that generations of
> experience in "real" FP work by numerical programmers have found that the
> semantically impure device of treating all NaNs as unequal results in
> simpler,
> clearer, or faster expression of important caclulations, and that Java is
> just
> following that. It sounds plausible to me, but I don't know (I'm /not/ a
> numerical programmer -- I'm pleased to say
>

In the Fortran implementations I've worked with it has been possible to
give a compilation flag to specify whether a program fails or continues on
encountering a NaN. This is a very blunt instrument though, in that the
program will abort not just on what most folks would consider a floating
point calculation yielding a NaN, but even reading one from a file.

Michael Saunby