New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Double.NaN min 0.0) yields 0.0, should be NaN #5104
Comments
Imported From: https://issues.scala-lang.org/browse/SI-5104?orig=1 |
@paulp said: |
@dlwh said: http://www.itu.dk/~sestoft/javaprecisely/java-floatingpoint.pdf min of anything with NaN is NaN and max of anything with NaN is NaN. Also by spec, (NaN != NaN) == true. However, note that: scala> math.min(0.0,Double.NaN) scala> (0.0 min Double.NaN) which is probably bad. Should I open a separate ticket for this? |
@paulp said: |
Jentsch (jentsch) said: |
@khernyo said: |
@khernyo said: |
[Original report is classified as out of scope; ticket is open for (NaN min 0) wrongness.]
*import* scala.math.Ordering.Double._
Hi Scala folks!
I find something in Scala, that made me searching the web, reading documentations and rummaging in the sources of Scala and trying many things. So far so good, but I'm still wondering why is the following expression
*true*
:I found out that
NaN
inOrdering.Double
is bigger than everything else, even that_PositivInfinity_
! AndNaN
is equal to it self. The implementation injava.lang.Double.compare
have the same behaviour.The other implementation is the the native one, based on IEEE. (You know
<
,>=
and so on.) This one says that every comparison withNaN
returns*false*
, evenNaN==NaN
is*false*
.I think is a philosophical discussion what the better way is. I prefer IEEE but that doesn't matter.
The point is the code snipped at the top with
min
andmax
. I can not say what is bigger.NaN
or 0? I also can't say what is smaller.NaN
or0
? I have the same problem, so I expected the same result of both methods. Currentlymax
returns alwaysNaN
andmin
the other number (0 in my example).Now I see four possible solutions for this inconsistency:
(I tried to mark pro and contra, but they are not weighted. Some points are definitely stronger than others.)
Ordering.Double
gets anNaN
.(+) That is a hyper correct dealing with
NaN
(-) and a hidden trap for many programmers, because this solution would be far away from the native handling with
NaN
and the use of anOrdering
withimplicit
parameters isn't visible for starting programmers.(-) Throwing an exception for normal program flow? Doesn't sounds good.
(-) Currently fine working code could throw suddenly exceptions.
(-) Leave the problem
(+) Leave the code
min
andmax
forDouble
:(+) That means the result is
NaN
and would makeNaN
more dominant like in other arithmetic operations.(-) I fear that someone had used
min
andmax
to sort something.A single
NaN
could duplicate its self this way. Old code is may not cable of handling this behaviour.(-) This changes treats to change the
min
andmax
methods inTraversableOnce
to:(+) But I think that would be good changes anyway.
Ordering.Double
should be direct child ofParticalOrdering
(+) That's an other hyper correct dealing
NaN
.(-)
RichDouble
or its parentScalaNumberProxy
needDouble
as a{Numeric
andNumeric
depends onOrdered
. I think that can be resolved with more re-factoring, but it would be hard work.(+) It's possible to mark the old way as deprecated. Every becomes a warning, if he use
min
ormax
onDoubles
.(-) Many people (like me) want to use the
min
andmax
methods inTraversableOnce
, so the methods have to handle this new situation.A very naive implementation of
max
could be:This would have to throw an exception if
NaN
part of the collection.(+) But maybe that expand the use of
ParticalOrdering
.You see, I'm very focused on
min
andmax
, that's because I can't decide what the best way is to deal withNaN
and<
,>=
. Solution number three gives a good reason whymin
andmax
returns what they do and works around<
,>=
.Maybe it is possible for solution number three get the (+) with deprecated of solution number four, but I have no idea how.
My favourite solution is number three. What do you think about it?
Sincerely,
D. Jentsch
The text was updated successfully, but these errors were encountered: