IC should not do unsafe arithmetic manipulation of constants

goat: eclipse
ECLiPSe Constraint Logic Programming System [kernel]
Copyright Imperial College London and ICL
Certain libraries copyright Parc Technologies Ltd
GMP library copyright Free Software Foundation
Version 5.3 #41, Sat Nov 24 13:49 2001
[eclipse 4]: X *= (15/16)^240.

X = 1.8754536520940796e-7__1.8754536520940796e-7
Yes (0.00s cpu)
[eclipse 5]: X *= 15/16.

X = 0.9375__0.9375
Yes (0.00s cpu)
[eclipse 6]: X *= 15/16, Y *= X^240.
unimplemented functionality in ^(0.9375__0.9375, 240, _466)
Abort
[eclipse 7]: Y *= X^240, X *= 15/16.

Y = Y{1.8754536520940788e-7 .. 1.8754536520940804e-7}
X = 0.9375__0.9375


Delayed goals:
	ic : (-(_516{1.8754536520940794e-7 .. 1.87545365209408e-7}) + Y{1.8754536520940788e-7 .. 1.8754536520940804e-7} =:= 0)
	ic : (0.9375__0.9375 =:= rpow(_516{1.8754536520940794e-7 ..  1.87545365209408e-7}, 240))
Yes (0.00s cpu)
[eclipse 8]: X *= 32/16.

X = 2.0__2.0
Yes (0.00s cpu)
[eclipse 9]: 16 * X *= 32.

X = 2
Yes (0.00s cpu)
[eclipse 10]: 


IC seems to handle 15/16 OK when `/'/2 is the top-level functor, but if it's
buried inside another expression it gets evaluated using the default (wrong)
method.  Anything appearing in an IC constraint should be evaluated using
safe arithmetic (except perhaps where it's obvious it shouldn't be).

Also, if the result of a division is integral, the result should be
integral; `16 * X *= 32' and `X *= 32/16' shouldn't really give different
results.

Note that fixing the former problem could be tricky; it seems to require
is/2 to know that we want safe division...

Cheers,
Warwick