Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #4401
| From | Lew <noone@lewscanon.com> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: About using assertion |
| Date | 2011-05-22 01:19 -0400 |
| Organization | albasani.net |
| Message-ID | <ira6dt$ia2$1@news.albasani.net> (permalink) |
| References | <f1e4cc83-8596-4e53-bed7-34a5209fe8c4@k3g2000prl.googlegroups.com> <92r0e9F6lvU1@mid.individual.net> <sjmea8-067.ln1@tmcd-linux-p4.austin.tx.us> <se-dnUMuGp0Fj0jQnZ2dnUVZ_o-dnZ2d@earthlink.com> <juula8-jc3.ln1@tmcd-linux-p4.austin.tx.us> |
Tim McDaniel wrote: > Patricia Shanahan wrote: >> Negative zero is a strange beast. As far as I can tell, it exists >> mainly to produce negative infinity when it is used as a divisor. For >> example, it is equal to zero for comparison purposes. > Hm, I thought it didn't, but the authoritative-looking but old > <http://www.concentric.net/~ttwang/tech/javafloat.htm> says otherwise. Authoritative-looking is not authoritative, though it is correct. Authoritative is the official documentation, which your source elucidates. > However, Float/Double apparently acts differently from float/double: Maybe because they *are* different? For example, the mechanism of comparison differs. Primitives don't use method calls, object types do. > Comparing two Java "Float" objects can have different semantics > than comparing two Java "float" values. Recall the "float" class > is a Java primitive class, while java.lang.Float is a subclass of > "Object". > > A "NaN" value is not equal to itself. However, a "NaN" Java > "Float" object is equal to itself. The semantic is defined this > way, because otherwise "NaN" Java "Float" objects cannot be > retrieved from a hash table. > > (new Float(0.0 / 0.0)).equals(new Float(0.0 / 0.0)) -> true > > For the class java.lang.Float, objects are ordered from lowest to > highest: -Infinity, negative numbers, -0.0, 0.0, positive numbers, > Infinity, NaN. "java.lang.Double" objects are identically ordered. > > (new Float(0.0)).equals(new Float(-0.0)) -> false The primitives are ordered thus: "Except for NaN, floating-point values are ordered; arranged from smallest to largest, they are negative infinity, negative finite nonzero values, positive and negative zero, positive finite nonzero values, and positive infinity." JLS ยง4.2.3 It goes on to say that NaN can be represented by multiple different bit patterns that can be distinguished programmatically. As with other primitives, 'double' is ordered via the ==, >, <, and related operators. With the reference type 'Double' comparison is via the 'compareTo()' method, which of course is different from and independent of the primitive operators. Since the purposes of a reference type differ from those of a primitive type in Java, for example, 'Comparable#compareTo()' should be consistent with 'equals()' (as mentioned in the docs for 'Double'), it makes sense that the semantics might differ. Unfortunate, perhaps, but sensible. <http://download.oracle.com/javase/6/docs/api/java/lang/Double.html#compareTo(java.lang.Double)> "Compares two Double objects numerically. There are two ways in which comparisons performed by this method differ from those performed by the Java language numerical comparison operators (<, <=, ==, >= >) when applied to primitive double values: "- Double.NaN is considered by this method to be equal to itself and greater than all other double values (including Double.POSITIVE_INFINITY). "- 0.0d is considered by this method to be greater than -0.0d. "This ensures that the natural ordering of Double objects imposed by this method is consistent with equals." This doesn't quite assure me that all forms of 'NaN' (by bit pattern) would box to 'Double.valueOf( Double.NaN )'. I'll have to run an example program. Anyway, it is an interesting point of comparison between the very different 'double' and 'Double' types (and their narrower counterparts) and a good thing to watch out for in the mapping between them. Thanks for bringing it up. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar
Re: About using assertion tmcd@tmcd-p4-linux.austin.tx.us (Tim McDaniel) - 2011-05-19 00:32 -0500
Re: About using assertion Michal Kleczek <kleku75@gmail.com> - 2011-05-19 08:34 +0200
Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-19 08:46 -0400
Re: About using assertion Michal Kleczek <kleku75@gmail.com> - 2011-05-19 15:16 +0200
Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-19 09:38 -0400
Re: About using assertion Robert Klemme <shortcutter@googlemail.com> - 2011-05-19 07:41 -0700
Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-19 11:00 -0400
Re: About using assertion Patricia Shanahan <pats@acm.org> - 2011-05-19 05:52 -0700
Re: About using assertion tmcd@tmcd-p4-linux.austin.tx.us (Tim McDaniel) - 2011-05-21 18:37 -0500
Re: About using assertion Patricia Shanahan <pats@acm.org> - 2011-05-21 19:00 -0700
Re: About using assertion Lew <noone@lewscanon.com> - 2011-05-22 01:19 -0400
csiph-web