Malcolm Ryan wrote: > I've discovered a problem with ic(sets): > > [eclipse 9]: #([3,2,1], L). > > No (0.00s cpu) > [eclipse 10]: #([1,2,3], L). > > L = 3 > Yes (0.00s cpu) [3,2,1] is not a _set_ in the sense of the library. The solver works on the domain of the sorted, duplicate-free lists of integers. If you give anything else to the constraints, the behaviour is not defined. That behaviour is pervasive, e.g. ?- sameset([1,2,3],[3,2,1]). No. and I wouldn't like to change anything. It simply means that all the set-constants you use in your code must be well-formed, so if you have unsorted lists, use sort/2 first to make a proper set. You could argue that the constraints should raise errors instead of failing, but adding sortedness checks everywhere would be quite expensive. This should probably be clarified in the documentation. Also, ic_sets:is_solver_type/1 should probably check for sortedness. -- JoachimReceived on Wed Jun 13 2007 - 14:23:13 CEST
This archive was generated by hypermail 2.2.0 : Thu Feb 02 2012 - 02:31:58 CET