| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0000471 | mercury | Bug | public | 2018-09-22 14:01 | 2018-09-22 14:01 | ||||||||
| Reporter | wangp | ||||||||||||
| Assigned To | |||||||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||||||
| Status | new | Resolution | open | ||||||||||
| Product Version | |||||||||||||
| Target Version | Fixed in Version | ||||||||||||
| Summary | 0000471: float rounding | ||||||||||||
| Description | float.round_to_int and math.round are implemented with floor(X + 0.5) There are problems with very large floats that behave as integers, e.g. round(8333333333388609.0) -> 8333333333388610.0 or when the fractional part is the predecessor of 0.5, e.g. round_to_int(0.49999999999999994) -> 1 See http://blog.frama-c.com/index.php?post/2013/05/02/nearbyintf1 I think no real programs would intentionally depend on the current behaviour so we should be free to fix the implementation. --- BTW {ceiling,floor,round,truncate}_to_int should specify the behaviour if the value would overflow the result type [or if the input is NaN]. But that's only one aspect of overflow handling that we don't do yet. | ||||||||||||
| 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 |
|---|---|---|---|
| 2018-09-22 14:01 | wangp | New Issue | |
| Issue History |