| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0000147 | mercury | Bug | public | 2010-05-25 13:30 | 2010-05-25 13:30 | ||||||||
| Reporter | juliensf | ||||||||||||
| Assigned To | |||||||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||||||
| Status | new | Resolution | open | ||||||||||
| Product Version | |||||||||||||
| Target Version | Fixed in Version | ||||||||||||
| Summary | 0000147: NaN behaviour | ||||||||||||
| Description | From the BUGS file: ------------------------- Subject: NaN behaviour Date: Mon, 21 Oct 2002 21:02:00 +1000 The mercury standard library tends to avoid producing NaN (e.g. throwing an exception in many places where libc would return NaN), but it's still possible from arithmetic functions (e.g. 0.0*Inf, Inf - Inf, Inf + -Inf, Inf / Inf), sin,cos,tan when passed infinity, and perhaps other things (I haven't done a full search). Presumably it can also arise from using the foreign language interface. When NaN does arise, we have a problem that `=' (and unification) aren't reflexive. From a logical point of view, this is a fairly serious problem. A lesser problem is that `<' doesn't induce a total order on floats. | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
|
 Relationships |
| Notes |
|
| There are no notes attached to this issue. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-05-25 13:30 | juliensf | New Issue | |
| Issue History |