1. Forum
  2. Newsgroups
  3. comp.lang.prolog

  • Re: Summary of ISO draft - Help me find my mistakes

    From Mild Shock@bursejan@gmail.com to comp.lang.prolog on Thu Sep 28 13:17:16 2023
    From Newsgroup: comp.lang.prolog

    I guess it doesn't have term_singletons/2 in it, right?
    Its pretty difficult to implement, even Ulrich Neumerkel
    doesn't know a linear algorithm for this:

    /* SWI-Prolog 9.1.16 */
    bomb(0, 1) :- !.
    bomb(N, (X+X)) :- M is N-1, bomb(M, X)

    ?- between(23,27,N), bomb(N,X),
    time(term_singletons(X,_)), fail; true.
    % -1 inferences, 0.078 CPU in 0.074 seconds (106% CPU, -13 Lips)
    % -1 inferences, 0.141 CPU in 0.153 seconds (92% CPU, -7 Lips)
    % -1 inferences, 0.328 CPU in 0.322 seconds (102% CPU, -3 Lips)
    % -1 inferences, 0.672 CPU in 0.667 seconds (101% CPU, -1 Lips)
    % -1 inferences, 1.344 CPU in 1.350 seconds (100% CPU, -1 Lips)
    true.

    I got an idea with my variable spines, if they would have
    a singleton marking itself. If you have a spine, i.e. the
    the variables of a term before instantiation, and if you

    have singleton information in this spine already, I guess
    you only to visit the singletons in the spine, to collect the
    singletons. But maybe its too late to experiment with such

    a solution. Also spines, which are available in formerly Jekejeke
    Prolog, and can be already determined at compile time,
    didn't make it into Dogelog Player. So maybe another solution?

    Michael Covington schrieb am Sonntag, 13. Juni 1993 um 06:09:17 UTC+2:
    Below is a LaTeX document that will eventually be an appendix to
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Mild Shock@bursejan@gmail.com to comp.lang.prolog on Thu Sep 28 13:23:43 2023
    From Newsgroup: comp.lang.prolog

    Also singleton information is useful to optimize away
    the occurs check. I did some experiments in the past and
    there also papers which communicate these ideas.

    Until I discovered a way to do some occurs check optimization
    based on another idea, completely dynamical at runtime,
    without some compiletime analysis, which is now available in

    formerly Jekejeke Prolog. But again, none of this made
    it into Dogelog Player, which has only a traditional very
    basic unify_with_occurs_check/2 built-in, but no

    occurs check flag at all that would influence (=)/2.

    Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:17:19 UTC+2:
    I guess it doesn't have term_singletons/2 in it, right?
    Its pretty difficult to implement, even Ulrich Neumerkel
    doesn't know a linear algorithm for this:

    /* SWI-Prolog 9.1.16 */
    bomb(0, 1) :- !.
    bomb(N, (X+X)) :- M is N-1, bomb(M, X)

    ?- between(23,27,N), bomb(N,X),
    time(term_singletons(X,_)), fail; true.
    % -1 inferences, 0.078 CPU in 0.074 seconds (106% CPU, -13 Lips)
    % -1 inferences, 0.141 CPU in 0.153 seconds (92% CPU, -7 Lips)
    % -1 inferences, 0.328 CPU in 0.322 seconds (102% CPU, -3 Lips)
    % -1 inferences, 0.672 CPU in 0.667 seconds (101% CPU, -1 Lips)
    % -1 inferences, 1.344 CPU in 1.350 seconds (100% CPU, -1 Lips)
    true.

    I got an idea with my variable spines, if they would have
    a singleton marking itself. If you have a spine, i.e. the
    the variables of a term before instantiation, and if you

    have singleton information in this spine already, I guess
    you only to visit the singletons in the spine, to collect the
    singletons. But maybe its too late to experiment with such

    a solution. Also spines, which are available in formerly Jekejeke
    Prolog, and can be already determined at compile time,
    didn't make it into Dogelog Player. So maybe another solution?

    Michael Covington schrieb am Sonntag, 13. Juni 1993 um 06:09:17 UTC+2:
    Below is a LaTeX document that will eventually be an appendix to
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Mild Shock@bursejan@gmail.com to comp.lang.prolog on Fri Sep 29 00:15:37 2023
    From Newsgroup: comp.lang.prolog

    Woa! Ulrich Neumerkel is really lost. Its shows me again:
    "Error 404, brain not found". Is he really asking:

    More and more Prolog systems: Which systems?
    Which three other Prolog systems?

    For a start:

    https://www.swi-prolog.org/pldoc/man?predicate=term_singletons/2 https://github.com/trealla-prolog/trealla

    Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:23:45 UTC+2:
    Also singleton information is useful to optimize away
    the occurs check. I did some experiments in the past and
    there also papers which communicate these ideas.

    Until I discovered a way to do some occurs check optimization
    based on another idea, completely dynamical at runtime,
    without some compiletime analysis, which is now available in

    formerly Jekejeke Prolog. But again, none of this made
    it into Dogelog Player, which has only a traditional very
    basic unify_with_occurs_check/2 built-in, but no

    occurs check flag at all that would influence (=)/2.
    Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:17:19 UTC+2:
    I guess it doesn't have term_singletons/2 in it, right?
    Its pretty difficult to implement, even Ulrich Neumerkel
    doesn't know a linear algorithm for this:

    /* SWI-Prolog 9.1.16 */
    bomb(0, 1) :- !.
    bomb(N, (X+X)) :- M is N-1, bomb(M, X)

    ?- between(23,27,N), bomb(N,X),
    time(term_singletons(X,_)), fail; true.
    % -1 inferences, 0.078 CPU in 0.074 seconds (106% CPU, -13 Lips)
    % -1 inferences, 0.141 CPU in 0.153 seconds (92% CPU, -7 Lips)
    % -1 inferences, 0.328 CPU in 0.322 seconds (102% CPU, -3 Lips)
    % -1 inferences, 0.672 CPU in 0.667 seconds (101% CPU, -1 Lips)
    % -1 inferences, 1.344 CPU in 1.350 seconds (100% CPU, -1 Lips)
    true.

    I got an idea with my variable spines, if they would have
    a singleton marking itself. If you have a spine, i.e. the
    the variables of a term before instantiation, and if you

    have singleton information in this spine already, I guess
    you only to visit the singletons in the spine, to collect the
    singletons. But maybe its too late to experiment with such

    a solution. Also spines, which are available in formerly Jekejeke
    Prolog, and can be already determined at compile time,
    didn't make it into Dogelog Player. So maybe another solution?

    Michael Covington schrieb am Sonntag, 13. Juni 1993 um 06:09:17 UTC+2:
    Below is a LaTeX document that will eventually be an appendix to
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Mild Shock@bursejan@gmail.com to comp.lang.prolog on Fri Sep 29 00:18:22 2023
    From Newsgroup: comp.lang.prolog

    But this is a genious test case:

    marquee(L,M) :-
    append(L,R,LD),
    append(R,M,LD).

    I was rather thinking about:

    marquee2(L,M) :-
    repeat,
    append(A,B,L),
    append(B,A,M).

    marquee2/2 obviously can run indefinitely. But can your Prolog
    system run marquee/2 also indefinitely, like here:

    ?- marquee("prolog", _), fail; true.

    Mild Shock schrieb am Freitag, 29. September 2023 um 09:15:39 UTC+2:
    Woa! Ulrich Neumerkel is really lost. Its shows me again:
    "Error 404, brain not found". Is he really asking:

    More and more Prolog systems: Which systems?
    Which three other Prolog systems?

    For a start:

    https://www.swi-prolog.org/pldoc/man?predicate=term_singletons/2 https://github.com/trealla-prolog/trealla
    Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:23:45 UTC+2:
    Also singleton information is useful to optimize away
    the occurs check. I did some experiments in the past and
    there also papers which communicate these ideas.

    Until I discovered a way to do some occurs check optimization
    based on another idea, completely dynamical at runtime,
    without some compiletime analysis, which is now available in

    formerly Jekejeke Prolog. But again, none of this made
    it into Dogelog Player, which has only a traditional very
    basic unify_with_occurs_check/2 built-in, but no

    occurs check flag at all that would influence (=)/2.
    Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:17:19 UTC+2:
    I guess it doesn't have term_singletons/2 in it, right?
    Its pretty difficult to implement, even Ulrich Neumerkel
    doesn't know a linear algorithm for this:

    /* SWI-Prolog 9.1.16 */
    bomb(0, 1) :- !.
    bomb(N, (X+X)) :- M is N-1, bomb(M, X)

    ?- between(23,27,N), bomb(N,X),
    time(term_singletons(X,_)), fail; true.
    % -1 inferences, 0.078 CPU in 0.074 seconds (106% CPU, -13 Lips)
    % -1 inferences, 0.141 CPU in 0.153 seconds (92% CPU, -7 Lips)
    % -1 inferences, 0.328 CPU in 0.322 seconds (102% CPU, -3 Lips)
    % -1 inferences, 0.672 CPU in 0.667 seconds (101% CPU, -1 Lips)
    % -1 inferences, 1.344 CPU in 1.350 seconds (100% CPU, -1 Lips)
    true.

    I got an idea with my variable spines, if they would have
    a singleton marking itself. If you have a spine, i.e. the
    the variables of a term before instantiation, and if you

    have singleton information in this spine already, I guess
    you only to visit the singletons in the spine, to collect the singletons. But maybe its too late to experiment with such

    a solution. Also spines, which are available in formerly Jekejeke Prolog, and can be already determined at compile time,
    didn't make it into Dogelog Player. So maybe another solution?

    Michael Covington schrieb am Sonntag, 13. Juni 1993 um 06:09:17 UTC+2:
    Below is a LaTeX document that will eventually be an appendix to
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Mild Shock@bursejan@gmail.com to comp.lang.prolog on Fri Sep 29 00:20:33 2023
    From Newsgroup: comp.lang.prolog

    A better test case is this query:

    ?- append(Y, X, [1,2,3|Y]), fail; true.

    Versus this query:

    test(X) :- append(Y, X, [1,2,3|Y]).
    ?- test(X), fail; true.

    Which one runs indefinitely in a Prolog system with
    good last call optimization? And why?

    Mild Shock schrieb am Freitag, 29. September 2023 um 09:18:24 UTC+2:
    But this is a genious test case:

    marquee(L,M) :-
    append(L,R,LD),
    append(R,M,LD).

    I was rather thinking about:

    marquee2(L,M) :-
    repeat,
    append(A,B,L),
    append(B,A,M).

    marquee2/2 obviously can run indefinitely. But can your Prolog
    system run marquee/2 also indefinitely, like here:

    ?- marquee("prolog", _), fail; true.
    Mild Shock schrieb am Freitag, 29. September 2023 um 09:15:39 UTC+2:
    Woa! Ulrich Neumerkel is really lost. Its shows me again:
    "Error 404, brain not found". Is he really asking:

    More and more Prolog systems: Which systems?
    Which three other Prolog systems?

    For a start:

    https://www.swi-prolog.org/pldoc/man?predicate=term_singletons/2 https://github.com/trealla-prolog/trealla
    Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:23:45 UTC+2:
    Also singleton information is useful to optimize away
    the occurs check. I did some experiments in the past and
    there also papers which communicate these ideas.

    Until I discovered a way to do some occurs check optimization
    based on another idea, completely dynamical at runtime,
    without some compiletime analysis, which is now available in

    formerly Jekejeke Prolog. But again, none of this made
    it into Dogelog Player, which has only a traditional very
    basic unify_with_occurs_check/2 built-in, but no

    occurs check flag at all that would influence (=)/2.
    Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:17:19 UTC+2:
    I guess it doesn't have term_singletons/2 in it, right?
    Its pretty difficult to implement, even Ulrich Neumerkel
    doesn't know a linear algorithm for this:

    /* SWI-Prolog 9.1.16 */
    bomb(0, 1) :- !.
    bomb(N, (X+X)) :- M is N-1, bomb(M, X)

    ?- between(23,27,N), bomb(N,X),
    time(term_singletons(X,_)), fail; true.
    % -1 inferences, 0.078 CPU in 0.074 seconds (106% CPU, -13 Lips)
    % -1 inferences, 0.141 CPU in 0.153 seconds (92% CPU, -7 Lips)
    % -1 inferences, 0.328 CPU in 0.322 seconds (102% CPU, -3 Lips)
    % -1 inferences, 0.672 CPU in 0.667 seconds (101% CPU, -1 Lips)
    % -1 inferences, 1.344 CPU in 1.350 seconds (100% CPU, -1 Lips)
    true.

    I got an idea with my variable spines, if they would have
    a singleton marking itself. If you have a spine, i.e. the
    the variables of a term before instantiation, and if you

    have singleton information in this spine already, I guess
    you only to visit the singletons in the spine, to collect the singletons. But maybe its too late to experiment with such

    a solution. Also spines, which are available in formerly Jekejeke Prolog, and can be already determined at compile time,
    didn't make it into Dogelog Player. So maybe another solution?

    Michael Covington schrieb am Sonntag, 13. Juni 1993 um 06:09:17 UTC+2:
    Below is a LaTeX document that will eventually be an appendix to
    --- Synchronet 3.20a-Linux NewsLink 1.114