n1=1; n2=1; n3=nx; for(ni=4; ni <= n; ni++) {
ntmp=n1+n2+n3; n1=n2; n2=n3; n3=ntmp; bDomain &&= (n3<=ny);
}
assert_all(bDomain && n3==ny);
Table 7 shows experimental results (with translation times **included).** FznTini was used with clasp **as an underlying solver (the built-in solver gave poorer results). The**
number of variables and clauses generated by ursa **were, in these benchmarks, smaller** than for FznTini**. For** lparse/clasp**, the translation time was significant, and some of** the poor results for some benchmarks are due to large domains **(while the system works** with relations rather than functions). For recurrence relations, g12/fd **reported model** inconsistency when it approached its limit for integers, while B-prolog **just failed to find**
a solution for larger instances. Overall, on this set of benchmarks, ursa **gave better results** than clasp and FznTini **and on some benchmarks outperformed all other tools.** Discussion. The described limited experiments cannot give **definite conclusions or ranking**
of the considered systems, as discussed above. In particular, one may raise the following concerns, that can be confronted with the following arguments: - ursa **was used with a good problem specifications, and there may be specifications for**
other systems that lead to better efficiency. **However, almost all specifications were taken**
from the system distributions, given there to illustrate the modelling and solving power of the systems. Also, the problem specifications used for ursa **are also probably not** the best possible, but are rather straightforward, as specifications for other systems. In addition, in contrast to ursa**, other modelling systems typically aim at liberating the** user of thinking of details of internal representations and **are free to perform internal**
reformulations of the input problem. Making specifications in ursa **may be somewhat** more demanding than for some other systems, but gives to the user a fuller control of problem representation.

- **Some specifications used for** ursa **are related to the direct encoding (known to be efficient, for example, for the queens problem), while this is not the case with other systems.**
What is suitable for sat**-based systems is not necessarily suitable for other systems. For** instance, g12/fd gives significantly poorer results with the specification of **the queens**
problem based on the direct encoding, than with the one used in the experiment. This is not surprising, because systems that are not based on sat **does not necessarily handle** efficiently large numbers of Boolean variables and constraints (in contrast to sat **solvers)**
and lessons from the sat **world (e.g., that for some sort of problems, some encoding** scheme is the most efficient) cannot be a priori **applied to other solving paradigms.**
- ursa uses bit-wise logical operators, while other systems do not **(as they don't have support**
for them). **Bit-wise logical operators make one of advantages of** ursa**, while in the same**
time, some other systems use their good weapons (e.g., global constraints such as alldifferent).