History dependent semi_lex_compare/3

General
32

Don’t use my random_cyclic/1 in place of @ridgeworks random_cyclic/1.
He modified it to return only ground. He posted about that. But the transitivity

violation in your code exists. It seems to be reproducible in the top-level of
SWI-Prolog. Maybe should double check with another Prolog system?

/* SWI-Prolog 9.1.7 */
?- T1 = s(s(T1, 0), T1), T2 = s(T2, 1), T3 = _S3, % where
    _S1 = s(_S1, _S2),
    _S2 = s(_S2, 0),
    _S3 = s(_S1, _S3),    
    compare_with_stack(C1,T1,T2,[],F1), compare_with_stack(C2,T2,T3,F1,F2), 
    compare_with_stack(C3,T1,T3,F2,_), C1==C2, C1\==C3.
% answer:
C1 = C2, C2 = (<),
C3 = (>).

So compare_with_stack/5 cannot be used for sort/2.

Edit 03.04.2023
But they are very few. They are much rarer than those for native compare/3 or
for compare_stack/3. When using 10’000’000 iterations I get:

?- aggregate_all(count, (between(1,10000000,_), random_cyclic(T1), ground(T1),
random_cyclic(T2), ground(T2), random_cyclic(T3), ground(T3),
compare_with_stack(C1,T1,T2,[],F1), compare_with_stack(C2,T2,T3,F1,F2), 
compare_with_stack(C3,T1,T3,F2,_), C1==C2, C1\==C3), F).
F = 1.

Hope its not a bug in SWI-Prolog itself. But if it were a bug, since I can reproduce an example
on the top-level, it would be a bug not related to the failure driven loop.