Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.prolog > #14634 > unrolled thread

The Ghosts in my Cabinet: Indexing

Back to article view | Back to comp.lang.prolog

Contents

  The Ghosts in my Cabinet: Indexing Mild Shock <janburse@fastmail.fm> - 2025-07-10 12:45 +0200
    Observed while watching FAIL/REDO ports (Was: The Ghosts in my Cabinet: Indexing) Mild Shock <janburse@fastmail.fm> - 2025-07-10 12:46 +0200
      Shocking Revelation: No eGovernment can trust Prolog! (Was: Observed while watching FAIL/REDO ports) Mild Shock <janburse@fastmail.fm> - 2025-07-10 13:26 +0200
        Easier certification with 100% Prolog Prolog? (Was: Shocking Revelation: No eGovernment can trust Prolog!) Mild Shock <janburse@fastmail.fm> - 2025-07-10 14:05 +0200
          Doing a Prolog system without any iterator API (Was: Easier certification with 100% Prolog Prolog?) Mild Shock <janburse@fastmail.fm> - 2025-07-10 14:14 +0200
            The headache with JIT indexing: Native -> Prolog (Was: Doing a Prolog system without any iterator API) Mild Shock <janburse@fastmail.fm> - 2025-07-10 14:40 +0200
              Just lets burn another candle for Barty Boy (Was: The headache with JIT indexing: Native -> Prolog) Mild Shock <janburse@fastmail.fm> - 2025-07-10 18:13 +0200
                Physics PhDs might never have heard of Quantifier Eliminations (Re: Just lets burn another candle for Barty Boy) Mild Shock <janburse@fastmail.fm> - 2025-07-10 18:33 +0200
                  How long willl I piss on Bart Demoen (Was: Physics PhDs might never have heard of Quantifier Eliminations) Mild Shock <janburse@fastmail.fm> - 2025-07-10 18:39 +0200
                    But I shouldn't waste too much time (Was: How long willl I piss on Bart Demoen) Mild Shock <janburse@fastmail.fm> - 2025-07-10 19:13 +0200
    DCG is easily affected (Was: The Ghosts in my Cabinet: Indexing) Mild Shock <janburse@fastmail.fm> - 2025-07-11 09:38 +0200
      The headache an eGovernment might get from Prolog (Was: DCG is easily affected) Mild Shock <janburse@fastmail.fm> - 2025-07-15 15:20 +0200
        Wait till they find out about compare/3 (Was: The headache an eGovernment might get from Prolog) Mild Shock <janburse@fastmail.fm> - 2025-07-15 15:24 +0200
          Corr. (Was: Wait till they find out about compare/3) Mild Shock <janburse@fastmail.fm> - 2025-07-15 15:28 +0200
            eGovernements will need AGI to survive (Was: Corr. (Was: Wait till they find out about compare/3)) Mild Shock <janburse@fastmail.fm> - 2025-07-15 18:41 +0200
              Having 2544 issues is probably a bad sign (Re: eGovernements will need AGI to survive) Mild Shock <janburse@fastmail.fm> - 2025-07-15 18:41 +0200
                The Signal Collapse gives us System Uncertainty (Re: Having 2544 issues is probably a bad sign) Mild Shock <janburse@fastmail.fm> - 2025-07-15 19:02 +0200
                  Rename GitHub, to TurdPit, and make Amber Heard their CEO (Was: The Signal Collapse gives us System Uncertainty) Mild Shock <janburse@fastmail.fm> - 2025-07-15 19:52 +0200
              Humans are just overwhelmed by computers (Was: eGovernements will need AGI to survive) Mild Shock <janburse@fastmail.fm> - 2025-07-16 18:59 +0200
                Fishy 🐟 in Scryer Prolog and SWI-Prolog (Was: Humans are just overwhelmed by computers) Mild Shock <janburse@fastmail.fm> - 2025-07-16 20:08 +0200
                  So we are essentially all using Trojan Horses 🐎 daily? (Re: Fishy 🐟 in Scryer Prolog and SWI-Prolog) Mild Shock <janburse@fastmail.fm> - 2025-07-17 10:57 +0200
                  Strudel Rust gives Scryer Frust 💩: Try C+20 Pipes (Was: Fishy 🐟 in Scryer Prolog and SWI-Prolog( Mild Shock <janburse@fastmail.fm> - 2025-11-25 22:55 +0100
                SWI-Prolog as a Test Bed for Copilots (Was: Humans are just overwhelmed by computers) Mild Shock <janburse@fastmail.fm> - 2025-07-20 14:36 +0200
                  Mathematics currently hates Computer Science because of AI (Re: SWI-Prolog as a Test Bed for Copilots) Mild Shock <janburse@fastmail.fm> - 2025-07-20 15:13 +0200

Page 1 of 2  [1] 2  Next page →

#14634 — The Ghosts in my Cabinet: Indexing

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

[toc] | [next] | [standalone]

#14635 — Observed while watching FAIL/REDO ports (Was: The Ghosts in my Cabinet: Indexing)

I made the observation while looking at
debugger traces, choice point elimination,
driven by indexes, also determines what
FAIL/REDO ports a debugger shows.

What is amazing Scryer Prolog, which has
a tamer version of multi-argument indexing, a
kind of skip indexing, they describe
it on their GitHub homepage, can do it:

/* Scryer Prolog 0.9.4-415 */
?- app(X,Y,[1]).
    X = [], Y = [1]
;  X = [1], Y = [].

And the ghost from my cabinet, formerly
Jekejeke Prolog, which does a little bit more
than skip indexing, but still not the same deep
indexing as in SWI-Prolog can also do it:

/* Jekejeke Runtime 1.7.3 */
?- app(X,Y,[1]).
X = [], Y = [1];
X = [1], Y = [].

Mild Shock schrieb:
> I am currently doing a re-evaluation of an old
> Prolog system, checking what features I could adopt.
> This is unlike the current trend where people have
> turned their focus on GUIs, like XPCE,
> 
> or a are stuck in an endless loop of parser
> problems, like in Trealla. But I would nevertheless
> share my finding. Take this simple example of
> a list append:
> 
> app([], X, X).
> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
> 
> ECLiPSe Prolog gives me, only one redo question
> in the top-level:
> 
> /* ECLiPSe Prolog 7.1beta #13 */
> [eclipse 2]: app(X,Y,[1]).
> 
> X = []
> Y = [1]
> Yes (0.00s cpu, solution 1, maybe more) ? ;
> 
> X = [1]
> Y = []
> Yes (0.00s cpu, solution 2)
> 
> In SWI-Prolog I find, two redo questions
> in the top.level:
> 
> /* SWI-Prolog 9.3.25 */
> ?- app(X,Y,[1]).
> X = [],
> Y = [1] ;
> X = [1],
> Y = [] ;
> false.
> 
> I know SWI-Prolog handles lists differently
> than other Prolog terms during indexing. Could
> this be the reason? Or maybe that the call is
> not “hot” enough, so it doesn’t get JIT-ed.
> 
> ECLiPSe Prolog does it on the very first call,
> and I assume its due to a kind of index on
> the 3rd argument.
> 

[toc] | [prev] | [next] | [standalone]

#14636 — Shocking Revelation: No eGovernment can trust Prolog! (Was: Observed while watching FAIL/REDO ports)

Hi,

Shocking revelation, I found two significant
bugs in my age old indexer code base yesterday.
How can an eGovernment ever trust any Prolog
system? These were bugs that typically go

unnoticed by lets say a Rust type system.
Would possibly require deep axiomatization
or heavy fuzzy testing of the code, or a
combination of both.

LoL

Bye

Mild Shock schrieb:
> I made the observation while looking at
> debugger traces, choice point elimination,
> driven by indexes, also determines what
> FAIL/REDO ports a debugger shows.
> 
> What is amazing Scryer Prolog, which has
> a tamer version of multi-argument indexing, a
> kind of skip indexing, they describe
> it on their GitHub homepage, can do it:
> 
> /* Scryer Prolog 0.9.4-415 */
> ?- app(X,Y,[1]).
>     X = [], Y = [1]
> ;  X = [1], Y = [].
> 
> And the ghost from my cabinet, formerly
> Jekejeke Prolog, which does a little bit more
> than skip indexing, but still not the same deep
> indexing as in SWI-Prolog can also do it:
> 
> /* Jekejeke Runtime 1.7.3 */
> ?- app(X,Y,[1]).
> X = [], Y = [1];
> X = [1], Y = [].
> 
> Mild Shock schrieb:
>> I am currently doing a re-evaluation of an old
>> Prolog system, checking what features I could adopt.
>> This is unlike the current trend where people have
>> turned their focus on GUIs, like XPCE,
>>
>> or a are stuck in an endless loop of parser
>> problems, like in Trealla. But I would nevertheless
>> share my finding. Take this simple example of
>> a list append:
>>
>> app([], X, X).
>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>
>> ECLiPSe Prolog gives me, only one redo question
>> in the top-level:
>>
>> /* ECLiPSe Prolog 7.1beta #13 */
>> [eclipse 2]: app(X,Y,[1]).
>>
>> X = []
>> Y = [1]
>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>
>> X = [1]
>> Y = []
>> Yes (0.00s cpu, solution 2)
>>
>> In SWI-Prolog I find, two redo questions
>> in the top.level:
>>
>> /* SWI-Prolog 9.3.25 */
>> ?- app(X,Y,[1]).
>> X = [],
>> Y = [1] ;
>> X = [1],
>> Y = [] ;
>> false.
>>
>> I know SWI-Prolog handles lists differently
>> than other Prolog terms during indexing. Could
>> this be the reason? Or maybe that the call is
>> not “hot” enough, so it doesn’t get JIT-ed.
>>
>> ECLiPSe Prolog does it on the very first call,
>> and I assume its due to a kind of index on
>> the 3rd argument.
>>
> 

[toc] | [prev] | [next] | [standalone]

#14637 — Easier certification with 100% Prolog Prolog? (Was: Shocking Revelation: No eGovernment can trust Prolog!)

Hi,

Is there an easier certification with a Prolog
system that is written 100% in Prolog itself. Maybe
or maybe not, I don't know, it feels a little bit

like having implemented a Prolog system by taking
the declarative specification of in the appendix
of the ISO core standard, except I didn't use the

always declarative style of the ISO appendix. It
doesn't make any sense practically for a declarative
style and have later some Prolog system which is either

inefficient because the choice points explode or
something impractical without I/O effects like the
html//1 thingy in SWI-Prolog.

Bye

Mild Shock schrieb:
> Hi,
> 
> Shocking revelation, I found two significant
> bugs in my age old indexer code base yesterday.
> How can an eGovernment ever trust any Prolog
> system? These were bugs that typically go
> 
> unnoticed by lets say a Rust type system.
> Would possibly require deep axiomatization
> or heavy fuzzy testing of the code, or a
> combination of both.
> 
> LoL
> 
> Bye
> 
> Mild Shock schrieb:
>> I made the observation while looking at
>> debugger traces, choice point elimination,
>> driven by indexes, also determines what
>> FAIL/REDO ports a debugger shows.
>>
>> What is amazing Scryer Prolog, which has
>> a tamer version of multi-argument indexing, a
>> kind of skip indexing, they describe
>> it on their GitHub homepage, can do it:
>>
>> /* Scryer Prolog 0.9.4-415 */
>> ?- app(X,Y,[1]).
>>     X = [], Y = [1]
>> ;  X = [1], Y = [].
>>
>> And the ghost from my cabinet, formerly
>> Jekejeke Prolog, which does a little bit more
>> than skip indexing, but still not the same deep
>> indexing as in SWI-Prolog can also do it:
>>
>> /* Jekejeke Runtime 1.7.3 */
>> ?- app(X,Y,[1]).
>> X = [], Y = [1];
>> X = [1], Y = [].
>>
>> Mild Shock schrieb:
>>> I am currently doing a re-evaluation of an old
>>> Prolog system, checking what features I could adopt.
>>> This is unlike the current trend where people have
>>> turned their focus on GUIs, like XPCE,
>>>
>>> or a are stuck in an endless loop of parser
>>> problems, like in Trealla. But I would nevertheless
>>> share my finding. Take this simple example of
>>> a list append:
>>>
>>> app([], X, X).
>>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>>
>>> ECLiPSe Prolog gives me, only one redo question
>>> in the top-level:
>>>
>>> /* ECLiPSe Prolog 7.1beta #13 */
>>> [eclipse 2]: app(X,Y,[1]).
>>>
>>> X = []
>>> Y = [1]
>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>
>>> X = [1]
>>> Y = []
>>> Yes (0.00s cpu, solution 2)
>>>
>>> In SWI-Prolog I find, two redo questions
>>> in the top.level:
>>>
>>> /* SWI-Prolog 9.3.25 */
>>> ?- app(X,Y,[1]).
>>> X = [],
>>> Y = [1] ;
>>> X = [1],
>>> Y = [] ;
>>> false.
>>>
>>> I know SWI-Prolog handles lists differently
>>> than other Prolog terms during indexing. Could
>>> this be the reason? Or maybe that the call is
>>> not “hot” enough, so it doesn’t get JIT-ed.
>>>
>>> ECLiPSe Prolog does it on the very first call,
>>> and I assume its due to a kind of index on
>>> the 3rd argument.
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14638 — Doing a Prolog system without any iterator API (Was: Easier certification with 100% Prolog Prolog?)

Hi,

Most of the libraries and the system are design so
that native is a last resort. So most functionality is
Prolog and in a few instances there is a native call:

- Main Design:

   Prolog (a lot of it) --> Native (very little)

This design, concerning the call control flow, is only
broken in the top level, and in very few places, like the
browser and a web server. The top-level is a native entry

point and it needs to reach into Prolog, and the
libraries library(react) and library(spin) provide call
back facilities for the browser and a web

server event handlers:

- 2nd Design:

   Native (top-level, react and spin) --> Prolog

There is no idea at all that the Prolog system supports
any iterators. I did this in the past. But the Prolog
system gets simpler without the viewpoint that the

interface should support iterators. SWI-Prolog always
invests heavily to support iterators. Based on the
rather negative experience with formerly Jekejeke Prolog

we tried to completely avoid any iterator interface.

Bye

Mild Shock schrieb:
> Hi,
> 
> Is there an easier certification with a Prolog
> system that is written 100% in Prolog itself. Maybe
> or maybe not, I don't know, it feels a little bit
> 
> like having implemented a Prolog system by taking
> the declarative specification of in the appendix
> of the ISO core standard, except I didn't use the
> 
> always declarative style of the ISO appendix. It
> doesn't make any sense practically for a declarative
> style and have later some Prolog system which is either
> 
> inefficient because the choice points explode or
> something impractical without I/O effects like the
> html//1 thingy in SWI-Prolog.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Shocking revelation, I found two significant
>> bugs in my age old indexer code base yesterday.
>> How can an eGovernment ever trust any Prolog
>> system? These were bugs that typically go
>>
>> unnoticed by lets say a Rust type system.
>> Would possibly require deep axiomatization
>> or heavy fuzzy testing of the code, or a
>> combination of both.
>>
>> LoL
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> I made the observation while looking at
>>> debugger traces, choice point elimination,
>>> driven by indexes, also determines what
>>> FAIL/REDO ports a debugger shows.
>>>
>>> What is amazing Scryer Prolog, which has
>>> a tamer version of multi-argument indexing, a
>>> kind of skip indexing, they describe
>>> it on their GitHub homepage, can do it:
>>>
>>> /* Scryer Prolog 0.9.4-415 */
>>> ?- app(X,Y,[1]).
>>>     X = [], Y = [1]
>>> ;  X = [1], Y = [].
>>>
>>> And the ghost from my cabinet, formerly
>>> Jekejeke Prolog, which does a little bit more
>>> than skip indexing, but still not the same deep
>>> indexing as in SWI-Prolog can also do it:
>>>
>>> /* Jekejeke Runtime 1.7.3 */
>>> ?- app(X,Y,[1]).
>>> X = [], Y = [1];
>>> X = [1], Y = [].
>>>
>>> Mild Shock schrieb:
>>>> I am currently doing a re-evaluation of an old
>>>> Prolog system, checking what features I could adopt.
>>>> This is unlike the current trend where people have
>>>> turned their focus on GUIs, like XPCE,
>>>>
>>>> or a are stuck in an endless loop of parser
>>>> problems, like in Trealla. But I would nevertheless
>>>> share my finding. Take this simple example of
>>>> a list append:
>>>>
>>>> app([], X, X).
>>>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>>>
>>>> ECLiPSe Prolog gives me, only one redo question
>>>> in the top-level:
>>>>
>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>> [eclipse 2]: app(X,Y,[1]).
>>>>
>>>> X = []
>>>> Y = [1]
>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>
>>>> X = [1]
>>>> Y = []
>>>> Yes (0.00s cpu, solution 2)
>>>>
>>>> In SWI-Prolog I find, two redo questions
>>>> in the top.level:
>>>>
>>>> /* SWI-Prolog 9.3.25 */
>>>> ?- app(X,Y,[1]).
>>>> X = [],
>>>> Y = [1] ;
>>>> X = [1],
>>>> Y = [] ;
>>>> false.
>>>>
>>>> I know SWI-Prolog handles lists differently
>>>> than other Prolog terms during indexing. Could
>>>> this be the reason? Or maybe that the call is
>>>> not “hot” enough, so it doesn’t get JIT-ed.
>>>>
>>>> ECLiPSe Prolog does it on the very first call,
>>>> and I assume its due to a kind of index on
>>>> the 3rd argument.
>>>>
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14639 — The headache with JIT indexing: Native -> Prolog (Was: Doing a Prolog system without any iterator API)

Hi,

There is one thing that currently causes me headaches.
So far the Dogelog Player design didn't have a big
ping pong from Prolog to Native and back.

It has the Main Design with Prolog --> Native, and
the 2nd Design with Native --> Prolog. We also managed
to do some clause indexing preparation

in the Main Design, so we have this separation of concerning
currently for first argument indexing:

- Computation of Clause Key Value: Prolog
   The computation of the Key Value of a clause is done
   at compile time in pure Prolog. There are two strategies,
   for dynamic predicates the key is directly taken from
   the first argument of the head.

   For static predicates the body of the claue is also
   analyzed, and this can also give a key, like for
   exaple if the body as a unification X = C, and X
   appears as first argument, the the key can be taken from C.

- Computation of Goal/Head Key Value: Native
   The clauses are supplied with their Key Value, and
   Native code does add them with indexing. Or update the
   index when a clause is removed.

   The computation of the Key Value of a goal or clause
   head is done a runtime in Native. And then the lookup
   is done natively as well.

Now I wonder how I can bring multi-argument JIT Indexing
from formerly Jekejeke Prolog into the picture, and still
have a high degree of 100% Prolog code. Some hurdles:

- Clause Key Value on Demand: Native -> Prolog
   So if I would keep the scheme that Prolog determines the
   clause Key Values. And if I would do this on demand,
   I would have a Native -> Prolog call.

- Clauses would need decompile:
   Even if I implement such a Native -> Prolog hook,
   the problem is Clauses have not the compile time format
   at runtime. So the my old 100% Prolog code for Clause
   Key Value will not work, requires first decompilation.

- YAP approach:
   I have an old paper from YAP. For the indexing they
   are scanning the native clause code. I didn't double
   check yet what SWI-Prolog (has JIT-ing) or Scryer Prolog
   (doesn't do it JIT style?). Etc...

- What else?

Well its not a big headache, but a kind of blocker,
before I decide what to do. There are a couple of options
to get out of the dilemma, and turn the Prolog systems

around, and make it 100% Prolog again. Its like the
big beautiful bill by Donald Trump. Make Prolog
100% Prolog again!

LoL

Bye

Mild Shock schrieb:
> Hi,
> 
> Most of the libraries and the system are design so
> that native is a last resort. So most functionality is
> Prolog and in a few instances there is a native call:
> 
> - Main Design:
> 
>    Prolog (a lot of it) --> Native (very little)
> 
> This design, concerning the call control flow, is only
> broken in the top level, and in very few places, like the
> browser and a web server. The top-level is a native entry
> 
> point and it needs to reach into Prolog, and the
> libraries library(react) and library(spin) provide call
> back facilities for the browser and a web
> 
> server event handlers:
> 
> - 2nd Design:
> 
>    Native (top-level, react and spin) --> Prolog
> 
> There is no idea at all that the Prolog system supports
> any iterators. I did this in the past. But the Prolog
> system gets simpler without the viewpoint that the
> 
> interface should support iterators. SWI-Prolog always
> invests heavily to support iterators. Based on the
> rather negative experience with formerly Jekejeke Prolog
> 
> we tried to completely avoid any iterator interface.
> 
> Bye

[toc] | [prev] | [next] | [standalone]

#14640 — Just lets burn another candle for Barty Boy (Was: The headache with JIT indexing: Native -> Prolog)

Hi,

I have really interesting ghosts in by cabinet.
Not only old software, also crazy people like
Bart Demoen. And the good thing everything is

still available through Google Groups that
has nicely preserved comp.lang.prolog. According
Barty Boy the term "Choice Point Elimination"

didn't really exist:

 > Anyway, I have no idea what "choice point
 > elimination" is supposed to refer to in literature.
 >
 > Literally, "choice point elimination" should mean
 > something related to: a choicepoint was created
 > some technique eliminates that choice point

https://groups.google.com/g/comp.lang.prolog/c/qnwD_TEG4xg/m/LMiDtFY1dQIJ

Well he is somehow right if "elimination" is
interpreted as creating and then destroying.
But it could also mean preventing the creation

of a choice point. You never know from the
far of a the flemish / dutch mountains what a
term means. Even if somebody presents a corpus

resarch as I did.

Bye

Mild Shock schrieb:
> Hi,
> 
> There is one thing that currently causes me headaches.
> So far the Dogelog Player design didn't have a big
> ping pong from Prolog to Native and back.
> 
> It has the Main Design with Prolog --> Native, and
> the 2nd Design with Native --> Prolog. We also managed
> to do some clause indexing preparation
> 
> in the Main Design, so we have this separation of concerning
> currently for first argument indexing:
> 
> - Computation of Clause Key Value: Prolog
>    The computation of the Key Value of a clause is done
>    at compile time in pure Prolog. There are two strategies,
>    for dynamic predicates the key is directly taken from
>    the first argument of the head.
> 
>    For static predicates the body of the claue is also
>    analyzed, and this can also give a key, like for
>    exaple if the body as a unification X = C, and X
>    appears as first argument, the the key can be taken from C.
> 
> - Computation of Goal/Head Key Value: Native
>    The clauses are supplied with their Key Value, and
>    Native code does add them with indexing. Or update the
>    index when a clause is removed.
> 
>    The computation of the Key Value of a goal or clause
>    head is done a runtime in Native. And then the lookup
>    is done natively as well.
> 
> Now I wonder how I can bring multi-argument JIT Indexing
> from formerly Jekejeke Prolog into the picture, and still
> have a high degree of 100% Prolog code. Some hurdles:
> 
> - Clause Key Value on Demand: Native -> Prolog
>    So if I would keep the scheme that Prolog determines the
>    clause Key Values. And if I would do this on demand,
>    I would have a Native -> Prolog call.
> 
> - Clauses would need decompile:
>    Even if I implement such a Native -> Prolog hook,
>    the problem is Clauses have not the compile time format
>    at runtime. So the my old 100% Prolog code for Clause
>    Key Value will not work, requires first decompilation.
> 
> - YAP approach:
>    I have an old paper from YAP. For the indexing they
>    are scanning the native clause code. I didn't double
>    check yet what SWI-Prolog (has JIT-ing) or Scryer Prolog
>    (doesn't do it JIT style?). Etc...
> 
> - What else?
> 
> Well its not a big headache, but a kind of blocker,
> before I decide what to do. There are a couple of options
> to get out of the dilemma, and turn the Prolog systems
> 
> around, and make it 100% Prolog again. Its like the
> big beautiful bill by Donald Trump. Make Prolog
> 100% Prolog again!
> 
> LoL
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Most of the libraries and the system are design so
>> that native is a last resort. So most functionality is
>> Prolog and in a few instances there is a native call:
>>
>> - Main Design:
>>
>>    Prolog (a lot of it) --> Native (very little)
>>
>> This design, concerning the call control flow, is only
>> broken in the top level, and in very few places, like the
>> browser and a web server. The top-level is a native entry
>>
>> point and it needs to reach into Prolog, and the
>> libraries library(react) and library(spin) provide call
>> back facilities for the browser and a web
>>
>> server event handlers:
>>
>> - 2nd Design:
>>
>>    Native (top-level, react and spin) --> Prolog
>>
>> There is no idea at all that the Prolog system supports
>> any iterators. I did this in the past. But the Prolog
>> system gets simpler without the viewpoint that the
>>
>> interface should support iterators. SWI-Prolog always
>> invests heavily to support iterators. Based on the
>> rather negative experience with formerly Jekejeke Prolog
>>
>> we tried to completely avoid any iterator interface.
>>
>> Bye

[toc] | [prev] | [next] | [standalone]

#14641 — Physics PhDs might never have heard of Quantifier Eliminations (Re: Just lets burn another candle for Barty Boy)

Hi,

But after all these years, Wikipedia still mentions:

Choice Point Elimination
https://en.wikipedia.org/wiki/Comparison_of_Prolog_implementations#Optimizations

Still the complete moron Bart Demoen, drowning in
Dunning-Kruger syndrom, of incompetent people working
in the wrong domain, accused me of:

 > gives me the feeling that "choice point elimination" is
 > something jb coined, and does not belong to traditional
 > Prolog implementation terminology.

So what does Choice Point Elimination mean?

 From compiler optimization I would guess elimination
and avoidance have the similar meaning, whereas I would
prefer elimination. Elimination could mean to eliminate

an intermediate step. Like in quantifier elimination,
you eliminate something that was already there but you
could somehow get rid of it through some transformation,

you don't really avoid it. So the Physics PhDs Bart Demoen
which had no education in mathematical logic is no
way excused. He was just exposing the dark side of

wrong people in wrong places.

Bye

Mild Shock schrieb:
> Hi,
> 
> I have really interesting ghosts in by cabinet.
> Not only old software, also crazy people like
> Bart Demoen. And the good thing everything is
> 
> still available through Google Groups that
> has nicely preserved comp.lang.prolog. According
> Barty Boy the term "Choice Point Elimination"
> 
> didn't really exist:
> 
>  > Anyway, I have no idea what "choice point
>  > elimination" is supposed to refer to in literature.
>  >
>  > Literally, "choice point elimination" should mean
>  > something related to: a choicepoint was created
>  > some technique eliminates that choice point
> 
> https://groups.google.com/g/comp.lang.prolog/c/qnwD_TEG4xg/m/LMiDtFY1dQIJ
> 
> Well he is somehow right if "elimination" is
> interpreted as creating and then destroying.
> But it could also mean preventing the creation
> 
> of a choice point. You never know from the
> far of a the flemish / dutch mountains what a
> term means. Even if somebody presents a corpus
> 
> resarch as I did.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> There is one thing that currently causes me headaches.
>> So far the Dogelog Player design didn't have a big
>> ping pong from Prolog to Native and back.
>>
>> It has the Main Design with Prolog --> Native, and
>> the 2nd Design with Native --> Prolog. We also managed
>> to do some clause indexing preparation
>>
>> in the Main Design, so we have this separation of concerning
>> currently for first argument indexing:
>>
>> - Computation of Clause Key Value: Prolog
>>    The computation of the Key Value of a clause is done
>>    at compile time in pure Prolog. There are two strategies,
>>    for dynamic predicates the key is directly taken from
>>    the first argument of the head.
>>
>>    For static predicates the body of the claue is also
>>    analyzed, and this can also give a key, like for
>>    exaple if the body as a unification X = C, and X
>>    appears as first argument, the the key can be taken from C.
>>
>> - Computation of Goal/Head Key Value: Native
>>    The clauses are supplied with their Key Value, and
>>    Native code does add them with indexing. Or update the
>>    index when a clause is removed.
>>
>>    The computation of the Key Value of a goal or clause
>>    head is done a runtime in Native. And then the lookup
>>    is done natively as well.
>>
>> Now I wonder how I can bring multi-argument JIT Indexing
>> from formerly Jekejeke Prolog into the picture, and still
>> have a high degree of 100% Prolog code. Some hurdles:
>>
>> - Clause Key Value on Demand: Native -> Prolog
>>    So if I would keep the scheme that Prolog determines the
>>    clause Key Values. And if I would do this on demand,
>>    I would have a Native -> Prolog call.
>>
>> - Clauses would need decompile:
>>    Even if I implement such a Native -> Prolog hook,
>>    the problem is Clauses have not the compile time format
>>    at runtime. So the my old 100% Prolog code for Clause
>>    Key Value will not work, requires first decompilation.
>>
>> - YAP approach:
>>    I have an old paper from YAP. For the indexing they
>>    are scanning the native clause code. I didn't double
>>    check yet what SWI-Prolog (has JIT-ing) or Scryer Prolog
>>    (doesn't do it JIT style?). Etc...
>>
>> - What else?
>>
>> Well its not a big headache, but a kind of blocker,
>> before I decide what to do. There are a couple of options
>> to get out of the dilemma, and turn the Prolog systems
>>
>> around, and make it 100% Prolog again. Its like the
>> big beautiful bill by Donald Trump. Make Prolog
>> 100% Prolog again!
>>
>> LoL
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Most of the libraries and the system are design so
>>> that native is a last resort. So most functionality is
>>> Prolog and in a few instances there is a native call:
>>>
>>> - Main Design:
>>>
>>>    Prolog (a lot of it) --> Native (very little)
>>>
>>> This design, concerning the call control flow, is only
>>> broken in the top level, and in very few places, like the
>>> browser and a web server. The top-level is a native entry
>>>
>>> point and it needs to reach into Prolog, and the
>>> libraries library(react) and library(spin) provide call
>>> back facilities for the browser and a web
>>>
>>> server event handlers:
>>>
>>> - 2nd Design:
>>>
>>>    Native (top-level, react and spin) --> Prolog
>>>
>>> There is no idea at all that the Prolog system supports
>>> any iterators. I did this in the past. But the Prolog
>>> system gets simpler without the viewpoint that the
>>>
>>> interface should support iterators. SWI-Prolog always
>>> invests heavily to support iterators. Based on the
>>> rather negative experience with formerly Jekejeke Prolog
>>>
>>> we tried to completely avoid any iterator interface.
>>>
>>> Bye
> 

[toc] | [prev] | [next] | [standalone]

#14642 — How long willl I piss on Bart Demoen (Was: Physics PhDs might never have heard of Quantifier Eliminations)

Hi,

How long willl I piss on Bart Demoen?
I don't know, as long as it takes to
clean up my cabinet full of ghosts.

After that I might do some LogNonsenseTalk
bashing again, didn't do a for a long time.
But since Paulo Moura was deciple of

following Bart Demoen in mobbing, he
deserves nothing better. But LogNonsenseTalk
is not yet a ghost, not retired yet,

still a walking Zombie...

LoL

Bye

Mild Shock schrieb:
> Hi,
> 
> But after all these years, Wikipedia still mentions:
> 
> Choice Point Elimination
> https://en.wikipedia.org/wiki/Comparison_of_Prolog_implementations#Optimizations 
> 
> Still the complete moron Bart Demoen, drowning in
> Dunning-Kruger syndrom, of incompetent people working
> in the wrong domain, accused me of:
> 
>  > gives me the feeling that "choice point elimination" is
>  > something jb coined, and does not belong to traditional
>  > Prolog implementation terminology.
> 
> So what does Choice Point Elimination mean?
> 
>  From compiler optimization I would guess elimination
> and avoidance have the similar meaning, whereas I would
> prefer elimination. Elimination could mean to eliminate
> 
> an intermediate step. Like in quantifier elimination,
> you eliminate something that was already there but you
> could somehow get rid of it through some transformation,
> 
> you don't really avoid it. So the Physics PhDs Bart Demoen
> which had no education in mathematical logic is no
> way excused. He was just exposing the dark side of
> 
> wrong people in wrong places.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> I have really interesting ghosts in by cabinet.
>> Not only old software, also crazy people like
>> Bart Demoen. And the good thing everything is
>>
>> still available through Google Groups that
>> has nicely preserved comp.lang.prolog. According
>> Barty Boy the term "Choice Point Elimination"
>>
>> didn't really exist:
>>
>>  > Anyway, I have no idea what "choice point
>>  > elimination" is supposed to refer to in literature.
>>  >
>>  > Literally, "choice point elimination" should mean
>>  > something related to: a choicepoint was created
>>  > some technique eliminates that choice point
>>
>> https://groups.google.com/g/comp.lang.prolog/c/qnwD_TEG4xg/m/LMiDtFY1dQIJ
>>
>> Well he is somehow right if "elimination" is
>> interpreted as creating and then destroying.
>> But it could also mean preventing the creation
>>
>> of a choice point. You never know from the
>> far of a the flemish / dutch mountains what a
>> term means. Even if somebody presents a corpus
>>
>> resarch as I did.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> There is one thing that currently causes me headaches.
>>> So far the Dogelog Player design didn't have a big
>>> ping pong from Prolog to Native and back.
>>>
>>> It has the Main Design with Prolog --> Native, and
>>> the 2nd Design with Native --> Prolog. We also managed
>>> to do some clause indexing preparation
>>>
>>> in the Main Design, so we have this separation of concerning
>>> currently for first argument indexing:
>>>
>>> - Computation of Clause Key Value: Prolog
>>>    The computation of the Key Value of a clause is done
>>>    at compile time in pure Prolog. There are two strategies,
>>>    for dynamic predicates the key is directly taken from
>>>    the first argument of the head.
>>>
>>>    For static predicates the body of the claue is also
>>>    analyzed, and this can also give a key, like for
>>>    exaple if the body as a unification X = C, and X
>>>    appears as first argument, the the key can be taken from C.
>>>
>>> - Computation of Goal/Head Key Value: Native
>>>    The clauses are supplied with their Key Value, and
>>>    Native code does add them with indexing. Or update the
>>>    index when a clause is removed.
>>>
>>>    The computation of the Key Value of a goal or clause
>>>    head is done a runtime in Native. And then the lookup
>>>    is done natively as well.
>>>
>>> Now I wonder how I can bring multi-argument JIT Indexing
>>> from formerly Jekejeke Prolog into the picture, and still
>>> have a high degree of 100% Prolog code. Some hurdles:
>>>
>>> - Clause Key Value on Demand: Native -> Prolog
>>>    So if I would keep the scheme that Prolog determines the
>>>    clause Key Values. And if I would do this on demand,
>>>    I would have a Native -> Prolog call.
>>>
>>> - Clauses would need decompile:
>>>    Even if I implement such a Native -> Prolog hook,
>>>    the problem is Clauses have not the compile time format
>>>    at runtime. So the my old 100% Prolog code for Clause
>>>    Key Value will not work, requires first decompilation.
>>>
>>> - YAP approach:
>>>    I have an old paper from YAP. For the indexing they
>>>    are scanning the native clause code. I didn't double
>>>    check yet what SWI-Prolog (has JIT-ing) or Scryer Prolog
>>>    (doesn't do it JIT style?). Etc...
>>>
>>> - What else?
>>>
>>> Well its not a big headache, but a kind of blocker,
>>> before I decide what to do. There are a couple of options
>>> to get out of the dilemma, and turn the Prolog systems
>>>
>>> around, and make it 100% Prolog again. Its like the
>>> big beautiful bill by Donald Trump. Make Prolog
>>> 100% Prolog again!
>>>
>>> LoL
>>>
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>> Hi,
>>>>
>>>> Most of the libraries and the system are design so
>>>> that native is a last resort. So most functionality is
>>>> Prolog and in a few instances there is a native call:
>>>>
>>>> - Main Design:
>>>>
>>>>    Prolog (a lot of it) --> Native (very little)
>>>>
>>>> This design, concerning the call control flow, is only
>>>> broken in the top level, and in very few places, like the
>>>> browser and a web server. The top-level is a native entry
>>>>
>>>> point and it needs to reach into Prolog, and the
>>>> libraries library(react) and library(spin) provide call
>>>> back facilities for the browser and a web
>>>>
>>>> server event handlers:
>>>>
>>>> - 2nd Design:
>>>>
>>>>    Native (top-level, react and spin) --> Prolog
>>>>
>>>> There is no idea at all that the Prolog system supports
>>>> any iterators. I did this in the past. But the Prolog
>>>> system gets simpler without the viewpoint that the
>>>>
>>>> interface should support iterators. SWI-Prolog always
>>>> invests heavily to support iterators. Based on the
>>>> rather negative experience with formerly Jekejeke Prolog
>>>>
>>>> we tried to completely avoid any iterator interface.
>>>>
>>>> Bye
>>
> 

[toc] | [prev] | [next] | [standalone]

#14643 — But I shouldn't waste too much time (Was: How long willl I piss on Bart Demoen)

Hi,

But I shouldn't waste too much time.
One shouldn't punish people for just
being plain stupid.

Like for example this clueless french
philosopher who had a lot of troubles
with non-classical logic.

His brain tried to eliminate non-classical
logic, it was keen on avoiding non-classical
logic. A typical species of a human with

an extremly small brain, again working
in the wrong place!

Bye

P.S.: Maybe this a Poincaré thingy? Poincaré
was a strong critic of logicism (as championed
by Frege and Russell) and of Hilbert’s
formalist program.

But, he did not formally use or promote systems
like intuitionistic logic, modal logic, or
relevance logic. His logical framework remained
within the bounds of classical logic,

though he was skeptical of excessive formalism.
He thought formal systems could miss the creative
and synthetic nature of mathematical
invention.

Mild Shock schrieb:
> Hi,
> 
> How long willl I piss on Bart Demoen?
> I don't know, as long as it takes to
> clean up my cabinet full of ghosts.
> 
> After that I might do some LogNonsenseTalk
> bashing again, didn't do a for a long time.
> But since Paulo Moura was deciple of
> 
> following Bart Demoen in mobbing, he
> deserves nothing better. But LogNonsenseTalk
> is not yet a ghost, not retired yet,
> 
> still a walking Zombie...
> 
> LoL
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> But after all these years, Wikipedia still mentions:
>>
>> Choice Point Elimination
>> https://en.wikipedia.org/wiki/Comparison_of_Prolog_implementations#Optimizations 
>>
>> Still the complete moron Bart Demoen, drowning in
>> Dunning-Kruger syndrom, of incompetent people working
>> in the wrong domain, accused me of:
>>
>>  > gives me the feeling that "choice point elimination" is
>>  > something jb coined, and does not belong to traditional
>>  > Prolog implementation terminology.
>>
>> So what does Choice Point Elimination mean?
>>
>>  From compiler optimization I would guess elimination
>> and avoidance have the similar meaning, whereas I would
>> prefer elimination. Elimination could mean to eliminate
>>
>> an intermediate step. Like in quantifier elimination,
>> you eliminate something that was already there but you
>> could somehow get rid of it through some transformation,
>>
>> you don't really avoid it. So the Physics PhDs Bart Demoen
>> which had no education in mathematical logic is no
>> way excused. He was just exposing the dark side of
>>
>> wrong people in wrong places.
>>
>> Bye

[toc] | [prev] | [next] | [standalone]

#14651 — DCG is easily affected (Was: The Ghosts in my Cabinet: Indexing)

Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
     A=B.
app([A|B], [A|C], D) :-
     app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:
> I am currently doing a re-evaluation of an old
> Prolog system, checking what features I could adopt.
> This is unlike the current trend where people have
> turned their focus on GUIs, like XPCE,
> 
> or a are stuck in an endless loop of parser
> problems, like in Trealla. But I would nevertheless
> share my finding. Take this simple example of
> a list append:
> 
> app([], X, X).
> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
> 
> ECLiPSe Prolog gives me, only one redo question
> in the top-level:
> 
> /* ECLiPSe Prolog 7.1beta #13 */
> [eclipse 2]: app(X,Y,[1]).
> 
> X = []
> Y = [1]
> Yes (0.00s cpu, solution 1, maybe more) ? ;
> 
> X = [1]
> Y = []
> Yes (0.00s cpu, solution 2)
> 
> In SWI-Prolog I find, two redo questions
> in the top.level:
> 
> /* SWI-Prolog 9.3.25 */
> ?- app(X,Y,[1]).
> X = [],
> Y = [1] ;
> X = [1],
> Y = [] ;
> false.
> 
> I know SWI-Prolog handles lists differently
> than other Prolog terms during indexing. Could
> this be the reason? Or maybe that the call is
> not “hot” enough, so it doesn’t get JIT-ed.
> 
> ECLiPSe Prolog does it on the very first call,
> and I assume its due to a kind of index on
> the 3rd argument.
> 

[toc] | [prev] | [next] | [standalone]

#14668 — The headache an eGovernment might get from Prolog (Was: DCG is easily affected)

Hi,

That false/0 and not fail/0 is now all over the place,
I don't mean in person but for example here:

?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
false.

Is a little didactical nightmare.

Syntactic unification has mathematical axioms (1978),
to fully formalize unifcation you would need to
formalize both (=)/2 and (≠)/2 (sic!), otherwise you
rely on some negation as failure concept.

Keith L. Clark, Negation as Failure
https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11

You can realize a subset of a mixture of (=)/2
and (≠)/2 in the form of a vanilla unify Prolog
predicate using some of the meta programming
facilities of Prolog, like var/1 and having some

negation as failure reading:

/* Vanilla Unify */
unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
unify(V, T) :- var(V), !, V = T.
unify(S, W) :- var(W), !, W = S.
unify(S, T) :- functor(S, F, N), functor(T, F, N),
      S =.. [F|L], T =.. [F|R], maplist(unify, L, R).

I indeed get:

?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
false.

If the vanilla unify/2 already fails then unify
with and without subject to occurs check, will also
fail, and unify with and without ability to
handle rational terms, will also fail:

Bye

Mild Shock schrieb:
> 
> Interestingly, DCG is also affect. Here a
> DCG take of an append app/3, it has the 2nd
> and 3rd argument swapped:
> 
> ?- [user].
> app([]) --> [].
> app([X|Y]) --> [X], app(Y).
> ^D
> 
> Looks like an append, taking the argument swap
> into account, the A=B is redundant, could
> be optimized away:
> 
> /* SWI-Prolog 9.3.25 */
> ?- listing(app/3).
> app([], A, B) :-
>      A=B.
> app([A|B], [A|C], D) :-
>      app(B, C, D).
> 
> And works like an append, again taking the
> argument swap into account:
> 
> ?- app([1],X,[2,3]).
> X = [1, 2, 3].
> 
> Now the multi-argument indexing test, still
> taking the argument swap into account;
> 
> /* ECLiPSe Prolog 7.1beta #13 */
> [eclipse 3]: app(X, [1], Y).
> 
> X = []
> Y = [1]
> Yes (0.00s cpu, solution 1, maybe more) ? ;
> 
> X = [1]
> Y = []
> Yes (0.00s cpu, solution 2)
> 
> Versus:
> 
> /* SWI-Prolog 9.3.25 */
> ?- app(X, [1], Y).
> X = [],
> Y = [1] ;
> X = [1],
> Y = [] ;
> false.
> 
> Mild Shock schrieb:
>> I am currently doing a re-evaluation of an old
>> Prolog system, checking what features I could adopt.
>> This is unlike the current trend where people have
>> turned their focus on GUIs, like XPCE,
>>
>> or a are stuck in an endless loop of parser
>> problems, like in Trealla. But I would nevertheless
>> share my finding. Take this simple example of
>> a list append:
>>
>> app([], X, X).
>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>
>> ECLiPSe Prolog gives me, only one redo question
>> in the top-level:
>>
>> /* ECLiPSe Prolog 7.1beta #13 */
>> [eclipse 2]: app(X,Y,[1]).
>>
>> X = []
>> Y = [1]
>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>
>> X = [1]
>> Y = []
>> Yes (0.00s cpu, solution 2)
>>
>> In SWI-Prolog I find, two redo questions
>> in the top.level:
>>
>> /* SWI-Prolog 9.3.25 */
>> ?- app(X,Y,[1]).
>> X = [],
>> Y = [1] ;
>> X = [1],
>> Y = [] ;
>> false.
>>
>> I know SWI-Prolog handles lists differently
>> than other Prolog terms during indexing. Could
>> this be the reason? Or maybe that the call is
>> not “hot” enough, so it doesn’t get JIT-ed.
>>
>> ECLiPSe Prolog does it on the very first call,
>> and I assume its due to a kind of index on
>> the 3rd argument.
>>
> 

[toc] | [prev] | [next] | [standalone]

#14669 — Wait till they find out about compare/3 (Was: The headache an eGovernment might get from Prolog)

Hi,

Now somebody was so friendly to spear head
a new Don Quixote attempt in fighting the
windmills of compare/3. Interestingly my

favorite counter example still goes through:

?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, X, Y).
X = X-0-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (<).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, Z, Y).
H = H-9-7-6-5-4-3-2-1-0,
Z = H-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (>).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X = 
X-0-9-7-6-5-4-3-2-1,
    compare_with_stack(C, Z, X).
H = H-9-7-6-5-4-3-2-1-0,
Z = X, X = X-0-9-7-6-5-4-3-2-1,
C = (=).

I posted it here in March 2023:

Careful with compare/3 and Brent algorithm
https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413

Its based that rational terms are indeed in
some relation to rational numbers. The above
terms are related to:

10/81 = 0.(123456790) = 0.12345679(02345679)

Bye

Mild Shock schrieb:
> Hi,
> 
> That false/0 and not fail/0 is now all over the place,
> I don't mean in person but for example here:
> 
> ?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
> false.
> 
> Is a little didactical nightmare.
> 
> Syntactic unification has mathematical axioms (1978),
> to fully formalize unifcation you would need to
> formalize both (=)/2 and (≠)/2 (sic!), otherwise you
> rely on some negation as failure concept.
> 
> Keith L. Clark, Negation as Failure
> https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11
> 
> You can realize a subset of a mixture of (=)/2
> and (≠)/2 in the form of a vanilla unify Prolog
> predicate using some of the meta programming
> facilities of Prolog, like var/1 and having some
> 
> negation as failure reading:
> 
> /* Vanilla Unify */
> unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
> unify(V, T) :- var(V), !, V = T.
> unify(S, W) :- var(W), !, W = S.
> unify(S, T) :- functor(S, F, N), functor(T, F, N),
>       S =.. [F|L], T =.. [F|R], maplist(unify, L, R).
> 
> I indeed get:
> 
> ?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
> false.
> 
> If the vanilla unify/2 already fails then unify
> with and without subject to occurs check, will also
> fail, and unify with and without ability to
> handle rational terms, will also fail:
> 
> Bye
> 
> Mild Shock schrieb:
>>
>> Interestingly, DCG is also affect. Here a
>> DCG take of an append app/3, it has the 2nd
>> and 3rd argument swapped:
>>
>> ?- [user].
>> app([]) --> [].
>> app([X|Y]) --> [X], app(Y).
>> ^D
>>
>> Looks like an append, taking the argument swap
>> into account, the A=B is redundant, could
>> be optimized away:
>>
>> /* SWI-Prolog 9.3.25 */
>> ?- listing(app/3).
>> app([], A, B) :-
>>      A=B.
>> app([A|B], [A|C], D) :-
>>      app(B, C, D).
>>
>> And works like an append, again taking the
>> argument swap into account:
>>
>> ?- app([1],X,[2,3]).
>> X = [1, 2, 3].
>>
>> Now the multi-argument indexing test, still
>> taking the argument swap into account;
>>
>> /* ECLiPSe Prolog 7.1beta #13 */
>> [eclipse 3]: app(X, [1], Y).
>>
>> X = []
>> Y = [1]
>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>
>> X = [1]
>> Y = []
>> Yes (0.00s cpu, solution 2)
>>
>> Versus:
>>
>> /* SWI-Prolog 9.3.25 */
>> ?- app(X, [1], Y).
>> X = [],
>> Y = [1] ;
>> X = [1],
>> Y = [] ;
>> false.
>>
>> Mild Shock schrieb:
>>> I am currently doing a re-evaluation of an old
>>> Prolog system, checking what features I could adopt.
>>> This is unlike the current trend where people have
>>> turned their focus on GUIs, like XPCE,
>>>
>>> or a are stuck in an endless loop of parser
>>> problems, like in Trealla. But I would nevertheless
>>> share my finding. Take this simple example of
>>> a list append:
>>>
>>> app([], X, X).
>>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>>
>>> ECLiPSe Prolog gives me, only one redo question
>>> in the top-level:
>>>
>>> /* ECLiPSe Prolog 7.1beta #13 */
>>> [eclipse 2]: app(X,Y,[1]).
>>>
>>> X = []
>>> Y = [1]
>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>
>>> X = [1]
>>> Y = []
>>> Yes (0.00s cpu, solution 2)
>>>
>>> In SWI-Prolog I find, two redo questions
>>> in the top.level:
>>>
>>> /* SWI-Prolog 9.3.25 */
>>> ?- app(X,Y,[1]).
>>> X = [],
>>> Y = [1] ;
>>> X = [1],
>>> Y = [] ;
>>> false.
>>>
>>> I know SWI-Prolog handles lists differently
>>> than other Prolog terms during indexing. Could
>>> this be the reason? Or maybe that the call is
>>> not “hot” enough, so it doesn’t get JIT-ed.
>>>
>>> ECLiPSe Prolog does it on the very first call,
>>> and I assume its due to a kind of index on
>>> the 3rd argument.
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14670 — Corr. (Was: Wait till they find out about compare/3)

Corr.: Small typo in the number
expansion itself, should read:

10/81 = 0.(123456790) = 0.12345679(012345679)

Mild Shock schrieb:
> Hi,
> 
> Now somebody was so friendly to spear head
> a new Don Quixote attempt in fighting the
> windmills of compare/3. Interestingly my
> 
> favorite counter example still goes through:
> 
> ?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>     compare_with_stack(C, X, Y).
> X = X-0-9-7-6-5-4-3-2-1,
> Y = Y-7-5-8-2-4-1,
> C = (<).
> 
> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>     compare_with_stack(C, Z, Y).
> H = H-9-7-6-5-4-3-2-1-0,
> Z = H-9-7-6-5-4-3-2-1,
> Y = Y-7-5-8-2-4-1,
> C = (>).
> 
> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X = X-0-9-7-6-5-4-3-2-1,
>     compare_with_stack(C, Z, X).
> H = H-9-7-6-5-4-3-2-1-0,
> Z = X, X = X-0-9-7-6-5-4-3-2-1,
> C = (=).
> 
> I posted it here in March 2023:
> 
> Careful with compare/3 and Brent algorithm
> https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413 
> 
> 
> Its based that rational terms are indeed in
> some relation to rational numbers. The above
> terms are related to:
> 
> 10/81 = 0.(123456790) = 0.12345679(02345679)
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> That false/0 and not fail/0 is now all over the place,
>> I don't mean in person but for example here:
>>
>> ?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
>> false.
>>
>> Is a little didactical nightmare.
>>
>> Syntactic unification has mathematical axioms (1978),
>> to fully formalize unifcation you would need to
>> formalize both (=)/2 and (≠)/2 (sic!), otherwise you
>> rely on some negation as failure concept.
>>
>> Keith L. Clark, Negation as Failure
>> https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11
>>
>> You can realize a subset of a mixture of (=)/2
>> and (≠)/2 in the form of a vanilla unify Prolog
>> predicate using some of the meta programming
>> facilities of Prolog, like var/1 and having some
>>
>> negation as failure reading:
>>
>> /* Vanilla Unify */
>> unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
>> unify(V, T) :- var(V), !, V = T.
>> unify(S, W) :- var(W), !, W = S.
>> unify(S, T) :- functor(S, F, N), functor(T, F, N),
>>       S =.. [F|L], T =.. [F|R], maplist(unify, L, R).
>>
>> I indeed get:
>>
>> ?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
>> false.
>>
>> If the vanilla unify/2 already fails then unify
>> with and without subject to occurs check, will also
>> fail, and unify with and without ability to
>> handle rational terms, will also fail:
>>
>> Bye
>>
>> Mild Shock schrieb:
>>>
>>> Interestingly, DCG is also affect. Here a
>>> DCG take of an append app/3, it has the 2nd
>>> and 3rd argument swapped:
>>>
>>> ?- [user].
>>> app([]) --> [].
>>> app([X|Y]) --> [X], app(Y).
>>> ^D
>>>
>>> Looks like an append, taking the argument swap
>>> into account, the A=B is redundant, could
>>> be optimized away:
>>>
>>> /* SWI-Prolog 9.3.25 */
>>> ?- listing(app/3).
>>> app([], A, B) :-
>>>      A=B.
>>> app([A|B], [A|C], D) :-
>>>      app(B, C, D).
>>>
>>> And works like an append, again taking the
>>> argument swap into account:
>>>
>>> ?- app([1],X,[2,3]).
>>> X = [1, 2, 3].
>>>
>>> Now the multi-argument indexing test, still
>>> taking the argument swap into account;
>>>
>>> /* ECLiPSe Prolog 7.1beta #13 */
>>> [eclipse 3]: app(X, [1], Y).
>>>
>>> X = []
>>> Y = [1]
>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>
>>> X = [1]
>>> Y = []
>>> Yes (0.00s cpu, solution 2)
>>>
>>> Versus:
>>>
>>> /* SWI-Prolog 9.3.25 */
>>> ?- app(X, [1], Y).
>>> X = [],
>>> Y = [1] ;
>>> X = [1],
>>> Y = [] ;
>>> false.
>>>
>>> Mild Shock schrieb:
>>>> I am currently doing a re-evaluation of an old
>>>> Prolog system, checking what features I could adopt.
>>>> This is unlike the current trend where people have
>>>> turned their focus on GUIs, like XPCE,
>>>>
>>>> or a are stuck in an endless loop of parser
>>>> problems, like in Trealla. But I would nevertheless
>>>> share my finding. Take this simple example of
>>>> a list append:
>>>>
>>>> app([], X, X).
>>>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>>>
>>>> ECLiPSe Prolog gives me, only one redo question
>>>> in the top-level:
>>>>
>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>> [eclipse 2]: app(X,Y,[1]).
>>>>
>>>> X = []
>>>> Y = [1]
>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>
>>>> X = [1]
>>>> Y = []
>>>> Yes (0.00s cpu, solution 2)
>>>>
>>>> In SWI-Prolog I find, two redo questions
>>>> in the top.level:
>>>>
>>>> /* SWI-Prolog 9.3.25 */
>>>> ?- app(X,Y,[1]).
>>>> X = [],
>>>> Y = [1] ;
>>>> X = [1],
>>>> Y = [] ;
>>>> false.
>>>>
>>>> I know SWI-Prolog handles lists differently
>>>> than other Prolog terms during indexing. Could
>>>> this be the reason? Or maybe that the call is
>>>> not “hot” enough, so it doesn’t get JIT-ed.
>>>>
>>>> ECLiPSe Prolog does it on the very first call,
>>>> and I assume its due to a kind of index on
>>>> the 3rd argument.
>>>>
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14671 — eGovernements will need AGI to survive (Was: Corr. (Was: Wait till they find out about compare/3))

Hi,

Maybe AGI should take over proving.
Just take the humans out of the loop
of any programming, it leads to nowhere.

Bye

 > Julio Di Egidio schrieb:
 > > But we must thank MS for the nail in that coffin, too: they can't
 > > be satisfied with just a Lean broken by design, they must own the
 > > whole compartment: only poisoned meatballs for the public...
 >
 > -Julio

Mild Shock schrieb:
> Corr.: Small typo in the number
> expansion itself, should read:
> 
> 10/81 = 0.(123456790) = 0.12345679(012345679)
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Now somebody was so friendly to spear head
>> a new Don Quixote attempt in fighting the
>> windmills of compare/3. Interestingly my
>>
>> favorite counter example still goes through:
>>
>> ?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>>     compare_with_stack(C, X, Y).
>> X = X-0-9-7-6-5-4-3-2-1,
>> Y = Y-7-5-8-2-4-1,
>> C = (<).
>>
>> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>>     compare_with_stack(C, Z, Y).
>> H = H-9-7-6-5-4-3-2-1-0,
>> Z = H-9-7-6-5-4-3-2-1,
>> Y = Y-7-5-8-2-4-1,
>> C = (>).
>>
>> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X = 
>> X-0-9-7-6-5-4-3-2-1,
>>     compare_with_stack(C, Z, X).
>> H = H-9-7-6-5-4-3-2-1-0,
>> Z = X, X = X-0-9-7-6-5-4-3-2-1,
>> C = (=).
>>
>> I posted it here in March 2023:
>>
>> Careful with compare/3 and Brent algorithm
>> https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413 
>>
>>
>> Its based that rational terms are indeed in
>> some relation to rational numbers. The above
>> terms are related to:
>>
>> 10/81 = 0.(123456790) = 0.12345679(02345679)
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> That false/0 and not fail/0 is now all over the place,
>>> I don't mean in person but for example here:
>>>
>>> ?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
>>> false.
>>>
>>> Is a little didactical nightmare.
>>>
>>> Syntactic unification has mathematical axioms (1978),
>>> to fully formalize unifcation you would need to
>>> formalize both (=)/2 and (≠)/2 (sic!), otherwise you
>>> rely on some negation as failure concept.
>>>
>>> Keith L. Clark, Negation as Failure
>>> https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11
>>>
>>> You can realize a subset of a mixture of (=)/2
>>> and (≠)/2 in the form of a vanilla unify Prolog
>>> predicate using some of the meta programming
>>> facilities of Prolog, like var/1 and having some
>>>
>>> negation as failure reading:
>>>
>>> /* Vanilla Unify */
>>> unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
>>> unify(V, T) :- var(V), !, V = T.
>>> unify(S, W) :- var(W), !, W = S.
>>> unify(S, T) :- functor(S, F, N), functor(T, F, N),
>>>       S =.. [F|L], T =.. [F|R], maplist(unify, L, R).
>>>
>>> I indeed get:
>>>
>>> ?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
>>> false.
>>>
>>> If the vanilla unify/2 already fails then unify
>>> with and without subject to occurs check, will also
>>> fail, and unify with and without ability to
>>> handle rational terms, will also fail:
>>>
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>>
>>>> Interestingly, DCG is also affect. Here a
>>>> DCG take of an append app/3, it has the 2nd
>>>> and 3rd argument swapped:
>>>>
>>>> ?- [user].
>>>> app([]) --> [].
>>>> app([X|Y]) --> [X], app(Y).
>>>> ^D
>>>>
>>>> Looks like an append, taking the argument swap
>>>> into account, the A=B is redundant, could
>>>> be optimized away:
>>>>
>>>> /* SWI-Prolog 9.3.25 */
>>>> ?- listing(app/3).
>>>> app([], A, B) :-
>>>>      A=B.
>>>> app([A|B], [A|C], D) :-
>>>>      app(B, C, D).
>>>>
>>>> And works like an append, again taking the
>>>> argument swap into account:
>>>>
>>>> ?- app([1],X,[2,3]).
>>>> X = [1, 2, 3].
>>>>
>>>> Now the multi-argument indexing test, still
>>>> taking the argument swap into account;
>>>>
>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>> [eclipse 3]: app(X, [1], Y).
>>>>
>>>> X = []
>>>> Y = [1]
>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>
>>>> X = [1]
>>>> Y = []
>>>> Yes (0.00s cpu, solution 2)
>>>>
>>>> Versus:
>>>>
>>>> /* SWI-Prolog 9.3.25 */
>>>> ?- app(X, [1], Y).
>>>> X = [],
>>>> Y = [1] ;
>>>> X = [1],
>>>> Y = [] ;
>>>> false.
>>>>
>>>> Mild Shock schrieb:
>>>>> I am currently doing a re-evaluation of an old
>>>>> Prolog system, checking what features I could adopt.
>>>>> This is unlike the current trend where people have
>>>>> turned their focus on GUIs, like XPCE,
>>>>>
>>>>> or a are stuck in an endless loop of parser
>>>>> problems, like in Trealla. But I would nevertheless
>>>>> share my finding. Take this simple example of
>>>>> a list append:
>>>>>
>>>>> app([], X, X).
>>>>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>>>>
>>>>> ECLiPSe Prolog gives me, only one redo question
>>>>> in the top-level:
>>>>>
>>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>>> [eclipse 2]: app(X,Y,[1]).
>>>>>
>>>>> X = []
>>>>> Y = [1]
>>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>>
>>>>> X = [1]
>>>>> Y = []
>>>>> Yes (0.00s cpu, solution 2)
>>>>>
>>>>> In SWI-Prolog I find, two redo questions
>>>>> in the top.level:
>>>>>
>>>>> /* SWI-Prolog 9.3.25 */
>>>>> ?- app(X,Y,[1]).
>>>>> X = [],
>>>>> Y = [1] ;
>>>>> X = [1],
>>>>> Y = [] ;
>>>>> false.
>>>>>
>>>>> I know SWI-Prolog handles lists differently
>>>>> than other Prolog terms during indexing. Could
>>>>> this be the reason? Or maybe that the call is
>>>>> not “hot” enough, so it doesn’t get JIT-ed.
>>>>>
>>>>> ECLiPSe Prolog does it on the very first call,
>>>>> and I assume its due to a kind of index on
>>>>> the 3rd argument.
>>>>>
>>>>
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14672 — Having 2544 issues is probably a bad sign (Re: eGovernements will need AGI to survive)

Hi,

Having 2544 issues is probably a bad sign.
I find this many issues here:

https://github.com/rocq-prover/rocq/issues

Mostlikely 90% of the issues can be move to
the new discussion feature of GitHub.

LoL

Bye

P.S.: Same holds for Scryer Prolog with 406 issues.

Mild Shock schrieb:
> Hi,
> 
> Maybe AGI should take over proving.
> Just take the humans out of the loop
> of any programming, it leads to nowhere.
> 
> Bye
> 
>  > Julio Di Egidio schrieb:
>  > > But we must thank MS for the nail in that coffin, too: they can't
>  > > be satisfied with just a Lean broken by design, they must own the
>  > > whole compartment: only poisoned meatballs for the public...
>  >
>  > -Julio
> 
> Mild Shock schrieb:
>> Corr.: Small typo in the number
>> expansion itself, should read:
>>
>> 10/81 = 0.(123456790) = 0.12345679(012345679)
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Now somebody was so friendly to spear head
>>> a new Don Quixote attempt in fighting the
>>> windmills of compare/3. Interestingly my
>>>
>>> favorite counter example still goes through:
>>>
>>> ?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>>>     compare_with_stack(C, X, Y).
>>> X = X-0-9-7-6-5-4-3-2-1,
>>> Y = Y-7-5-8-2-4-1,
>>> C = (<).
>>>
>>> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>>>     compare_with_stack(C, Z, Y).
>>> H = H-9-7-6-5-4-3-2-1-0,
>>> Z = H-9-7-6-5-4-3-2-1,
>>> Y = Y-7-5-8-2-4-1,
>>> C = (>).
>>>
>>> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X = 
>>> X-0-9-7-6-5-4-3-2-1,
>>>     compare_with_stack(C, Z, X).
>>> H = H-9-7-6-5-4-3-2-1-0,
>>> Z = X, X = X-0-9-7-6-5-4-3-2-1,
>>> C = (=).
>>>
>>> I posted it here in March 2023:
>>>
>>> Careful with compare/3 and Brent algorithm
>>> https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413 
>>>
>>>
>>> Its based that rational terms are indeed in
>>> some relation to rational numbers. The above
>>> terms are related to:
>>>
>>> 10/81 = 0.(123456790) = 0.12345679(02345679)
>>>
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>> Hi,
>>>>
>>>> That false/0 and not fail/0 is now all over the place,
>>>> I don't mean in person but for example here:
>>>>
>>>> ?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
>>>> false.
>>>>
>>>> Is a little didactical nightmare.
>>>>
>>>> Syntactic unification has mathematical axioms (1978),
>>>> to fully formalize unifcation you would need to
>>>> formalize both (=)/2 and (≠)/2 (sic!), otherwise you
>>>> rely on some negation as failure concept.
>>>>
>>>> Keith L. Clark, Negation as Failure
>>>> https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11
>>>>
>>>> You can realize a subset of a mixture of (=)/2
>>>> and (≠)/2 in the form of a vanilla unify Prolog
>>>> predicate using some of the meta programming
>>>> facilities of Prolog, like var/1 and having some
>>>>
>>>> negation as failure reading:
>>>>
>>>> /* Vanilla Unify */
>>>> unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
>>>> unify(V, T) :- var(V), !, V = T.
>>>> unify(S, W) :- var(W), !, W = S.
>>>> unify(S, T) :- functor(S, F, N), functor(T, F, N),
>>>>       S =.. [F|L], T =.. [F|R], maplist(unify, L, R).
>>>>
>>>> I indeed get:
>>>>
>>>> ?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
>>>> false.
>>>>
>>>> If the vanilla unify/2 already fails then unify
>>>> with and without subject to occurs check, will also
>>>> fail, and unify with and without ability to
>>>> handle rational terms, will also fail:
>>>>
>>>> Bye
>>>>
>>>> Mild Shock schrieb:
>>>>>
>>>>> Interestingly, DCG is also affect. Here a
>>>>> DCG take of an append app/3, it has the 2nd
>>>>> and 3rd argument swapped:
>>>>>
>>>>> ?- [user].
>>>>> app([]) --> [].
>>>>> app([X|Y]) --> [X], app(Y).
>>>>> ^D
>>>>>
>>>>> Looks like an append, taking the argument swap
>>>>> into account, the A=B is redundant, could
>>>>> be optimized away:
>>>>>
>>>>> /* SWI-Prolog 9.3.25 */
>>>>> ?- listing(app/3).
>>>>> app([], A, B) :-
>>>>>      A=B.
>>>>> app([A|B], [A|C], D) :-
>>>>>      app(B, C, D).
>>>>>
>>>>> And works like an append, again taking the
>>>>> argument swap into account:
>>>>>
>>>>> ?- app([1],X,[2,3]).
>>>>> X = [1, 2, 3].
>>>>>
>>>>> Now the multi-argument indexing test, still
>>>>> taking the argument swap into account;
>>>>>
>>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>>> [eclipse 3]: app(X, [1], Y).
>>>>>
>>>>> X = []
>>>>> Y = [1]
>>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>>
>>>>> X = [1]
>>>>> Y = []
>>>>> Yes (0.00s cpu, solution 2)
>>>>>
>>>>> Versus:
>>>>>
>>>>> /* SWI-Prolog 9.3.25 */
>>>>> ?- app(X, [1], Y).
>>>>> X = [],
>>>>> Y = [1] ;
>>>>> X = [1],
>>>>> Y = [] ;
>>>>> false.
>>>>>
>>>>> Mild Shock schrieb:
>>>>>> I am currently doing a re-evaluation of an old
>>>>>> Prolog system, checking what features I could adopt.
>>>>>> This is unlike the current trend where people have
>>>>>> turned their focus on GUIs, like XPCE,
>>>>>>
>>>>>> or a are stuck in an endless loop of parser
>>>>>> problems, like in Trealla. But I would nevertheless
>>>>>> share my finding. Take this simple example of
>>>>>> a list append:
>>>>>>
>>>>>> app([], X, X).
>>>>>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>>>>>
>>>>>> ECLiPSe Prolog gives me, only one redo question
>>>>>> in the top-level:
>>>>>>
>>>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>>>> [eclipse 2]: app(X,Y,[1]).
>>>>>>
>>>>>> X = []
>>>>>> Y = [1]
>>>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>>>
>>>>>> X = [1]
>>>>>> Y = []
>>>>>> Yes (0.00s cpu, solution 2)
>>>>>>
>>>>>> In SWI-Prolog I find, two redo questions
>>>>>> in the top.level:
>>>>>>
>>>>>> /* SWI-Prolog 9.3.25 */
>>>>>> ?- app(X,Y,[1]).
>>>>>> X = [],
>>>>>> Y = [1] ;
>>>>>> X = [1],
>>>>>> Y = [] ;
>>>>>> false.
>>>>>>
>>>>>> I know SWI-Prolog handles lists differently
>>>>>> than other Prolog terms during indexing. Could
>>>>>> this be the reason? Or maybe that the call is
>>>>>> not “hot” enough, so it doesn’t get JIT-ed.
>>>>>>
>>>>>> ECLiPSe Prolog does it on the very first call,
>>>>>> and I assume its due to a kind of index on
>>>>>> the 3rd argument.
>>>>>>
>>>>>
>>>>
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14673 — The Signal Collapse gives us System Uncertainty (Re: Having 2544 issues is probably a bad sign)

Hi,

1. Everybody’s a programmer now
    The barrier to entry dropped dramatically — you can
    become a "developer" with a few online tutorials
    and a GitHub account.

2. Everybody’s an academic now
    Academia expanded, but standards often fell. In
    some places, it's publish or perish, so paper
    mills and fake research flourish.

3. Signal Collapse ↔ Systemic Uncertainty
    Credentials lose meaning, No reliable markers of
    skill, Fragile systems built on shallow knowledge

4. Signal Collapse ↔ Systemic Uncertainty
    Quantity overwhelms quality, Important truths get
    buried, Bad signals drown good ones

Etc..

Bye

Mild Shock schrieb:
> Hi,
> 
> Having 2544 issues is probably a bad sign.
> I find this many issues here:
> 
> https://github.com/rocq-prover/rocq/issues
> 
> Mostlikely 90% of the issues can be move to
> the new discussion feature of GitHub.
> 
> LoL
> 
> Bye
> 
> P.S.: Same holds for Scryer Prolog with 406 issues.
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Maybe AGI should take over proving.
>> Just take the humans out of the loop
>> of any programming, it leads to nowhere.
>>
>> Bye
>>
>>  > Julio Di Egidio schrieb:
>>  > > But we must thank MS for the nail in that coffin, too: they can't
>>  > > be satisfied with just a Lean broken by design, they must own the
>>  > > whole compartment: only poisoned meatballs for the public...
>>  >
>>  > -Julio
>>
>> Mild Shock schrieb:
>>> Corr.: Small typo in the number
>>> expansion itself, should read:
>>>
>>> 10/81 = 0.(123456790) = 0.12345679(012345679)
>>>
>>> Mild Shock schrieb:
>>>> Hi,
>>>>
>>>> Now somebody was so friendly to spear head
>>>> a new Don Quixote attempt in fighting the
>>>> windmills of compare/3. Interestingly my
>>>>
>>>> favorite counter example still goes through:
>>>>
>>>> ?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>>>>     compare_with_stack(C, X, Y).
>>>> X = X-0-9-7-6-5-4-3-2-1,
>>>> Y = Y-7-5-8-2-4-1,
>>>> C = (<).
>>>>
>>>> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>>>>     compare_with_stack(C, Z, Y).
>>>> H = H-9-7-6-5-4-3-2-1-0,
>>>> Z = H-9-7-6-5-4-3-2-1,
>>>> Y = Y-7-5-8-2-4-1,
>>>> C = (>).
>>>>
>>>> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X = 
>>>> X-0-9-7-6-5-4-3-2-1,
>>>>     compare_with_stack(C, Z, X).
>>>> H = H-9-7-6-5-4-3-2-1-0,
>>>> Z = X, X = X-0-9-7-6-5-4-3-2-1,
>>>> C = (=).
>>>>
>>>> I posted it here in March 2023:
>>>>
>>>> Careful with compare/3 and Brent algorithm
>>>> https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413 
>>>>
>>>>
>>>> Its based that rational terms are indeed in
>>>> some relation to rational numbers. The above
>>>> terms are related to:
>>>>
>>>> 10/81 = 0.(123456790) = 0.12345679(02345679)
>>>>
>>>> Bye
>>>>
>>>> Mild Shock schrieb:
>>>>> Hi,
>>>>>
>>>>> That false/0 and not fail/0 is now all over the place,
>>>>> I don't mean in person but for example here:
>>>>>
>>>>> ?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
>>>>> false.
>>>>>
>>>>> Is a little didactical nightmare.
>>>>>
>>>>> Syntactic unification has mathematical axioms (1978),
>>>>> to fully formalize unifcation you would need to
>>>>> formalize both (=)/2 and (≠)/2 (sic!), otherwise you
>>>>> rely on some negation as failure concept.
>>>>>
>>>>> Keith L. Clark, Negation as Failure
>>>>> https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11
>>>>>
>>>>> You can realize a subset of a mixture of (=)/2
>>>>> and (≠)/2 in the form of a vanilla unify Prolog
>>>>> predicate using some of the meta programming
>>>>> facilities of Prolog, like var/1 and having some
>>>>>
>>>>> negation as failure reading:
>>>>>
>>>>> /* Vanilla Unify */
>>>>> unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
>>>>> unify(V, T) :- var(V), !, V = T.
>>>>> unify(S, W) :- var(W), !, W = S.
>>>>> unify(S, T) :- functor(S, F, N), functor(T, F, N),
>>>>>       S =.. [F|L], T =.. [F|R], maplist(unify, L, R).
>>>>>
>>>>> I indeed get:
>>>>>
>>>>> ?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
>>>>> false.
>>>>>
>>>>> If the vanilla unify/2 already fails then unify
>>>>> with and without subject to occurs check, will also
>>>>> fail, and unify with and without ability to
>>>>> handle rational terms, will also fail:
>>>>>
>>>>> Bye
>>>>>
>>>>> Mild Shock schrieb:
>>>>>>
>>>>>> Interestingly, DCG is also affect. Here a
>>>>>> DCG take of an append app/3, it has the 2nd
>>>>>> and 3rd argument swapped:
>>>>>>
>>>>>> ?- [user].
>>>>>> app([]) --> [].
>>>>>> app([X|Y]) --> [X], app(Y).
>>>>>> ^D
>>>>>>
>>>>>> Looks like an append, taking the argument swap
>>>>>> into account, the A=B is redundant, could
>>>>>> be optimized away:
>>>>>>
>>>>>> /* SWI-Prolog 9.3.25 */
>>>>>> ?- listing(app/3).
>>>>>> app([], A, B) :-
>>>>>>      A=B.
>>>>>> app([A|B], [A|C], D) :-
>>>>>>      app(B, C, D).
>>>>>>
>>>>>> And works like an append, again taking the
>>>>>> argument swap into account:
>>>>>>
>>>>>> ?- app([1],X,[2,3]).
>>>>>> X = [1, 2, 3].
>>>>>>
>>>>>> Now the multi-argument indexing test, still
>>>>>> taking the argument swap into account;
>>>>>>
>>>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>>>> [eclipse 3]: app(X, [1], Y).
>>>>>>
>>>>>> X = []
>>>>>> Y = [1]
>>>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>>>
>>>>>> X = [1]
>>>>>> Y = []
>>>>>> Yes (0.00s cpu, solution 2)
>>>>>>
>>>>>> Versus:
>>>>>>
>>>>>> /* SWI-Prolog 9.3.25 */
>>>>>> ?- app(X, [1], Y).
>>>>>> X = [],
>>>>>> Y = [1] ;
>>>>>> X = [1],
>>>>>> Y = [] ;
>>>>>> false.
>>>>>>
>>>>>> Mild Shock schrieb:
>>>>>>> I am currently doing a re-evaluation of an old
>>>>>>> Prolog system, checking what features I could adopt.
>>>>>>> This is unlike the current trend where people have
>>>>>>> turned their focus on GUIs, like XPCE,
>>>>>>>
>>>>>>> or a are stuck in an endless loop of parser
>>>>>>> problems, like in Trealla. But I would nevertheless
>>>>>>> share my finding. Take this simple example of
>>>>>>> a list append:
>>>>>>>
>>>>>>> app([], X, X).
>>>>>>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>>>>>>
>>>>>>> ECLiPSe Prolog gives me, only one redo question
>>>>>>> in the top-level:
>>>>>>>
>>>>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>>>>> [eclipse 2]: app(X,Y,[1]).
>>>>>>>
>>>>>>> X = []
>>>>>>> Y = [1]
>>>>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>>>>
>>>>>>> X = [1]
>>>>>>> Y = []
>>>>>>> Yes (0.00s cpu, solution 2)
>>>>>>>
>>>>>>> In SWI-Prolog I find, two redo questions
>>>>>>> in the top.level:
>>>>>>>
>>>>>>> /* SWI-Prolog 9.3.25 */
>>>>>>> ?- app(X,Y,[1]).
>>>>>>> X = [],
>>>>>>> Y = [1] ;
>>>>>>> X = [1],
>>>>>>> Y = [] ;
>>>>>>> false.
>>>>>>>
>>>>>>> I know SWI-Prolog handles lists differently
>>>>>>> than other Prolog terms during indexing. Could
>>>>>>> this be the reason? Or maybe that the call is
>>>>>>> not “hot” enough, so it doesn’t get JIT-ed.
>>>>>>>
>>>>>>> ECLiPSe Prolog does it on the very first call,
>>>>>>> and I assume its due to a kind of index on
>>>>>>> the 3rd argument.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14674 — Rename GitHub, to TurdPit, and make Amber Heard their CEO (Was: The Signal Collapse gives us System Uncertainty)

Hi,

A 2020 study analyzing 2,927 GitHub projects found
that many repositories quickly become unmaintained.
This implies that the majority of projects don’t
sustain long-term active development.

Another study reported 46% of repositories inactive
for at least six months, and only 13% active in the
last month, showing low ongoing engagement
across most repos.

Because millions of repos exist on GitHub, and
large portions are abandoned, inactive, or minimal
“toy” projects, the fraction of repositories that are
well-maintained, collaborative, and used in
production contexts is low—roughly estimated
to be around 1–2%.

The caravan moves forth, leaving behind the
occasional turd perfectly captures GitHub. Rename
GitHub, to TurdPit, and make Amber Heard their CEO.

Bye

Mild Shock schrieb:
> Hi,
> 
> 1. Everybody’s a programmer now
>     The barrier to entry dropped dramatically — you can
>     become a "developer" with a few online tutorials
>     and a GitHub account.
> 
> 2. Everybody’s an academic now
>     Academia expanded, but standards often fell. In
>     some places, it's publish or perish, so paper
>     mills and fake research flourish.
> 
> 3. Signal Collapse ↔ Systemic Uncertainty
>     Credentials lose meaning, No reliable markers of
>     skill, Fragile systems built on shallow knowledge
> 
> 4. Signal Collapse ↔ Systemic Uncertainty
>     Quantity overwhelms quality, Important truths get
>     buried, Bad signals drown good ones
> 
> Etc..
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Having 2544 issues is probably a bad sign.
>> I find this many issues here:
>>
>> https://github.com/rocq-prover/rocq/issues
>>
>> Mostlikely 90% of the issues can be move to
>> the new discussion feature of GitHub.
>>
>> LoL
>>
>> Bye
>>
>> P.S.: Same holds for Scryer Prolog with 406 issues.
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Maybe AGI should take over proving.
>>> Just take the humans out of the loop
>>> of any programming, it leads to nowhere.
>>>
>>> Bye
>>>
>>>  > Julio Di Egidio schrieb:
>>>  > > But we must thank MS for the nail in that coffin, too: they can't
>>>  > > be satisfied with just a Lean broken by design, they must own the
>>>  > > whole compartment: only poisoned meatballs for the public...
>>>  >
>>>  > -Julio
>>>
>>> Mild Shock schrieb:
>>>> Corr.: Small typo in the number
>>>> expansion itself, should read:
>>>>
>>>> 10/81 = 0.(123456790) = 0.12345679(012345679)
>>>>
>>>> Mild Shock schrieb:
>>>>> Hi,
>>>>>
>>>>> Now somebody was so friendly to spear head
>>>>> a new Don Quixote attempt in fighting the
>>>>> windmills of compare/3. Interestingly my
>>>>>
>>>>> favorite counter example still goes through:
>>>>>
>>>>> ?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>>>>>     compare_with_stack(C, X, Y).
>>>>> X = X-0-9-7-6-5-4-3-2-1,
>>>>> Y = Y-7-5-8-2-4-1,
>>>>> C = (<).
>>>>>
>>>>> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>>>>>     compare_with_stack(C, Z, Y).
>>>>> H = H-9-7-6-5-4-3-2-1-0,
>>>>> Z = H-9-7-6-5-4-3-2-1,
>>>>> Y = Y-7-5-8-2-4-1,
>>>>> C = (>).
>>>>>
>>>>> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X = 
>>>>> X-0-9-7-6-5-4-3-2-1,
>>>>>     compare_with_stack(C, Z, X).
>>>>> H = H-9-7-6-5-4-3-2-1-0,
>>>>> Z = X, X = X-0-9-7-6-5-4-3-2-1,
>>>>> C = (=).
>>>>>
>>>>> I posted it here in March 2023:
>>>>>
>>>>> Careful with compare/3 and Brent algorithm
>>>>> https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413 
>>>>>
>>>>>
>>>>> Its based that rational terms are indeed in
>>>>> some relation to rational numbers. The above
>>>>> terms are related to:
>>>>>
>>>>> 10/81 = 0.(123456790) = 0.12345679(02345679)
>>>>>
>>>>> Bye
>>>>>
>>>>> Mild Shock schrieb:
>>>>>> Hi,
>>>>>>
>>>>>> That false/0 and not fail/0 is now all over the place,
>>>>>> I don't mean in person but for example here:
>>>>>>
>>>>>> ?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
>>>>>> false.
>>>>>>
>>>>>> Is a little didactical nightmare.
>>>>>>
>>>>>> Syntactic unification has mathematical axioms (1978),
>>>>>> to fully formalize unifcation you would need to
>>>>>> formalize both (=)/2 and (≠)/2 (sic!), otherwise you
>>>>>> rely on some negation as failure concept.
>>>>>>
>>>>>> Keith L. Clark, Negation as Failure
>>>>>> https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11
>>>>>>
>>>>>> You can realize a subset of a mixture of (=)/2
>>>>>> and (≠)/2 in the form of a vanilla unify Prolog
>>>>>> predicate using some of the meta programming
>>>>>> facilities of Prolog, like var/1 and having some
>>>>>>
>>>>>> negation as failure reading:
>>>>>>
>>>>>> /* Vanilla Unify */
>>>>>> unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
>>>>>> unify(V, T) :- var(V), !, V = T.
>>>>>> unify(S, W) :- var(W), !, W = S.
>>>>>> unify(S, T) :- functor(S, F, N), functor(T, F, N),
>>>>>>       S =.. [F|L], T =.. [F|R], maplist(unify, L, R).
>>>>>>
>>>>>> I indeed get:
>>>>>>
>>>>>> ?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
>>>>>> false.
>>>>>>
>>>>>> If the vanilla unify/2 already fails then unify
>>>>>> with and without subject to occurs check, will also
>>>>>> fail, and unify with and without ability to
>>>>>> handle rational terms, will also fail:
>>>>>>
>>>>>> Bye
>>>>>>
>>>>>> Mild Shock schrieb:
>>>>>>>
>>>>>>> Interestingly, DCG is also affect. Here a
>>>>>>> DCG take of an append app/3, it has the 2nd
>>>>>>> and 3rd argument swapped:
>>>>>>>
>>>>>>> ?- [user].
>>>>>>> app([]) --> [].
>>>>>>> app([X|Y]) --> [X], app(Y).
>>>>>>> ^D
>>>>>>>
>>>>>>> Looks like an append, taking the argument swap
>>>>>>> into account, the A=B is redundant, could
>>>>>>> be optimized away:
>>>>>>>
>>>>>>> /* SWI-Prolog 9.3.25 */
>>>>>>> ?- listing(app/3).
>>>>>>> app([], A, B) :-
>>>>>>>      A=B.
>>>>>>> app([A|B], [A|C], D) :-
>>>>>>>      app(B, C, D).
>>>>>>>
>>>>>>> And works like an append, again taking the
>>>>>>> argument swap into account:
>>>>>>>
>>>>>>> ?- app([1],X,[2,3]).
>>>>>>> X = [1, 2, 3].
>>>>>>>
>>>>>>> Now the multi-argument indexing test, still
>>>>>>> taking the argument swap into account;
>>>>>>>
>>>>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>>>>> [eclipse 3]: app(X, [1], Y).
>>>>>>>
>>>>>>> X = []
>>>>>>> Y = [1]
>>>>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>>>>
>>>>>>> X = [1]
>>>>>>> Y = []
>>>>>>> Yes (0.00s cpu, solution 2)
>>>>>>>
>>>>>>> Versus:
>>>>>>>
>>>>>>> /* SWI-Prolog 9.3.25 */
>>>>>>> ?- app(X, [1], Y).
>>>>>>> X = [],
>>>>>>> Y = [1] ;
>>>>>>> X = [1],
>>>>>>> Y = [] ;
>>>>>>> false.
>>>>>>>
>>>>>>> Mild Shock schrieb:
>>>>>>>> I am currently doing a re-evaluation of an old
>>>>>>>> Prolog system, checking what features I could adopt.
>>>>>>>> This is unlike the current trend where people have
>>>>>>>> turned their focus on GUIs, like XPCE,
>>>>>>>>
>>>>>>>> or a are stuck in an endless loop of parser
>>>>>>>> problems, like in Trealla. But I would nevertheless
>>>>>>>> share my finding. Take this simple example of
>>>>>>>> a list append:
>>>>>>>>
>>>>>>>> app([], X, X).
>>>>>>>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>>>>>>>
>>>>>>>> ECLiPSe Prolog gives me, only one redo question
>>>>>>>> in the top-level:
>>>>>>>>
>>>>>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>>>>>> [eclipse 2]: app(X,Y,[1]).
>>>>>>>>
>>>>>>>> X = []
>>>>>>>> Y = [1]
>>>>>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>>>>>
>>>>>>>> X = [1]
>>>>>>>> Y = []
>>>>>>>> Yes (0.00s cpu, solution 2)
>>>>>>>>
>>>>>>>> In SWI-Prolog I find, two redo questions
>>>>>>>> in the top.level:
>>>>>>>>
>>>>>>>> /* SWI-Prolog 9.3.25 */
>>>>>>>> ?- app(X,Y,[1]).
>>>>>>>> X = [],
>>>>>>>> Y = [1] ;
>>>>>>>> X = [1],
>>>>>>>> Y = [] ;
>>>>>>>> false.
>>>>>>>>
>>>>>>>> I know SWI-Prolog handles lists differently
>>>>>>>> than other Prolog terms during indexing. Could
>>>>>>>> this be the reason? Or maybe that the call is
>>>>>>>> not “hot” enough, so it doesn’t get JIT-ed.
>>>>>>>>
>>>>>>>> ECLiPSe Prolog does it on the very first call,
>>>>>>>> and I assume its due to a kind of index on
>>>>>>>> the 3rd argument.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14680 — Humans are just overwhelmed by computers (Was: eGovernements will need AGI to survive)

 > I checked that your examples are not counter
 > examples for my compare_with_stack/3.

What makes you think the values I show, X, Y
and Z, are possible in a total linear ordering?
The values also break predsort/3, you can easily
verify that sort([x,y,z]) =\= sort([y,x,z]):

value(x, X) :- X = X-0-9-7-6-5-4-3-2-1.
value(y, Y) :- Y = Y-7-5-8-2-4-1.
value(z, Z) :- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1.

values(L, R) :- maplist(value, L, R).

?- values([x,y,z], A), predsort(compare_with_stack, A, B),
    values([y,x,z], C), predsort(compare_with_stack, C, D),
    B == D.
false.

But expectation would be sort([x,y,z]) ==
sort([y,x,z]) since sort/2 should be immune
to permutation. If this isn’t enough proof that
there is something fishy in compare_with_stack/3 ,

well then I don’t know, maybe the earth is indeed flat?

Mild Shock schrieb:
> Hi,
> 
> Maybe AGI should take over proving.
> Just take the humans out of the loop
> of any programming, it leads to nowhere.
> 
> Bye
> 
>  > Julio Di Egidio schrieb:
>  > > But we must thank MS for the nail in that coffin, too: they can't
>  > > be satisfied with just a Lean broken by design, they must own the
>  > > whole compartment: only poisoned meatballs for the public...
>  >
>  > -Julio
> 
> Mild Shock schrieb:
>> Corr.: Small typo in the number
>> expansion itself, should read:
>>
>> 10/81 = 0.(123456790) = 0.12345679(012345679)
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Now somebody was so friendly to spear head
>>> a new Don Quixote attempt in fighting the
>>> windmills of compare/3. Interestingly my
>>>
>>> favorite counter example still goes through:
>>>
>>> ?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>>>     compare_with_stack(C, X, Y).
>>> X = X-0-9-7-6-5-4-3-2-1,
>>> Y = Y-7-5-8-2-4-1,
>>> C = (<).
>>>
>>> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
>>>     compare_with_stack(C, Z, Y).
>>> H = H-9-7-6-5-4-3-2-1-0,
>>> Z = H-9-7-6-5-4-3-2-1,
>>> Y = Y-7-5-8-2-4-1,
>>> C = (>).
>>>
>>> ?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X = 
>>> X-0-9-7-6-5-4-3-2-1,
>>>     compare_with_stack(C, Z, X).
>>> H = H-9-7-6-5-4-3-2-1-0,
>>> Z = X, X = X-0-9-7-6-5-4-3-2-1,
>>> C = (=).
>>>
>>> I posted it here in March 2023:
>>>
>>> Careful with compare/3 and Brent algorithm
>>> https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413 
>>>
>>>
>>> Its based that rational terms are indeed in
>>> some relation to rational numbers. The above
>>> terms are related to:
>>>
>>> 10/81 = 0.(123456790) = 0.12345679(02345679)
>>>
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>> Hi,
>>>>
>>>> That false/0 and not fail/0 is now all over the place,
>>>> I don't mean in person but for example here:
>>>>
>>>> ?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
>>>> false.
>>>>
>>>> Is a little didactical nightmare.
>>>>
>>>> Syntactic unification has mathematical axioms (1978),
>>>> to fully formalize unifcation you would need to
>>>> formalize both (=)/2 and (≠)/2 (sic!), otherwise you
>>>> rely on some negation as failure concept.
>>>>
>>>> Keith L. Clark, Negation as Failure
>>>> https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11
>>>>
>>>> You can realize a subset of a mixture of (=)/2
>>>> and (≠)/2 in the form of a vanilla unify Prolog
>>>> predicate using some of the meta programming
>>>> facilities of Prolog, like var/1 and having some
>>>>
>>>> negation as failure reading:
>>>>
>>>> /* Vanilla Unify */
>>>> unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
>>>> unify(V, T) :- var(V), !, V = T.
>>>> unify(S, W) :- var(W), !, W = S.
>>>> unify(S, T) :- functor(S, F, N), functor(T, F, N),
>>>>       S =.. [F|L], T =.. [F|R], maplist(unify, L, R).
>>>>
>>>> I indeed get:
>>>>
>>>> ?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
>>>> false.
>>>>
>>>> If the vanilla unify/2 already fails then unify
>>>> with and without subject to occurs check, will also
>>>> fail, and unify with and without ability to
>>>> handle rational terms, will also fail:
>>>>
>>>> Bye
>>>>
>>>> Mild Shock schrieb:
>>>>>
>>>>> Interestingly, DCG is also affect. Here a
>>>>> DCG take of an append app/3, it has the 2nd
>>>>> and 3rd argument swapped:
>>>>>
>>>>> ?- [user].
>>>>> app([]) --> [].
>>>>> app([X|Y]) --> [X], app(Y).
>>>>> ^D
>>>>>
>>>>> Looks like an append, taking the argument swap
>>>>> into account, the A=B is redundant, could
>>>>> be optimized away:
>>>>>
>>>>> /* SWI-Prolog 9.3.25 */
>>>>> ?- listing(app/3).
>>>>> app([], A, B) :-
>>>>>      A=B.
>>>>> app([A|B], [A|C], D) :-
>>>>>      app(B, C, D).
>>>>>
>>>>> And works like an append, again taking the
>>>>> argument swap into account:
>>>>>
>>>>> ?- app([1],X,[2,3]).
>>>>> X = [1, 2, 3].
>>>>>
>>>>> Now the multi-argument indexing test, still
>>>>> taking the argument swap into account;
>>>>>
>>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>>> [eclipse 3]: app(X, [1], Y).
>>>>>
>>>>> X = []
>>>>> Y = [1]
>>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>>
>>>>> X = [1]
>>>>> Y = []
>>>>> Yes (0.00s cpu, solution 2)
>>>>>
>>>>> Versus:
>>>>>
>>>>> /* SWI-Prolog 9.3.25 */
>>>>> ?- app(X, [1], Y).
>>>>> X = [],
>>>>> Y = [1] ;
>>>>> X = [1],
>>>>> Y = [] ;
>>>>> false.
>>>>>
>>>>> Mild Shock schrieb:
>>>>>> I am currently doing a re-evaluation of an old
>>>>>> Prolog system, checking what features I could adopt.
>>>>>> This is unlike the current trend where people have
>>>>>> turned their focus on GUIs, like XPCE,
>>>>>>
>>>>>> or a are stuck in an endless loop of parser
>>>>>> problems, like in Trealla. But I would nevertheless
>>>>>> share my finding. Take this simple example of
>>>>>> a list append:
>>>>>>
>>>>>> app([], X, X).
>>>>>> app([X|Y], Z, [X|T]) :- app(Y, Z, T).
>>>>>>
>>>>>> ECLiPSe Prolog gives me, only one redo question
>>>>>> in the top-level:
>>>>>>
>>>>>> /* ECLiPSe Prolog 7.1beta #13 */
>>>>>> [eclipse 2]: app(X,Y,[1]).
>>>>>>
>>>>>> X = []
>>>>>> Y = [1]
>>>>>> Yes (0.00s cpu, solution 1, maybe more) ? ;
>>>>>>
>>>>>> X = [1]
>>>>>> Y = []
>>>>>> Yes (0.00s cpu, solution 2)
>>>>>>
>>>>>> In SWI-Prolog I find, two redo questions
>>>>>> in the top.level:
>>>>>>
>>>>>> /* SWI-Prolog 9.3.25 */
>>>>>> ?- app(X,Y,[1]).
>>>>>> X = [],
>>>>>> Y = [1] ;
>>>>>> X = [1],
>>>>>> Y = [] ;
>>>>>> false.
>>>>>>
>>>>>> I know SWI-Prolog handles lists differently
>>>>>> than other Prolog terms during indexing. Could
>>>>>> this be the reason? Or maybe that the call is
>>>>>> not “hot” enough, so it doesn’t get JIT-ed.
>>>>>>
>>>>>> ECLiPSe Prolog does it on the very first call,
>>>>>> and I assume its due to a kind of index on
>>>>>> the 3rd argument.
>>>>>>
>>>>>
>>>>
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14681 — Fishy 🐟 in Scryer Prolog and SWI-Prolog (Was: Humans are just overwhelmed by computers)

Hi,

The same example values also create fishy 🐟
sorting using native sorting in Scryer Prolog:

/* Scryer Prolog 0.9.4-417 */
?- values([z,x,y], A), sort(A, B),
    values([x,y,z], C), sort(C, D), B == D.
    false. /* fishy 🐟 */

Or using native sorting in SWI-Prolog:

/* SWI-Prolog 9.3.25 */
?- values([z,x,y], A), sort(A, B),
    values([x,y,z], C), sort(C, D), B == D.
false. /* fishy 🐟 */

Bye

Mild Shock schrieb:
> 
>  > I checked that your examples are not counter
>  > examples for my compare_with_stack/3.
> 
> What makes you think the values I show, X, Y
> and Z, are possible in a total linear ordering?
> The values also break predsort/3, you can easily
> verify that sort([x,y,z]) =\= sort([y,x,z]):
> 
> value(x, X) :- X = X-0-9-7-6-5-4-3-2-1.
> value(y, Y) :- Y = Y-7-5-8-2-4-1.
> value(z, Z) :- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1.
> 
> values(L, R) :- maplist(value, L, R).
> 
> ?- values([x,y,z], A), predsort(compare_with_stack, A, B),
>     values([y,x,z], C), predsort(compare_with_stack, C, D),
>     B == D.
> false.
> 
> But expectation would be sort([x,y,z]) ==
> sort([y,x,z]) since sort/2 should be immune
> to permutation. If this isn’t enough proof that
> there is something fishy in compare_with_stack/3 ,
> 
> well then I don’t know, maybe the earth is indeed flat?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.prolog

csiph-web