Hi all, On Thursday 05 August 2010, Joachim Schimpf wrote: > > Stephan Schiffel wrote: > >> ?- hash_create(H), minimize((member(X,[3,2,1]), hash_add(H,solution,X)), > >> X). Found a solution with cost 3 > >> Found a solution with cost 2 > >> Found a solution with cost 1 > >> Found no solution with cost -1.0Inf .. 0 > >> > >> H = hash(4, 0, []) > >> X = 1 > > To get the behaviour you want, use a store that survives backtracking > (record, bag, store, shelf), e.g. > > ?- record_create(H), > minimize((member(X, [3, 2, 1]), recordz(H, X)), X), > recorded_list(H, Xs). Thanks for the suggestion, but this is not what I want. I really just want to remember some information about the best solution, not about all solutions. The output I'd like would be: ? hash_create(H), minimize((member(X,[3,2,1,4,5]), hash_add(H,solution,X)), X). ... H = hash(4, 1, [solution -> 1]) X = 1 That means as long as I'm not using any non-logical storage, I'd like minimize(Goal, Cost) to behave exactly as calling Goal and selecting the "right" branches on choice points instead of the first one first. So far, I thought of lib(hash) as logical storage, because it behaves well on backtracking. I know that it is not strictly logical, because it uses setarg/3 internally. Kish's e-mail explains the problem. Unfortunately, that means that using hash-tables is not a good idea because they don't behave well, at least not together with lib(branch_and_bound). I wonder if there is a way to implement hash-tables efficiently in a logical way, i.e., without using setarg/3. The problem could be easily solved with something like setarg(+N, +OldTerm, ?Arg, ?NewTerm), that does not change OldTerm but constructs a new one instead. However, avoiding the construction of a new term is probably what makes setarg/3 so efficient, right? Regards, Stephan -- Stephan Schiffel Technische Universität Dresden, Fakultät Informatik, 01062 Dresden, Germany Tel: [49] (351) 463-39243 Fax: [49] (351) 463-37924 Email: stephan.schiffel_at_inf.tu-dresden.deReceived on Thu Aug 05 2010 - 06:52:21 CEST
This archive was generated by hypermail 2.2.0 : Thu Feb 02 2012 - 02:31:58 CET