-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Much slower than SWI checking [wn_valid] from wordnet-prolog #1681
Comments
Would you mind reducing the size of your finding? For example, you could introduce |
... or just compare |
Wherever its 2nd arg was a fixed-length list, I had replaced |
Indeed, |
It's all in ?- time((multikey(X), false)).
% CPU time: 3716.558s
false. SWI by comparison: ?- time((multikey(X), false)). % Using swipl
% 414,620 inferences, 0.078 CPU in 0.078 seconds (100% CPU, 5328386 Lips)
false. Here is multikey(K):-
sk(I,_,K),
sk(J,_,K),
I\=J. I am sold on failure slicing! |
This seems like an issue with indexing. Specifically, we have: multikey(K):- sk(I,_,K), sk(J,_,K), I\=J. where In the highlighted goal above, i.e., Scryer Prolog currently only indexes on the first instantiated argument that occurs in any clause of a predicate, so in this case, only the first argument of Such an issue can be worked around "manually", by adding (or generating) auxiliary facts, say Ideally of course, the system would automatically generate suitable indices on demand, depending on which arguments are instantiated at the time of the call, so that the fitting clauses can later be found much more quickly. Related to #192. |
This is most helpful, thank you @triska! I just now naively tried sk_3(K,I,J) :- sk(I,J,K).
multikey(K):-
sk_3(K,I,_),
sk_3(K,J,_),
I\=J. but of course this does not speed anything up because it is the underlying facts that get indexed. Is there any more declarative way to 'request' indexing than writing permuted facts one-by-one? |
For the time being, maybe the best I can contribute back to the original repo via PR would be increased ISO standard compliance? I'll see what I can do to get this code running with |
@dcnorris: Improving ISO compliance for better portability would definitely help already, if only to make such comparisons between different systems easier. Regarding the auxiliary facts specifically useful for Scryer Prolog and other systems with limited built-in indexing, you may be able to use Scryer Prolog's For example, try: :- discontiguous(sk_1/3). :- discontiguous(sk_3/3). sk(X, Y, Z) :- sk_1(X, Y, Z). term_expansion(sk(X,Y,Z), [sk_1(X,Y,Z), sk_3(Z,X,Y)]). sk(100001740,1,'entity%1:03:00::'). sk(100001930,1,'physical_entity%1:03:00::'). sk(100002137,1,'abstraction%1:03:00::'). sk(100002137,2,'abstract_entity%1:03:00::'). sk(100002452,1,'thing%1:03:00::'). sk(100002684,1,'object%1:03:00::'). sk(100002684,2,'physical_object%1:03:00::'). ... In this way, you automatically get, for each |
And building on that, you can extend sk(X, Y, Z) :- ( nonvar(X) -> sk_1(X, Y, Z) ; nonvar(Z) -> sk_3(Z, X, Y) ; sk_1(X, Y, Z) ). In this way, all your code can use |
I find |
From the GNU Prolog documentation:
|
Too bad about these |
Syntax is excellent. Currently the best. Weak points are
|
You can use Logtalk's portable term-expansion mechanism to easily expand a Prolog file into another Prolog file. See: This solution will work with all Logtalk supported backend Prolog systems, including Scryer Prolog and GNU Prolog. P.S. I maintain a Prolog packs registry for WordNet at https://github.com/LogtalkDotOrg/wordnet It includes a pack manifest file for the project you forked. |
Cowabunga: % Appended the following to 'scryer.pl'
:- discontiguous(sk_1/3).
:- discontiguous(sk_3/3).
term_expansion(sk(X,Y,Z),
[sk_1(X,Y,Z),
sk_3(Z,X,Y)]).
sk(X, Y, Z) :-
( nonvar(X) ->
sk_1(X, Y, Z)
; nonvar(Z) ->
sk_3(Z, X, Y)
; sk_1(X, Y, Z)
). Result: ?- [wn_valid].
output/wn_valid.pl-Output-3.1
Semantic Relations: [at,cs,ent,hyp,ins,mm,mp,ms,sim,vgp]
... etc. etc. ...
% CPU time: 30.251s
true.
?- |
With the above application of |
@pmoura I can confirm that @triska's solution indeed does not work in 'gprolog.pl' as it does in 'scryer.pl.' But may I expect that after loading all the facts, I could simply |
May I suggest to use the GNU Prolog repository to file and discuss GNU Prolog-specific issues: |
I have added a support for To try it: simply replace in
@dcnorris I had to do several changes in the original code from Eric Kafe (too much SWI-oriented). I also implemented the changes for the `term_expansion/2' solution and for the above solution. I can share them with you if you want. |
I have forked ekaf/wordnet-prolog and made a few changes needed to get a validity check to run in Scryer.
Whereas
swipl
does[wn_valid].
in about 13 seconds, I find thatscryer-prolog
("v0.9.1-51-gfd191285") takes 1 hour. All but 24 seconds of this is spent in goalcheck_keys/0
:The text was updated successfully, but these errors were encountered: