- Mail actions: [ respond to this message ] [ mail a new topic ]
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Joachim Schimpf <jschimpf_at_...311...>

Date: Fri, 15 Apr 2022 17:06:24 +0100

Date: Fri, 15 Apr 2022 17:06:24 +0100

On 13/04/2022 16:40, Jeshan Babooa via ECLiPSe-CLP-Users wrote: > I understood that there are certain limits concerning number ranges when using IC. > e.g X #= 2 ^ 55, indomain(X). > gives: out of range in indomain(X{36028797018963964 .. 36028797018963976}) > > This works fine in other systems like Scryer and SWI. > > I was hoping to be able to label numbers of up to 2 ^ 128. > Could this somehow work in Eclipse? hopefully in a way that doesn't need code > editing? > > We could use several smaller integers to label them but that would meaning > labelling a huge number of integers. > > I thought to take a look at the code and In ic.c, I saw that MAX_BITMAP_RANGE > could have something to do with it. When I increase it, it takes really long to > label just X #= 2^64. > > So how should we label bigger integers? > > Jeshan Hi Jeshan, ECLiPSe's lib(ic) constraint solver is designed for handling mixtures of real- and integer-valued variables and numbers. All computations in IC-constraints are performed using double floats to represent upper and lower bounds, and integrality is simply treated as an additional constraint. Because double floats have 53 bits of precision, only integers in the range -9007199254740992..9007199254740992 are represented precisely. Larger integers are approximated by a floating point interval that encloses the true value. This is why your X remains uninstantiated when you exceed this range: ?- X #= 2 ^ 53. X = 9007199254740992 Yes (0.00s cpu) ?- X #= 2 ^ 53 + 1. X = X{9007199254740991 .. 9007199254740994} There is 1 delayed goal. Yes (0.00s cpu) It is a design decision of the IC solver to handle large numbers via this "fuzziness", instead of defaulting to unbounded size integer representations. This was done because in practice, models involving huge integer domains are rarely efficiently solvable, and are therefore less useful than they may seem at first glance. You are not saying anything about the problem you are actually trying to solve. But I suspect that your integers do not represent real world quantities/amounts/measurements/etc, and instead you are using them as bitmaps to represent arrays of booleans. In this case I would consider modelling directly with boolean (0..1) variables. -- JoachimReceived on Fri Apr 15 2022 - 16:25:23 CEST

*
This archive was generated by hypermail 2.3.0
: Wed Sep 25 2024 - 15:13:21 CEST
*