|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000419||mercury||Feature Request||public||2016-09-14 12:15||2016-09-21 04:57|
|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))
|Tags||No tags attached.|
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
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?
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.
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.
|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|