Re: [eclipse-clp-users] Time out issue with long integer

Dear Joachim,

  It would be great if the problem would be fixed. I read your email and understood. The large domain is due to the LONG range used in java as I am mapping it with variables in java.
In few cases, I could be in a situation where the no of constraints are very less. The above bug fix will also help me in my approach for real numbers. Please see below.

  On a separate note, please look at the following example. I read your posts on real numbers and understand the limitation to solve equations if the a finite solution is non existant.

To counter the same, I have come up with the following solution. Express a real number A as A1/A2(i.e fraction) where A1 and A2 are integers. for e.g. if your solution for A is say 4.5 you get A1 as 45 and A2 as 10. This approach solves most of the complex equations which otherwise give me a bounded real if locate is used. But it has a following limitation. I cannot use precision. Precision in my case is again different. 

If a > 3.5, I need the solution as 3.6 or 3.51 which is the boundary value for me. 

In the following problem I need the value of A1/A2 as 2.51 or 2.6 depending on the precision set.


Problem:-
:-lib(ic).
solve(A1, A2) :-
%%Domain
A1 :: -2147483648 .. 2147483647,
A2 :: -2147483648 .. 2147483647,

%%Constraints
(A1/A2) + 1  $> (3.5),
%%Search
search([A1, A2],0,input_order,indomain_min,complete,[]).

Output:-
A1 = -2147483648
A2 = -858993459
There are 2 delayed goals.
Yes (0.00s cpu, solution 1, maybe more)
-------
So A1/A2 is 2.5000000005820766092701993438579

Please let me know your thoughts on this.

Thanks and Regards,
Shrirang Edgaonkar


________________________________________
From: Joachim Schimpf [jschimpf_at_...311...]
Sent: 10 December 2014 23:52:42
To: eclipse-clp-users_at_lists.sourceforge.net
Subject: Re: [eclipse-clp-users] Time out issue with long integer

On 10/12/14 02:13, Edgaonkar, Shrirang wrote:
> Dear clp users,
>
>     I have the following problem. I am trying to get the value for IN_FORMULA1.
> Here I need to use indomain_min since I need the minimum value satisfying the
> equation. I could use indomain_split but it wont ensure the value is minimum.
> But using indomain_min, it takes infinite time to resolve the equation. Any
> pointers on this?
>
> :-lib(ic).
>
> solve(IN_FORMULA1):-
> %%Domain
> IN_FORMULA1 :: [-9223372036854775808 .. 9223372036854775807],
>
> %%Constraints
> (IN_FORMULA1 $> 115000000000),
>
> %%Search
> search([IN_FORMULA1], 0, input_order, indomain_min, complete, []).


You seem to have run into quite a curious bug, related to the size (~10^19) of
your variable domain.  I'll look into fixing this later.

Generally speaking, when working with integers, you should make your variable
domains as tight as possible.  Any enumeration-based search method is likely to
be hopeless when applied to such domain sizes.  Remember that the size of the
search space is the product of all the domain sizes, which quickly becomes
astronomical.  Is there a particular reason you are choosing these initial
bounds of 2^63?  The ic-library represents bounds as double floats, therefore it
is more efficient (and avoids the bug you have encountered) when you keep
integer bounds in the range -2^51..2^51.  In practice, integer bounds should be
much lower than that for a tractable constraint model.

As to your remark about the enumeration order: indomain_split (which doesn't
exhibit the bug) will generate solutions in the same order as indomain_min, so
there is no reason not to use it.  On large domains, splitting is usually
advantageous, because it can eliminate large ranges of search space in one step.


-- Joachim




------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
ECLiPSe-CLP-Users mailing list
ECLiPSe-CLP-Users_at_lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/eclipse-clp-users

______________________________________________________________________
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.