retract(pred(X,Y,Z) -- with X,Y,Z bound, creating a choice point

Help!
27

thank you,

I guess all called predicates will fail, but the call argument pattern, is what what counts here.

Does this also work when none of the called goals exist as facts, yet.

28

Yes

I don’t think so – it’s probably best to have to have a “sufficient” number of facts to trigger the index creation. The only way to be sure is to try it out and use jiti_list/0; and you can always assert some facts, do the fake queries to build the indexes, then retract the facts.
(My use case is that I load a set of facts; but the initial queries were quite slow because of the time it took to build the indexes.)

29

ok, thanks.

30

This is surely worse than just

fact(Int, Sym, List).

As said, the first argument are all -/2 terms, so that is non-indexable. The system identifies it can create a deep index on the first argument and a normal index on the second. As is, deep and normal indexes are nor combined so it must choose. If it goes for the deep index it will recurse, having the Int and Sym in the -/2 terms to work with. This puts it in exactly the same position as where it is with the simple plain term.

Given the plain term it will assess the indexes on the first and second argument (assuming these are instantiated). If one of these seems “good enough”, it uses that index. Otherwise will assess creating a combined index. You can expect fair performance in the lookup. You’ll have spurious choice points. As you claim the combination of the first two arguments is always unique, a cut solves that problem.

31

Thank you for the further insights Jan,

Its really my bad – to explore indexing i decided to place Sym into the first arg as a pair, while keeping Sym as second argument – rather than to shorten the fact to arity 2; and just to save typing,

I wasn’t aware that it would create this bad of a situation.

In the meantime I learned again something about indexing, and i reverted back to my earlier code as:

retract(fact(Int, Sym, List)),
!.

And, I guess, this may or may not generate a spurious choice point, depending on whether the JIT indexing will get enough of a chance to index fact(Int, Sym, …)

Edit:

To belabor the point once more a bit.

I would rather rely on an index than force a cut – i think its indexing is better to help catch a programming errors such, such as a assumed uniqueness not holding - and Prolog machinery generating a choice-point, where one should not be.

Dan