Is it possible to use JaCoP to solve a constraint problem that includes what might be called black box constraints? That is, I would like to be able to write a function that computes the values of one Domain Variable as a function of some other Domain Variables. This is a function that JaCoP will not be able to analyze, i.e., it will be a black box as far as JaCoP is concerned.
There is nothing readily available. However, it should be rather straightforward to create your own constraint, e.g. BlackBoxConstraint using for example XeqY as a template and then call your function that will compute the new domain of each of the variables given other variables.
If your constraint does not have a state then the only things you need to implement is consistency() and impose(). The consistency function will just call the external function to compute a new domain and call in(…) functions to restrict domains to just computed values.
Do you want to have this blackBoxConstraint for security reasons?
Can you be more specific how would you like to have this blackBox constraint implemented in terms of API? (info about constructor, etc). It does seem like a potential addition we could quickly add but I need to know more to make sure I fully understand your need.
If this blackBox constraint is not well behaving (etc the result depends not only on the domains of variables but e.g. the number of computations of this function) then nondeterministic and incomplete traversal of the search will occurr.
The blackBox function used to compute the domain of the result could also be informed about backtracking/changes as they occurr to improve the efficiency of the computation so feel free to express in more details the functionality you need.
If you want to define a discrete function in JaCoP you can always try to use ExtensionalSupport *** constraint. Technically it defines a relation between n variables but you might be able to use it for your purpose.
The reason for wanting a black-box constraint is to allow one to include arbitrary functions as part of the constraint system. More generally a capability such as this would in effect add a genetic algorithm capability. The black box constraint could be a GA fitness function. One could then try to minimize that function while at the same time satisfying other constraints. It would then not be necessary to include the other constraints in the fitness function since the constraint system would enforce them.
In addition, perhaps one doesn't require a minimum of the fitness function, just that it fall in some range. For example, it might be easier to solve multi-objective problems using a system of this sort-where each objective must fall within some range but where one doesn't require a minimum or maximum of any one of them and where it's not easy to define an overall fitness function.
This sort of thing comes up a lot when one is doing trade-offs among different capabilities when considering various design options for large systems. You want at least a given amount of each capability, but no one capability is that much more important than the others. The functions that compute the "amount" one has of the capabilities are too complex to be expressed in terms of JaCoP-like arithmetic.
Consider designing an automobile. One cares about gas mileage, acceleration, safety, roominess, etc. One has models that given the parameters of a candidate design will estimate what the values are for each of these criteria. The models are too complex to be expressed as JaCoP constraints, but they are not too complex to be expressed as easy-to-compute functions. One would like to use JaCoP to explore the trade space.
Often this is done by building a large spreadsheet and doing what-if experiments. The problem with that approach is that spreadsheets produce answers in only one direction. One would like to be able to express the relationships among the design parameters using the model functions, set some of them as well as some of the acceptable criteria ranges and see what happens.