Re: [eclipse-clp-users] IC produces unwanted delayed goals

Philipp Marcus wrote:
> Hi,
> 
> Given the following call when lib(ic) is loaded:
> 
> ?- Value $= 65 / 300, Result $= Value / 5.
> 
> Value = 0.21666666666666665__0.21666666666666667
> Result = 0.043333333333333328__0.043333333333333335
> There are 2 delayed goals.
> Yes (0.00s cpu)
> 
> Is there a way to prevent the creation of the delayed goals? As I'd 
> expect a rounded result e.g. with 3 decimal places.

The problem is that such a rounded result would not be an
actual solution, especially when equalities are involved:

?- Value $= 65 / 300, Result $= Value / 5, Value = 0.2167.
No (0.00s cpu)

That is the reason we have these "bounded real" numbers instead:
rather than saying "no" because 4.999=\=5.0, ECLiPSe says
"yes, provided the delayed goals hold".

At the end of your computation, you must make an assessment as to
whether you are likely to have a solution (which cannot be verified
automatically because of limited float precision), or whether the
uncertainties are so large that you have to suspect that there may
be no solution.  For this purpose you can:

1. examine all your variable bindings and, if they are breals (like
Value and Result in the example), check if they are "narrow enough".
Use breal_bounds/3.

2. examine all delayed goals (you can get them via subcall/2 or
delayed_goals/1) and check whether they are "close enough", e.g.
5 =:= 4.9999999999999991__5.0000000000000009

I think I had once written some code to do this check, but it's
lost in the mists of time...

If you problem is numerically well behaved, the check will hopefully
always succeed, and once you've got confidence in it, you can omit it
(which is effectively what you do by default when working with plain
floating point arithmetic...).

Due to all this, you should try to stick to integers as much as possible,
in particular with equality constraints.

-- Joachim