| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0000419 | mercury | Feature Request | public | 2016-09-14 12:15 | 2016-09-21 04:57 | ||||||||
| Reporter | wangp | ||||||||||||
| Assigned To | |||||||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||||||
| Status | new | Resolution | open | ||||||||||
| Product Version | |||||||||||||
| Target Version | Fixed in Version | ||||||||||||
| Summary | 0000419: cannot write floats in break point conditions | ||||||||||||
| Description | The mercury_trace_term.c parser does not accept float arguments. I don't know if more work would be required to make the break condition work. It is not very important to me. mdb> cond 2 != gray(float(1.0)) syntax error in term: gray(float(1.0)) ^ here | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
zs (developer) 2016-09-14 17:56 |
The main problem I see is that equality with floats is not precisely defined in general. There is exactly one float x for which x = 1.0 should work, but there is no one float for which x = 1.1 should work, since 1.1 is not exactly representable in binary. One would have to pick either a relative or absolute epsilon, and have x = 1.1 succeed for all x for which |x - 1.1| < epsilon (absolute) or all x for which |x - 1.1|/1.1 < epsilon (relative). To support float tests in breakpoint conditions, one would either have to provide a means for users to specify their desired epsilon (with a default, of course), or enrich the condition language to allow the epsilon to be specified in the test itself. I think we need one or more specific use cases to guide our choice in fixing this issue. Does anyone have one? |
|
wangp (developer) 2016-09-19 14:44 |
I only expected equality and inequality to work, like = and \= on floats in Mercury. I can see uses for an epsilon or specifying values in a range. That might be useful for int tests as well, e.g. stop only when this argument is negative. When I reported this bug, that was probably the first time that I've tried to use a float in a break point condition, so take that as you will. |
|
zs (developer) 2016-09-21 04:57 |
A long time ago, I did a subject on numerical analysis. One of the first things mentioned was that floats should not be compared for equality, because their approximate nature makes such comparisons inherently unreliable. I expect well-written programs that handle floats, in Mercury or in other languages, to follow that advice. For the programs that ignore the advice, the right fix is probably to generate a compiler warning whenever two floats are compared for equality, to get the programmer to fix the equality test itself. This is why, for programs that follow the advice, the treatment of float equality during normal execution should not be the semantics one should strive to implement for breakpoint conditions in the debugger. Note that at the moment, the debugger treats the literal values in breakpoint conditions as uninterpreted and untyped terms. Adding a mechanism for comparisons would require effectively reimplementing breakpoint conditions in a type-aware manner. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-09-14 12:15 | wangp | New Issue | |
| 2016-09-14 17:56 | zs | Note Added: 0000909 | |
| 2016-09-19 14:44 | wangp | Note Added: 0000911 | |
| 2016-09-21 04:57 | zs | Note Added: 0000919 | |
| Issue History |