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

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

Prolog totally missed the AI Boom

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

Contents

  Prolog totally missed the AI Boom Mild Shock <janburse@fastmail.fm> - 2025-02-22 13:05 +0100
    Auto-Encoders as Prolog Fact Stores (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-02-22 22:51 +0100
      Ignorance in ILP circles confirmed (Was: Auto-Encoders as Prolog Fact Stores) Mild Shock <janburse@fastmail.fm> - 2025-02-23 18:33 +0100
      Neuro infused logic programming [NILP] (Was: Auto-Encoders as Prolog Fact Stores) Mild Shock <janburse@fastmail.fm> - 2025-03-19 20:58 +0100
    Last Exit Analogical Resoning (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-03-07 18:16 +0100
    A software engineering analyis why Prolog fails (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-03-25 12:22 +0100
      Lets re-iterate software engineering first! (Was: A software engineering analyis why Prolog fails) Mild Shock <janburse@fastmail.fm> - 2025-03-27 11:42 +0100
        Re: Lets re-iterate software engineering first! (Was: A software engineering analyis why Prolog fails) Mild Shock <janburse@fastmail.fm> - 2025-03-27 11:43 +0100
    No Coders completely Brain Dead (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-06-23 16:37 +0200
      Unicode and atom length=1 (Was: No Coders completely Brain Dead) Mild Shock <janburse@fastmail.fm> - 2025-06-23 16:47 +0200
        Most radical approach is Novacore from Dogelog Player (Was: Unicode and atom length=1) Mild Shock <janburse@fastmail.fm> - 2025-06-23 17:03 +0200
          SWI-Prolog master not wide awake, doing day-sleeping (Was: Most radical approach is Novacore from Dogelog Player) Mild Shock <janburse@fastmail.fm> - 2025-06-23 18:43 +0200
            Re: SWI-Prolog master not wide awake, doing day-sleeping (Was: Most radical approach is Novacore from Dogelog Player) Mild Shock <janburse@fastmail.fm> - 2025-06-23 18:44 +0200
            The beauty of a double hook (Was: SWI-Prolog master not wide awake, doing day-sleeping) Mild Shock <janburse@fastmail.fm> - 2025-06-23 18:45 +0200
            The beauty of a dual use hook (Was: SWI-Prolog master not wide awake, doing day-sleeping) Mild Shock <janburse@fastmail.fm> - 2025-06-23 19:01 +0200
              maplist(char_code, Chars, Codes) is bidirectional (Was: The beauty of a dual use hook) Mild Shock <janburse@fastmail.fm> - 2025-06-23 19:17 +0200
                I really have lost all hope and given up (Was: maplist(char_code, Chars, Codes) is bidirectional) Mild Shock <janburse@fastmail.fm> - 2025-06-23 19:31 +0200
          Do Prologers know the Unicode Range? (Was: Most radical approach is Novacore from Dogelog Player) Mild Shock <janburse@fastmail.fm> - 2025-06-27 13:21 +0200
            Can Prologers produce 100% Prolog Code? (Was: Do Prologers know the Unicode Range?) Mild Shock <janburse@fastmail.fm> - 2025-06-27 13:22 +0200
              Attention: Python versus Java (Was: Can Prologers produce 100% Prolog Code?) Mild Shock <janburse@fastmail.fm> - 2025-06-27 13:36 +0200
          Is there a Swiss Army Knife of launching a Prolog system (Was: Most radical approach is Novacore from Dogelog Player) Mild Shock <janburse@fastmail.fm> - 2025-07-13 15:17 +0200
            An -e option could be the more rational choice (Was: Is there a Swiss Army Knife of launching a Prolog system) Mild Shock <janburse@fastmail.fm> - 2025-07-13 15:19 +0200
          Prolog Cycle detection in the Top-Level (Was: Most radical approach is Novacore from Dogelog Player) Mild Shock <janburse@fastmail.fm> - 2025-07-20 13:39 +0200
            What does SWI-Prolog / Ciao Prolog produce? (Was: Prolog Cycle detection in the Top-Level) Mild Shock <janburse@fastmail.fm> - 2025-07-20 13:43 +0200
    Do not give dogs what is holy [Matthew 7:6] (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-06-23 20:33 +0200
      Typo:: Do not give dogs what is holy [Matthew 7:6] (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-06-23 20:38 +0200
        What WG17 could do to prevent segregation [DEC-10 Prolog (10 November 1982)] (Was: Typo:: Do not give dogs what is holy) Mild Shock <janburse@fastmail.fm> - 2025-06-23 21:16 +0200
          Avoid the cheap tricks by Scryer Prolog (Was: What WG17 could do to prevent segregation [DEC-10 Prolog (10 November 1982)]) Mild Shock <janburse@fastmail.fm> - 2025-06-23 22:19 +0200
            Why tuck the tail in front of a false Messias (Was: Avoid the cheap tricks by Scryer Prolog) Mild Shock <janburse@fastmail.fm> - 2025-06-23 22:20 +0200
    Missed the AI Boom because missed the Emojis (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-06-29 13:32 +0200
      Bonus in Trealla Prolog, different Tokenizer (Was: Missed the AI Boom because missed the Emojis) Mild Shock <janburse@fastmail.fm> - 2025-06-29 13:36 +0200
    Science is not prepared for the AI Revolution (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-06-29 16:35 +0200
    Bart Demoen's amageddon revisited (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-07-09 01:55 +0200
      Long story short: Not everybody was blended by Bart Demoen (Was: Bart Demoen's amageddon revisited) Mild Shock <janburse@fastmail.fm> - 2025-07-09 02:08 +0200
        On last sample: Barty Boy in full swing (Re: Long story short: Not everybody was blended by Bart Demoen) Mild Shock <janburse@fastmail.fm> - 2025-07-09 02:12 +0200
          I hope he doesn't get a heart attack (Was: On last sample: Barty Boy in full swing) Mild Shock <janburse@fastmail.fm> - 2025-07-09 02:23 +0200
    Would Poincaré miss the AI Boom (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-07-10 19:17 +0200
      The ideal choice point as a logical formula (Was: Would Poincaré miss the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-07-10 21:22 +0200
        What is practical choice point eliminaton then? (Was: The ideal choice point as a logical formula) Mild Shock <janburse@fastmail.fm> - 2025-07-10 21:30 +0200
          Relation of the practical to the mathematical oracle (Was: What is practical choice point eliminaton then?) Mild Shock <janburse@fastmail.fm> - 2025-07-10 21:35 +0200
            Should try semi-deep Prolog argument indexing (Was: Relation of the practical to the mathematical oracle) Mild Shock <janburse@fastmail.fm> - 2025-07-10 21:43 +0200
              Benefit and drawback: (Semi-)Deep indexing still rare! (Was: Should try semi-deep Prolog argument indexing) Mild Shock <janburse@fastmail.fm> - 2025-07-10 21:58 +0200
                Does DCG standard [2025] say (Semi-)Deep indexing? (Was: Benefit and drawback: (Semi-)Deep indexing still rare!) Mild Shock <janburse@fastmail.fm> - 2025-07-10 22:03 +0200
      Stack Overflow is declining, and GitHub might be next (Was: Would Poincaré miss the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-07-15 20:55 +0200
        GitHub 2.0: The no code companion repository (Was: Stack Overflow is declining, and GitHub might be next) Mild Shock <janburse@fastmail.fm> - 2025-07-15 21:15 +0200
      Gian-Carlo Rota’s legacy and modern AI (Was: Would Poincaré miss the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-07-17 12:00 +0200
    Will the world build on American Stacks? (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-07-14 15:55 +0200
      Analogy as a Core of Intelligence (Human & Artificial) (Re: Will the world build on American Stacks?) Mild Shock <janburse@fastmail.fm> - 2025-07-17 12:14 +0200
        Alain Colmerauer Analogy : Rational Terms / Rational Numbers (Was: Analogy as a Core of Intelligence) Mild Shock <janburse@fastmail.fm> - 2025-07-17 14:33 +0200
          FYI: Peter Aczel Memorial Conference [10th September 2025] (Re: Alain Colmerauer Analogy : Rational Terms / Rational Numbers) Mild Shock <janburse@fastmail.fm> - 2025-07-17 14:57 +0200
            s/Coq/Rocq not found (Re: FYI: Peter Aczel Memorial Conference [10th September 2025]) Mild Shock <janburse@fastmail.fm> - 2025-07-17 23:17 +0200
              Wonder Years are Over: Next Step Mars (Was: s/Coq/Rocq not found) Mild Shock <janburse@fastmail.fm> - 2025-07-17 23:36 +0200
            Some of the legacy of Alain Colmerauer (Re: FYI: Peter Aczel Memorial Conference [10th September 2025]) Mild Shock <janburse@fastmail.fm> - 2025-07-23 19:10 +0200
    Looks like sorting of rational trees needs an existential type (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-07-23 13:57 +0200
      LLMs / Autoencoders could profit for Bisimulation Quotienting (Re: Looks like sorting of rational trees needs an existential type) Mild Shock <janburse@fastmail.fm> - 2025-07-23 14:03 +0200
        Are you Geh? From bi-simulation to bi-similarity (Was: LLMs / Autoencoders could profit for Bisimulation Quotienting) Mild Shock <janburse@fastmail.fm> - 2025-07-23 15:18 +0200
          Quite vibrant logic history one can experience right now! (Re: Are you Geh? From bi-simulation to bi-similarity) Mild Shock <janburse@fastmail.fm> - 2025-07-23 19:14 +0200
    The Prolog Community is extremly embarrassing (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-07-25 21:27 +0200
      Non-Wellfounded and Russell Paradox, what is your opinion? (Re: The Prolog Community is extremly embarrassing) Mild Shock <janburse@fastmail.fm> - 2025-07-25 21:38 +0200
        Unfinished Bimbo Stuff: 4.1. Trees as terms (Re: Non-Wellfounded and Russell Paradox, what is your opinion?) Mild Shock <janburse@fastmail.fm> - 2025-07-25 23:03 +0200
          Gold medal waiting for the crankiest of cranks (Was: Unfinished Bimbo Stuff: 4.1. Trees as terms) Mild Shock <janburse@fastmail.fm> - 2025-07-26 16:10 +0200
            Old School Logicians waste time with compare/3 ? (Was: Gold medal waiting for the crankiest of cranks) Mild Shock <janburse@fastmail.fm> - 2025-07-26 16:17 +0200
              Is compare/3 a sunflower study subject? (Was: Old School Logicians waste time with compare/3 ?) Mild Shock <janburse@fastmail.fm> - 2025-07-26 16:36 +0200
    Lattent Thinking the forbidden Fruit (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-11-02 11:58 +0100
    Latent Thinking the forbidden Fruit (Was: Prolog totally missed the AI Boom) Mild Shock <janburse@fastmail.fm> - 2025-11-02 12:19 +0100
      Fully automated AI researcher in your team? (Re: Latent Thinking the forbidden Fruit) Mild Shock <janburse@fastmail.fm> - 2025-11-02 13:20 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#14451 — Prolog totally missed the AI Boom

Inductive logic programming at 30
https://arxiv.org/abs/2102.10556

The paper contains not a single reference to autoencoders!
Still they show this example:

Fig. 1 ILP systems struggle with structured examples that
exhibit observational noise. All three examples clearly
spell the word "ILP", with some alterations: 3 noisy pixels,
shifted and elongated letters. If we would be to learn a
program that simply draws "ILP" in the middle of the picture,
without noisy pixels and elongated letters, that would
be a correct program.

I guess ILP is 30 years behind the AI boom. An early autoencoder
turned into transformer was already reported here (*):

SERIAL ORDER, Michael I. Jordan - May 1986
https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf

Well ILP might have its merits, maybe we should not ask
for a marriage of LLM and Prolog, but Autoencoders and ILP.
But its tricky, I am still trying to decode the da Vinci code of

things like stacked tensors, are they related to k-literal clauses?
The paper I referenced is found in this excellent video:

The Making of ChatGPT (35 Year History)
https://www.youtube.com/watch?v=OFS90-FX6pg

[toc] | [next] | [standalone]

#14452 — Auto-Encoders as Prolog Fact Stores (Was: Prolog totally missed the AI Boom)

Hi,

One idea I had was that autoencoders would
become kind of invisible, and work under the hood
to compress Prolog facts. Take these facts:

% standard _, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
data(seg7, [0,0,0,0,0,0,0], [0,0,0,0,0,0,0]).
data(seg7, [1,1,1,1,1,1,0], [1,1,1,1,1,1,0]).
data(seg7, [0,1,1,0,0,0,0], [0,1,1,0,0,0,0]).
data(seg7, [1,1,0,1,1,0,1], [1,1,0,1,1,0,1]).
data(seg7, [1,1,1,1,0,0,1], [1,1,1,1,0,0,1]).
data(seg7, [0,1,1,0,0,1,1], [0,1,1,0,0,1,1]).
data(seg7, [1,0,1,1,0,1,1], [1,0,1,1,0,1,1]).
data(seg7, [1,0,1,1,1,1,1], [1,0,1,1,1,1,1]).
data(seg7, [1,1,1,0,0,0,0], [1,1,1,0,0,0,0]).
data(seg7, [1,1,1,1,1,1,1], [1,1,1,1,1,1,1]).
data(seg7, [1,1,1,1,0,1,1], [1,1,1,1,0,1,1]).
% alternatives 9, 7, 6, 1
data(seg7, [1,1,1,0,0,1,1], [1,1,1,1,0,1,1]).
data(seg7, [1,1,1,0,0,1,0], [1,1,1,0,0,0,0]).
data(seg7, [0,0,1,1,1,1,1], [1,0,1,1,1,1,1]).
data(seg7, [0,0,0,0,1,1,0], [0,1,1,0,0,0,0]).
https://en.wikipedia.org/wiki/Seven-segment_display

Or more visually, 9 7 6 1 have variants trained:

:- show.
_0123456789(9)(7)(6)(1)

The auto encoder would create a latent space, an
encoder, and a decoder. And we could basically query
?- data(seg7, X, Y) with X input, and Y output,

9 7 6 1 were corrected:

:- random2.
0, 0
_01234567899761

The autoencoder might also tolerate errors in the
input that are not in the data, giving it some inferential
capability. And then choose an output again not in

the data, giving it some generative capabilities.

Bye

See also:

What is Latent Space in Deep Learning?
https://www.geeksforgeeks.org/what-is-latent-space-in-deep-learning/

Mild Shock schrieb:
> 
> Inductive logic programming at 30
> https://arxiv.org/abs/2102.10556
> 
> The paper contains not a single reference to autoencoders!
> Still they show this example:
> 
> Fig. 1 ILP systems struggle with structured examples that
> exhibit observational noise. All three examples clearly
> spell the word "ILP", with some alterations: 3 noisy pixels,
> shifted and elongated letters. If we would be to learn a
> program that simply draws "ILP" in the middle of the picture,
> without noisy pixels and elongated letters, that would
> be a correct program.
> 
> I guess ILP is 30 years behind the AI boom. An early autoencoder
> turned into transformer was already reported here (*):
> 
> SERIAL ORDER, Michael I. Jordan - May 1986
> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
> 
> Well ILP might have its merits, maybe we should not ask
> for a marriage of LLM and Prolog, but Autoencoders and ILP.
> But its tricky, I am still trying to decode the da Vinci code of
> 
> things like stacked tensors, are they related to k-literal clauses?
> The paper I referenced is found in this excellent video:
> 
> The Making of ChatGPT (35 Year History)
> https://www.youtube.com/watch?v=OFS90-FX6pg
> 

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

#14453 — Ignorance in ILP circles confirmed (Was: Auto-Encoders as Prolog Fact Stores)

Hi,

Somebody wrote:

 > It’s a self-supervised form of ILP.
 > No autoencoders anywhere at all.

And, this only proofs my point that ILP doesn’t
solve the problem to make autoencoders and transformers
available directly in Prolog. Which was the issue I posted
at the top of this thread.

Subsequently I would not look into ILP for Prolog
autoencoders and transformers is my point exactly. Because
mostlikely ILP is unaware of the concept of latent space.
Latent space has quite some advantages:

- *Dimensionality Reduction:* It captures the essential
   structure of high-dimensional data in a more
   compact form.

- *Synthetic Data:* Instead of modifying raw data, you can
   use the latent space, to generate variations for
   further learning.

- *Domain Adaptation:* Well-structured latent space can
   help transfer knowledge from abundant domains to
   underrepresented ones.

If you don’t mention autoencoders and transformers at
all, you are possibly also not aware of the above advantages
and other properties of autoencoders and transformers.

In ILP mostlikely the concept of latent space is dormant
or blurred, since the stance is well we invent predicates,
ergo relations. There is no attempt to break

down relations further:

https://www.v7labs.com/blog/autoencoders-guide

Basically autoencoders and transformers, by imposing some
hidden layer, are further structuring relations into an
encoder and a decoder. So a relation is seen as a join.

The H is the bottleneck on purpose:

relation(X, Y) :- encoder(X, H), decoder(H, Y).

The values of H go through the latent space which is
invented during the learning process. It is not simply
the input or output space.

This design has some very interesting repercussions.

Bye

Mild Shock schrieb:
> Hi,
> 
> One idea I had was that autoencoders would
> become kind of invisible, and work under the hood
> to compress Prolog facts. Take these facts:
> 
> % standard _, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
> data(seg7, [0,0,0,0,0,0,0], [0,0,0,0,0,0,0]).
> data(seg7, [1,1,1,1,1,1,0], [1,1,1,1,1,1,0]).
> data(seg7, [0,1,1,0,0,0,0], [0,1,1,0,0,0,0]).
> data(seg7, [1,1,0,1,1,0,1], [1,1,0,1,1,0,1]).
> data(seg7, [1,1,1,1,0,0,1], [1,1,1,1,0,0,1]).
> data(seg7, [0,1,1,0,0,1,1], [0,1,1,0,0,1,1]).
> data(seg7, [1,0,1,1,0,1,1], [1,0,1,1,0,1,1]).
> data(seg7, [1,0,1,1,1,1,1], [1,0,1,1,1,1,1]).
> data(seg7, [1,1,1,0,0,0,0], [1,1,1,0,0,0,0]).
> data(seg7, [1,1,1,1,1,1,1], [1,1,1,1,1,1,1]).
> data(seg7, [1,1,1,1,0,1,1], [1,1,1,1,0,1,1]).
> % alternatives 9, 7, 6, 1
> data(seg7, [1,1,1,0,0,1,1], [1,1,1,1,0,1,1]).
> data(seg7, [1,1,1,0,0,1,0], [1,1,1,0,0,0,0]).
> data(seg7, [0,0,1,1,1,1,1], [1,0,1,1,1,1,1]).
> data(seg7, [0,0,0,0,1,1,0], [0,1,1,0,0,0,0]).
> https://en.wikipedia.org/wiki/Seven-segment_display
> 
> Or more visually, 9 7 6 1 have variants trained:
> 
> :- show.
> _0123456789(9)(7)(6)(1)
> 
> The auto encoder would create a latent space, an
> encoder, and a decoder. And we could basically query
> ?- data(seg7, X, Y) with X input, and Y output,
> 
> 9 7 6 1 were corrected:
> 
> :- random2.
> 0, 0
> _01234567899761
> 
> The autoencoder might also tolerate errors in the
> input that are not in the data, giving it some inferential
> capability. And then choose an output again not in
> 
> the data, giving it some generative capabilities.
> 
> Bye
> 
> See also:
> 
> What is Latent Space in Deep Learning?
> https://www.geeksforgeeks.org/what-is-latent-space-in-deep-learning/
> 
> Mild Shock schrieb:
>>
>> Inductive logic programming at 30
>> https://arxiv.org/abs/2102.10556
>>
>> The paper contains not a single reference to autoencoders!
>> Still they show this example:
>>
>> Fig. 1 ILP systems struggle with structured examples that
>> exhibit observational noise. All three examples clearly
>> spell the word "ILP", with some alterations: 3 noisy pixels,
>> shifted and elongated letters. If we would be to learn a
>> program that simply draws "ILP" in the middle of the picture,
>> without noisy pixels and elongated letters, that would
>> be a correct program.
>>
>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>> turned into transformer was already reported here (*):
>>
>> SERIAL ORDER, Michael I. Jordan - May 1986
>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
>>
>> Well ILP might have its merits, maybe we should not ask
>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>> But its tricky, I am still trying to decode the da Vinci code of
>>
>> things like stacked tensors, are they related to k-literal clauses?
>> The paper I referenced is found in this excellent video:
>>
>> The Making of ChatGPT (35 Year History)
>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>
> 

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

#14481 — Neuro infused logic programming [NILP] (Was: Auto-Encoders as Prolog Fact Stores)

Hi,

I first wanted to use a working title:

"new frontiers in logic programming"

But upon reflection and because of fElon,
here another idea for a working title:

"neuro infused logic programming" (NILP)

What could it mean? Or does it have some
alternative phrasing already?

Try this paper:

Compositional Neural Logic Programming
Son N. Tran - 2021
The combination of connectionist models for low-level
information processing and logic programs for high-level
decision making can offer improvements in inference
efficiency and prediction performance
https://www.ijcai.org/proceedings/2021/421

Browsing through the bibliography I find:

[Cohen et al., 2017]
Tensorlog: Deep learning meets probabilistic

[Donadello et al., 2017]
Logic tensor networks

[Larochelle and Murray, 2011]
The neural autoregressive distribution estimator

[Manhaeve et al., 2018]
Neural probabilistic logic programming

[Mirza and Osindero, 2014]
Conditional generative adversarial nets

[Odena et al., 2017]
auxiliary classifier GANs

[Pierrot et al., 2019]
compositional neural programs

[Reed and de Freitas, 2016]
Neural programmer-interpreters

[Riveret et al., 2020]
Neuro-Symbolic Probabilistic Argumentation Machines

[Serafini and d’Avila Garcez, 2016]
logic tensor networks.

[Socher et al., 2013]
neural tensor networks

[Towell and Shavlik, 1994]
Knowledge-based artificial neural networks

[Tran and d’Avila Garcez, 2018]
Deep logic networks

[Wang et al., 2019]
compositional neural information fusion


Mild Shock schrieb:
> Hi,
> 
> One idea I had was that autoencoders would
> become kind of invisible, and work under the hood
> to compress Prolog facts. Take these facts:
> 
> % standard _, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
> data(seg7, [0,0,0,0,0,0,0], [0,0,0,0,0,0,0]).
> data(seg7, [1,1,1,1,1,1,0], [1,1,1,1,1,1,0]).
> data(seg7, [0,1,1,0,0,0,0], [0,1,1,0,0,0,0]).
> data(seg7, [1,1,0,1,1,0,1], [1,1,0,1,1,0,1]).
> data(seg7, [1,1,1,1,0,0,1], [1,1,1,1,0,0,1]).
> data(seg7, [0,1,1,0,0,1,1], [0,1,1,0,0,1,1]).
> data(seg7, [1,0,1,1,0,1,1], [1,0,1,1,0,1,1]).
> data(seg7, [1,0,1,1,1,1,1], [1,0,1,1,1,1,1]).
> data(seg7, [1,1,1,0,0,0,0], [1,1,1,0,0,0,0]).
> data(seg7, [1,1,1,1,1,1,1], [1,1,1,1,1,1,1]).
> data(seg7, [1,1,1,1,0,1,1], [1,1,1,1,0,1,1]).
> % alternatives 9, 7, 6, 1
> data(seg7, [1,1,1,0,0,1,1], [1,1,1,1,0,1,1]).
> data(seg7, [1,1,1,0,0,1,0], [1,1,1,0,0,0,0]).
> data(seg7, [0,0,1,1,1,1,1], [1,0,1,1,1,1,1]).
> data(seg7, [0,0,0,0,1,1,0], [0,1,1,0,0,0,0]).
> https://en.wikipedia.org/wiki/Seven-segment_display
> 
> Or more visually, 9 7 6 1 have variants trained:
> 
> :- show.
> _0123456789(9)(7)(6)(1)
> 
> The auto encoder would create a latent space, an
> encoder, and a decoder. And we could basically query
> ?- data(seg7, X, Y) with X input, and Y output,
> 
> 9 7 6 1 were corrected:
> 
> :- random2.
> 0, 0
> _01234567899761
> 
> The autoencoder might also tolerate errors in the
> input that are not in the data, giving it some inferential
> capability. And then choose an output again not in
> 
> the data, giving it some generative capabilities.
> 
> Bye
> 
> See also:
> 
> What is Latent Space in Deep Learning?
> https://www.geeksforgeeks.org/what-is-latent-space-in-deep-learning/
> 
> Mild Shock schrieb:
>>
>> Inductive logic programming at 30
>> https://arxiv.org/abs/2102.10556
>>
>> The paper contains not a single reference to autoencoders!
>> Still they show this example:
>>
>> Fig. 1 ILP systems struggle with structured examples that
>> exhibit observational noise. All three examples clearly
>> spell the word "ILP", with some alterations: 3 noisy pixels,
>> shifted and elongated letters. If we would be to learn a
>> program that simply draws "ILP" in the middle of the picture,
>> without noisy pixels and elongated letters, that would
>> be a correct program.
>>
>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>> turned into transformer was already reported here (*):
>>
>> SERIAL ORDER, Michael I. Jordan - May 1986
>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
>>
>> Well ILP might have its merits, maybe we should not ask
>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>> But its tricky, I am still trying to decode the da Vinci code of
>>
>> things like stacked tensors, are they related to k-literal clauses?
>> The paper I referenced is found in this excellent video:
>>
>> The Making of ChatGPT (35 Year History)
>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>
> 

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

#14466 — Last Exit Analogical Resoning (Was: Prolog totally missed the AI Boom)

The problem I am trying to address was
already adressed here:

ILP and Reasoning by Analogy
Intuitively, the idea is to use what is already
known to explain new observations that appear similar
to old knowledge. In a sense, it is opposite of induction,
where to explain the observations one comes up with
new hypotheses/theories.
Vesna Poprcova et al. - 2010
https://www.researchgate.net/publication/220141214

The problem consists in that ILP doesn’t try to
learn and apply analogies , whereas autoencoders and
transformers typically try to “Grok” analogies, so that
with a fewer training they can perform

well in certain domains. They will do some inferencing
on the part of the encoders also for unseen input
data. And they will do some generation on the part of
the decoder also for unseen

latent space configurations from unseen input data.
By unseen data I mean data not in the training set.
The full context window may tune the inferencing and
generation, which appeals to:

Analogy as a Search Procedure
Rumelhart and Abrahamson showed that when presented
with analogy problems like mokey:pig:gorilla:X, with
rabbit, tiger, cow, and elephant as alternatives for X,
subjects rank the four options following the
parallelogram rule.
Matías Osta-Vélez - 2022
https://www.researchgate.net/publication/363700634

There are learning methods that work similarly
like ILP, in that they are based on positive and
negative samples. And the statistics can involve
bilinear forms, similar like

is seen in the “Attention is all you Need” paper.
But I have not yet a good implementation of this
evisioned marriage of autoencoders and ILP, and
I am still researching the topic.

Mild Shock schrieb:
> 
> Inductive logic programming at 30
> https://arxiv.org/abs/2102.10556
> 
> The paper contains not a single reference to autoencoders!
> Still they show this example:
> 
> Fig. 1 ILP systems struggle with structured examples that
> exhibit observational noise. All three examples clearly
> spell the word "ILP", with some alterations: 3 noisy pixels,
> shifted and elongated letters. If we would be to learn a
> program that simply draws "ILP" in the middle of the picture,
> without noisy pixels and elongated letters, that would
> be a correct program.
> 
> I guess ILP is 30 years behind the AI boom. An early autoencoder
> turned into transformer was already reported here (*):
> 
> SERIAL ORDER, Michael I. Jordan - May 1986
> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
> 
> Well ILP might have its merits, maybe we should not ask
> for a marriage of LLM and Prolog, but Autoencoders and ILP.
> But its tricky, I am still trying to decode the da Vinci code of
> 
> things like stacked tensors, are they related to k-literal clauses?
> The paper I referenced is found in this excellent video:
> 
> The Making of ChatGPT (35 Year History)
> https://www.youtube.com/watch?v=OFS90-FX6pg
> 

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

#14485 — A software engineering analyis why Prolog fails (Was: Prolog totally missed the AI Boom)

Hi,

A software engineering analyis why Prolog fails
================================================

You would also get more done, if Prolog had some
well design plug and play machine learning libraries.
Currently most SWI Prolog packages are just GitHub dumps:

(Python) Problem ---> import solver ---> Solution

(SWI) Problem ---> install pack ---> Problem

Python shows more success in the practitioners domain,
since it has more libraries that have made the test of
time of practial use. Whereas Prolog is still in its
infancy in many domains,

you don’t arrive at the same level of convenience and
breadth as Python, if you have only fire and forget dumps
offered, from some PhD projects where software engineering
is secondary.

I don’t know exactly why Prolog has so much problems
with software engineering. Python has object orientation,
but Logtalk didn’t make the situation better. SWI-Prolog
has modules, but they are never used. For example this

here is a big monolith:

This module performs learning over Logic Programs
https://github.com/friguzzi/liftcover/blob/main/prolog/liftcover.pl

Its more designed towards providing some command line
control. But if you look into it, it has EM algorithms
and gradient algorithm, and who knows what. These building
blocks are not exposed,

not made towards reused or towards improvement by
switching in 3rd party alternatives. Mostlikely a design
flaw inside the pack mechanism itself, since it assumes a
single main module?

So the pack mechanism works, if a unit pack imports a
clp(BNR) pack, since it uses the single entry of clp(BNR).
But it is never on paar with the richness of Python packages,
which have more a hierarchical structure of many

many modules in their packs.

Mild Shock schrieb:
> 
> Inductive logic programming at 30
> https://arxiv.org/abs/2102.10556
> 
> The paper contains not a single reference to autoencoders!
> Still they show this example:
> 
> Fig. 1 ILP systems struggle with structured examples that
> exhibit observational noise. All three examples clearly
> spell the word "ILP", with some alterations: 3 noisy pixels,
> shifted and elongated letters. If we would be to learn a
> program that simply draws "ILP" in the middle of the picture,
> without noisy pixels and elongated letters, that would
> be a correct program.
> 
> I guess ILP is 30 years behind the AI boom. An early autoencoder
> turned into transformer was already reported here (*):
> 
> SERIAL ORDER, Michael I. Jordan - May 1986
> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
> 
> Well ILP might have its merits, maybe we should not ask
> for a marriage of LLM and Prolog, but Autoencoders and ILP.
> But its tricky, I am still trying to decode the da Vinci code of
> 
> things like stacked tensors, are they related to k-literal clauses?
> The paper I referenced is found in this excellent video:
> 
> The Making of ChatGPT (35 Year History)
> https://www.youtube.com/watch?v=OFS90-FX6pg
> 

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

#14487 — Lets re-iterate software engineering first! (Was: A software engineering analyis why Prolog fails)

I have retracted those posts, that had Python-first
in it, not sure whether my analysis about some projects
was water thight. I only made the Python example as to
illustrate the idea of

a variation point. I do not think programming language
trench wars are good idea, and one should put software
engineering -first, as an abstract computer science
discipline. Not doing so

is only a distraction from the real issues at hand.
Variation points where defined quite vaguely
on purpose:

 > Ivar Jacobson defines a variation point as follows:
 > A variation point identifies one or more locations at
 > which the variation will occur.

Variation points can come in many shades, and for
example ProbLog based approaches take the viewpoint
of a Prolog text with a lot of configuration flags
and predicate

annotations. This is quite different from the
autoencoder or transformer component approach I
suggested here. In particular component oriented
approach could be

more flexible and dynamic, when they allow programmatic
configuration of components. The drawback is you cannot
understand what the program does by looking at a

simply structured Prolog text. Although I expected
the situation is not that bad, and one could do
something similar to a table/1 directive, i.e. some
directive that says

look, this predicate is an autoencoder or transformer:

 > One idea I had was that autoencoders would become
 > kind of invisible, and work under the hood to compress
 > Prolog facts. Take these facts:
 >
 > % standard _, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
 > data(seg7, [0,0,0,0,0,0,0], [0,0,0,0,0,0,0]).

So to instruct the Prolog system to do what is sketched,
one would possibly need a new directive autoencoder/1:

:- autoencoder data/3.

Mild Shock schrieb:
> Hi,
> 
> A software engineering analyis why Prolog fails
> ================================================
> 
> You would also get more done, if Prolog had some
> well design plug and play machine learning libraries.
> Currently most SWI Prolog packages are just GitHub dumps:
> 
> (Python) Problem ---> import solver ---> Solution
> 
> (SWI) Problem ---> install pack ---> Problem
> 
> Python shows more success in the practitioners domain,
> since it has more libraries that have made the test of
> time of practial use. Whereas Prolog is still in its
> infancy in many domains,
> 
> you don’t arrive at the same level of convenience and
> breadth as Python, if you have only fire and forget dumps
> offered, from some PhD projects where software engineering
> is secondary.
> 
> I don’t know exactly why Prolog has so much problems
> with software engineering. Python has object orientation,
> but Logtalk didn’t make the situation better. SWI-Prolog
> has modules, but they are never used. For example this
> 
> here is a big monolith:
> 
> This module performs learning over Logic Programs
> https://github.com/friguzzi/liftcover/blob/main/prolog/liftcover.pl
> 
> Its more designed towards providing some command line
> control. But if you look into it, it has EM algorithms
> and gradient algorithm, and who knows what. These building
> blocks are not exposed,
> 
> not made towards reused or towards improvement by
> switching in 3rd party alternatives. Mostlikely a design
> flaw inside the pack mechanism itself, since it assumes a
> single main module?
> 
> So the pack mechanism works, if a unit pack imports a
> clp(BNR) pack, since it uses the single entry of clp(BNR).
> But it is never on paar with the richness of Python packages,
> which have more a hierarchical structure of many
> 
> many modules in their packs.
> 
> Mild Shock schrieb:
>>
>> Inductive logic programming at 30
>> https://arxiv.org/abs/2102.10556
>>
>> The paper contains not a single reference to autoencoders!
>> Still they show this example:
>>
>> Fig. 1 ILP systems struggle with structured examples that
>> exhibit observational noise. All three examples clearly
>> spell the word "ILP", with some alterations: 3 noisy pixels,
>> shifted and elongated letters. If we would be to learn a
>> program that simply draws "ILP" in the middle of the picture,
>> without noisy pixels and elongated letters, that would
>> be a correct program.
>>
>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>> turned into transformer was already reported here (*):
>>
>> SERIAL ORDER, Michael I. Jordan - May 1986
>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
>>
>> Well ILP might have its merits, maybe we should not ask
>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>> But its tricky, I am still trying to decode the da Vinci code of
>>
>> things like stacked tensors, are they related to k-literal clauses?
>> The paper I referenced is found in this excellent video:
>>
>> The Making of ChatGPT (35 Year History)
>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>
> 

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

#14488 — Re: Lets re-iterate software engineering first! (Was: A software engineering analyis why Prolog fails)

But even with such a directive there are many
challenges, which ProbLog suffers also from. Consider
this transformer pipeline, with two components of
type g twice:

      +----+   +----+   +----+
      |    |-->| g  |-->|    |
      |    |   +----+   |    |
x -->| f  |            | h  |--> y
      |    |   +----+   |    |
      |    |-->| g  |-->|    |
      +----+   +----+   +----+

With common subexpessions, i.e. computing
f only once, I can write the forward pass
as follows:

p, q = f(x)
y = h(g(p), g(q))

But the above doesn’t show the learnt parameters.
Will g and g be siamese neural networks, learning
one sets of parameters, or will they learn
two sets of parameters? See also:

Siamese neural network
https://en.wikipedia.org/wiki/Siamese_neural_network

If I am not mistaken in ProbLog one can use
variables to indicate probabilities annotation.
An example of such a variable is seen here:

% intensional probabilistic fact with flexible probability:
P::pack(Item) :- weight(Item,Weight),  P is 1.0/Weight.

But one might need something either to create
siamese or to separate siamese, depending on what
the default modus operandi of the probabilistic

logic programming language is.

Mild Shock schrieb:
> I have retracted those posts, that had Python-first
> in it, not sure whether my analysis about some projects
> was water thight. I only made the Python example as to
> illustrate the idea of
> 
> a variation point. I do not think programming language
> trench wars are good idea, and one should put software
> engineering -first, as an abstract computer science
> discipline. Not doing so
> 
> is only a distraction from the real issues at hand.
> Variation points where defined quite vaguely
> on purpose:
> 
>  > Ivar Jacobson defines a variation point as follows:
>  > A variation point identifies one or more locations at
>  > which the variation will occur.
> 
> Variation points can come in many shades, and for
> example ProbLog based approaches take the viewpoint
> of a Prolog text with a lot of configuration flags
> and predicate
> 
> annotations. This is quite different from the
> autoencoder or transformer component approach I
> suggested here. In particular component oriented
> approach could be
> 
> more flexible and dynamic, when they allow programmatic
> configuration of components. The drawback is you cannot
> understand what the program does by looking at a
> 
> simply structured Prolog text. Although I expected
> the situation is not that bad, and one could do
> something similar to a table/1 directive, i.e. some
> directive that says
> 
> look, this predicate is an autoencoder or transformer:
> 
>  > One idea I had was that autoencoders would become
>  > kind of invisible, and work under the hood to compress
>  > Prolog facts. Take these facts:
>  >
>  > % standard _, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
>  > data(seg7, [0,0,0,0,0,0,0], [0,0,0,0,0,0,0]).
> 
> So to instruct the Prolog system to do what is sketched,
> one would possibly need a new directive autoencoder/1:
> 
> :- autoencoder data/3.
> 
> Mild Shock schrieb:
>> Hi,
>>
>> A software engineering analyis why Prolog fails
>> ================================================
>>
>> You would also get more done, if Prolog had some
>> well design plug and play machine learning libraries.
>> Currently most SWI Prolog packages are just GitHub dumps:
>>
>> (Python) Problem ---> import solver ---> Solution
>>
>> (SWI) Problem ---> install pack ---> Problem
>>
>> Python shows more success in the practitioners domain,
>> since it has more libraries that have made the test of
>> time of practial use. Whereas Prolog is still in its
>> infancy in many domains,
>>
>> you don’t arrive at the same level of convenience and
>> breadth as Python, if you have only fire and forget dumps
>> offered, from some PhD projects where software engineering
>> is secondary.
>>
>> I don’t know exactly why Prolog has so much problems
>> with software engineering. Python has object orientation,
>> but Logtalk didn’t make the situation better. SWI-Prolog
>> has modules, but they are never used. For example this
>>
>> here is a big monolith:
>>
>> This module performs learning over Logic Programs
>> https://github.com/friguzzi/liftcover/blob/main/prolog/liftcover.pl
>>
>> Its more designed towards providing some command line
>> control. But if you look into it, it has EM algorithms
>> and gradient algorithm, and who knows what. These building
>> blocks are not exposed,
>>
>> not made towards reused or towards improvement by
>> switching in 3rd party alternatives. Mostlikely a design
>> flaw inside the pack mechanism itself, since it assumes a
>> single main module?
>>
>> So the pack mechanism works, if a unit pack imports a
>> clp(BNR) pack, since it uses the single entry of clp(BNR).
>> But it is never on paar with the richness of Python packages,
>> which have more a hierarchical structure of many
>>
>> many modules in their packs.
>>
>> Mild Shock schrieb:
>>>
>>> Inductive logic programming at 30
>>> https://arxiv.org/abs/2102.10556
>>>
>>> The paper contains not a single reference to autoencoders!
>>> Still they show this example:
>>>
>>> Fig. 1 ILP systems struggle with structured examples that
>>> exhibit observational noise. All three examples clearly
>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>> shifted and elongated letters. If we would be to learn a
>>> program that simply draws "ILP" in the middle of the picture,
>>> without noisy pixels and elongated letters, that would
>>> be a correct program.
>>>
>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>> turned into transformer was already reported here (*):
>>>
>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
>>>
>>> Well ILP might have its merits, maybe we should not ask
>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>> But its tricky, I am still trying to decode the da Vinci code of
>>>
>>> things like stacked tensors, are they related to k-literal clauses?
>>> The paper I referenced is found in this excellent video:
>>>
>>> The Making of ChatGPT (35 Year History)
>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>
>>
> 

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

#14573 — No Coders completely Brain Dead (Was: Prolog totally missed the AI Boom)

Concerning library(portray_text) which is in limbo:

 > Libraries are (often) written for either
and thus the libraries make the choice.

But who writes these libraries? The SWI Prolog
community. And who doesn’t improve these libraries,
instead floods the web with workaround tips?
The SWI Prolog community.

Conclusion the SWI-Prolog community has itself
trapped in an ancient status quo, creating an island.
Cannot improve its own tooling, is not willing
to support code from else where that uses chars.

Same with the missed AI Boom.

(*) Code from elsewhere is dangerous, People
might use other Prolog systems than only SWI-Prolog,
like for exampe Trealla Prolog and Scryer Prolog.

(**) Keeping the status quo is comfy. No need to
think in terms of programm code. Its like biology
teachers versus pathology staff, biology teachers
do not everyday see opened corpses.


Mild Shock schrieb:
> 
> Inductive logic programming at 30
> https://arxiv.org/abs/2102.10556
> 
> The paper contains not a single reference to autoencoders!
> Still they show this example:
> 
> Fig. 1 ILP systems struggle with structured examples that
> exhibit observational noise. All three examples clearly
> spell the word "ILP", with some alterations: 3 noisy pixels,
> shifted and elongated letters. If we would be to learn a
> program that simply draws "ILP" in the middle of the picture,
> without noisy pixels and elongated letters, that would
> be a correct program.
> 
> I guess ILP is 30 years behind the AI boom. An early autoencoder
> turned into transformer was already reported here (*):
> 
> SERIAL ORDER, Michael I. Jordan - May 1986
> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
> 
> Well ILP might have its merits, maybe we should not ask
> for a marriage of LLM and Prolog, but Autoencoders and ILP.
> But its tricky, I am still trying to decode the da Vinci code of
> 
> things like stacked tensors, are they related to k-literal clauses?
> The paper I referenced is found in this excellent video:
> 
> The Making of ChatGPT (35 Year History)
> https://www.youtube.com/watch?v=OFS90-FX6pg
> 

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

#14574 — Unicode and atom length=1 (Was: No Coders completely Brain Dead)

Technically SWI-Prolog doesn't prefer codes.
Library `library(pure_input)` might prefer codes.
But this is again an issue of improving the
library by some non existent SWI-Prolog community.

The ISO core standard is silent about a flag
back_quotes, but has a lot of API requirements
that support both codes and chars, for example it
requires atom_codes/2 and atom_chars/2.

Implementation wise there can be an issue,
like one might decide to implement the atoms
of length=1 more efficiently, since with Unicode
there is now an explosion.

Not sure whether Trealla Prolog and Scryer
Prolog thought about this problem, that the
atom table gets quite large. Whereas codes don't
eat the atom table. Maybe they forbit predicates

that have an atom of length=1 head:

h(X) :-
     write('Hello '), write(X), write('!'), nl.

Does this still work?

Mild Shock schrieb:
> Concerning library(portray_text) which is in limbo:
> 
>  > Libraries are (often) written for either
> and thus the libraries make the choice.
> 
> But who writes these libraries? The SWI Prolog
> community. And who doesn’t improve these libraries,
> instead floods the web with workaround tips?
> The SWI Prolog community.
> 
> Conclusion the SWI-Prolog community has itself
> trapped in an ancient status quo, creating an island.
> Cannot improve its own tooling, is not willing
> to support code from else where that uses chars.
> 
> Same with the missed AI Boom.
> 
> (*) Code from elsewhere is dangerous, People
> might use other Prolog systems than only SWI-Prolog,
> like for exampe Trealla Prolog and Scryer Prolog.
> 
> (**) Keeping the status quo is comfy. No need to
> think in terms of programm code. Its like biology
> teachers versus pathology staff, biology teachers
> do not everyday see opened corpses.
> 
> 
> Mild Shock schrieb:
>>
>> Inductive logic programming at 30
>> https://arxiv.org/abs/2102.10556
>>
>> The paper contains not a single reference to autoencoders!
>> Still they show this example:
>>
>> Fig. 1 ILP systems struggle with structured examples that
>> exhibit observational noise. All three examples clearly
>> spell the word "ILP", with some alterations: 3 noisy pixels,
>> shifted and elongated letters. If we would be to learn a
>> program that simply draws "ILP" in the middle of the picture,
>> without noisy pixels and elongated letters, that would
>> be a correct program.
>>
>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>> turned into transformer was already reported here (*):
>>
>> SERIAL ORDER, Michael I. Jordan - May 1986
>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
>>
>> Well ILP might have its merits, maybe we should not ask
>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>> But its tricky, I am still trying to decode the da Vinci code of
>>
>> things like stacked tensors, are they related to k-literal clauses?
>> The paper I referenced is found in this excellent video:
>>
>> The Making of ChatGPT (35 Year History)
>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>
> 

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

#14575 — Most radical approach is Novacore from Dogelog Player (Was: Unicode and atom length=1)

Hi,

The most radical approach is Novacore from
Dogelog Player. It consists of the following
major incisions in the ISO core standard:

- We do not forbid chars, like for example
   using lists of the form [a,b,c], we also
   provide char_code/2 predicate bidirectionally.

- We do not provide and _chars built-in
   predicates also there is nothing _strings. The
   Prolog system is clever enough to not put
   every atom it sees in an atom table. There
   is only a predicate table.

- Some host languages have garbage collection that
   deduplicates Strings. For example some Java
   versions have an options to do that. But we
   do not have any efforts to deduplicate atoms,
   which are simply plain strings.

- Some languages have constant pools. For example
   the Java byte code format includes a constant
   pool in every class header. We do not do that
   during transpilation , but we could of course.
   But it begs the question, why only deduplicate
   strings and not other constant expressions as well?

- We are totally happy that we have only codes,
   there are chances that the host languages use
   tagged pointers to represent them. So they
   are represented similar to the tagged pointers
   in SWI-Prolog which works for small integers.

- But the tagged pointer argument is moot,
   since atom length=1 entities can be also
   represented as tagged pointers, and some
   programming languages do that. Dogelog Player
   would use such tagged pointers without
   poluting the atom table.

- What else?

Bye

Mild Shock schrieb:
> 
> Technically SWI-Prolog doesn't prefer codes.
> Library `library(pure_input)` might prefer codes.
> But this is again an issue of improving the
> library by some non existent SWI-Prolog community.
> 
> The ISO core standard is silent about a flag
> back_quotes, but has a lot of API requirements
> that support both codes and chars, for example it
> requires atom_codes/2 and atom_chars/2.
> 
> Implementation wise there can be an issue,
> like one might decide to implement the atoms
> of length=1 more efficiently, since with Unicode
> there is now an explosion.
> 
> Not sure whether Trealla Prolog and Scryer
> Prolog thought about this problem, that the
> atom table gets quite large. Whereas codes don't
> eat the atom table. Maybe they forbit predicates
> 
> that have an atom of length=1 head:
> 
> h(X) :-
>      write('Hello '), write(X), write('!'), nl.
> 
> Does this still work?
> 
> Mild Shock schrieb:
>> Concerning library(portray_text) which is in limbo:
>>
>>  > Libraries are (often) written for either
>> and thus the libraries make the choice.
>>
>> But who writes these libraries? The SWI Prolog
>> community. And who doesn’t improve these libraries,
>> instead floods the web with workaround tips?
>> The SWI Prolog community.
>>
>> Conclusion the SWI-Prolog community has itself
>> trapped in an ancient status quo, creating an island.
>> Cannot improve its own tooling, is not willing
>> to support code from else where that uses chars.
>>
>> Same with the missed AI Boom.
>>
>> (*) Code from elsewhere is dangerous, People
>> might use other Prolog systems than only SWI-Prolog,
>> like for exampe Trealla Prolog and Scryer Prolog.
>>
>> (**) Keeping the status quo is comfy. No need to
>> think in terms of programm code. Its like biology
>> teachers versus pathology staff, biology teachers
>> do not everyday see opened corpses.
>>
>>
>> Mild Shock schrieb:
>>>
>>> Inductive logic programming at 30
>>> https://arxiv.org/abs/2102.10556
>>>
>>> The paper contains not a single reference to autoencoders!
>>> Still they show this example:
>>>
>>> Fig. 1 ILP systems struggle with structured examples that
>>> exhibit observational noise. All three examples clearly
>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>> shifted and elongated letters. If we would be to learn a
>>> program that simply draws "ILP" in the middle of the picture,
>>> without noisy pixels and elongated letters, that would
>>> be a correct program.
>>>
>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>> turned into transformer was already reported here (*):
>>>
>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
>>>
>>> Well ILP might have its merits, maybe we should not ask
>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>> But its tricky, I am still trying to decode the da Vinci code of
>>>
>>> things like stacked tensors, are they related to k-literal clauses?
>>> The paper I referenced is found in this excellent video:
>>>
>>> The Making of ChatGPT (35 Year History)
>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>
>>
> 

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

#14576 — SWI-Prolog master not wide awake, doing day-sleeping (Was: Most radical approach is Novacore from Dogelog Player)

Hi,

Even the SWI-Prolog master not wide awake,
doing day-sleeping.

 > I don’t know whether they realised that you
 > cannot meaningfully support both in the same
 > system and surely not in the same application.

Maybe you didn’t notice this nifty detail.
Thats all you need:

 > The ISO core standard is silent about a flag back_quotes

 > Its more a naming problem. Have two libraries
library(portray_codes) and library(portray_chars),
Or one library(portray_text).

Just add one more rule:

user:portray(Chars) :-
     portray_text_option(enabled, true),
     '$skip_list'(Length, Chars, _Tail),
     portray_text_option(min_length, MinLen),
     Length >= MinLen,
     mostly_chars(Chars, 0.9),
     portray_text_option(ellipsis, IfLonger),
     quote2(C),
     put_code(C),
     maplist(char_code, Chars, Codes),
     (   Length > IfLonger
     ->  First is IfLonger - 5,
         Skip is Length - 5,
         skip_first(Skip, Codes, Rest),
         put_n_codes(First, Codes, C),
         format('...', [])
     ;   Rest = Codes
     ),
     put_var_codes(Rest, C),
     put_code(C).

The use of maplist/3 is elegant, and works since we do
not print open lists, right?

Mild Shock schrieb:
> Hi,
> 
> The most radical approach is Novacore from
> Dogelog Player. It consists of the following
> major incisions in the ISO core standard:
> 
> - We do not forbid chars, like for example
>    using lists of the form [a,b,c], we also
>    provide char_code/2 predicate bidirectionally.
> 
> - We do not provide and _chars built-in
>    predicates also there is nothing _strings. The
>    Prolog system is clever enough to not put
>    every atom it sees in an atom table. There
>    is only a predicate table.
> 
> - Some host languages have garbage collection that
>    deduplicates Strings. For example some Java
>    versions have an options to do that. But we
>    do not have any efforts to deduplicate atoms,
>    which are simply plain strings.
> 
> - Some languages have constant pools. For example
>    the Java byte code format includes a constant
>    pool in every class header. We do not do that
>    during transpilation , but we could of course.
>    But it begs the question, why only deduplicate
>    strings and not other constant expressions as well?
> 
> - We are totally happy that we have only codes,
>    there are chances that the host languages use
>    tagged pointers to represent them. So they
>    are represented similar to the tagged pointers
>    in SWI-Prolog which works for small integers.
> 
> - But the tagged pointer argument is moot,
>    since atom length=1 entities can be also
>    represented as tagged pointers, and some
>    programming languages do that. Dogelog Player
>    would use such tagged pointers without
>    poluting the atom table.
> 
> - What else?
> 
> Bye
> 
> Mild Shock schrieb:
>>
>> Technically SWI-Prolog doesn't prefer codes.
>> Library `library(pure_input)` might prefer codes.
>> But this is again an issue of improving the
>> library by some non existent SWI-Prolog community.
>>
>> The ISO core standard is silent about a flag
>> back_quotes, but has a lot of API requirements
>> that support both codes and chars, for example it
>> requires atom_codes/2 and atom_chars/2.
>>
>> Implementation wise there can be an issue,
>> like one might decide to implement the atoms
>> of length=1 more efficiently, since with Unicode
>> there is now an explosion.
>>
>> Not sure whether Trealla Prolog and Scryer
>> Prolog thought about this problem, that the
>> atom table gets quite large. Whereas codes don't
>> eat the atom table. Maybe they forbit predicates
>>
>> that have an atom of length=1 head:
>>
>> h(X) :-
>>      write('Hello '), write(X), write('!'), nl.
>>
>> Does this still work?
>>
>> Mild Shock schrieb:
>>> Concerning library(portray_text) which is in limbo:
>>>
>>>  > Libraries are (often) written for either
>>> and thus the libraries make the choice.
>>>
>>> But who writes these libraries? The SWI Prolog
>>> community. And who doesn’t improve these libraries,
>>> instead floods the web with workaround tips?
>>> The SWI Prolog community.
>>>
>>> Conclusion the SWI-Prolog community has itself
>>> trapped in an ancient status quo, creating an island.
>>> Cannot improve its own tooling, is not willing
>>> to support code from else where that uses chars.
>>>
>>> Same with the missed AI Boom.
>>>
>>> (*) Code from elsewhere is dangerous, People
>>> might use other Prolog systems than only SWI-Prolog,
>>> like for exampe Trealla Prolog and Scryer Prolog.
>>>
>>> (**) Keeping the status quo is comfy. No need to
>>> think in terms of programm code. Its like biology
>>> teachers versus pathology staff, biology teachers
>>> do not everyday see opened corpses.
>>>
>>>
>>> Mild Shock schrieb:
>>>>
>>>> Inductive logic programming at 30
>>>> https://arxiv.org/abs/2102.10556
>>>>
>>>> The paper contains not a single reference to autoencoders!
>>>> Still they show this example:
>>>>
>>>> Fig. 1 ILP systems struggle with structured examples that
>>>> exhibit observational noise. All three examples clearly
>>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>>> shifted and elongated letters. If we would be to learn a
>>>> program that simply draws "ILP" in the middle of the picture,
>>>> without noisy pixels and elongated letters, that would
>>>> be a correct program.
>>>>
>>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>>> turned into transformer was already reported here (*):
>>>>
>>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf 
>>>>
>>>>
>>>> Well ILP might have its merits, maybe we should not ask
>>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>>> But its tricky, I am still trying to decode the da Vinci code of
>>>>
>>>> things like stacked tensors, are they related to k-literal clauses?
>>>> The paper I referenced is found in this excellent video:
>>>>
>>>> The Making of ChatGPT (35 Year History)
>>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>>
>>>
>>
> 

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

#14577 — Re: SWI-Prolog master not wide awake, doing day-sleeping (Was: Most radical approach is Novacore from Dogelog Player)

Since it has a double hook, works fine simultaneously:

?- set_portray_text(enabled, false).
true.

?- X = [a,b,c].
X = [a, b, c].

?- X = [0'a,0'b,0'c].
X = [97, 98, 99].

And then:

?- set_prolog_flag(double_quotes, codes).
true.

?- set_prolog_flag(back_quotes, chars).
true.

?- set_portray_text(enabled, true).
true.

?- X = [a,b,c].
X = `abc`.

?- X = [0'a,0'b,0'c].
X = "abc".

Mild Shock schrieb:
> Hi,
> 
> Even the SWI-Prolog master not wide awake,
> doing day-sleeping.
> 
>  > I don’t know whether they realised that you
>  > cannot meaningfully support both in the same
>  > system and surely not in the same application.
> 
> Maybe you didn’t notice this nifty detail.
> Thats all you need:
> 
>  > The ISO core standard is silent about a flag back_quotes
> 
>  > Its more a naming problem. Have two libraries
> library(portray_codes) and library(portray_chars),
> Or one library(portray_text).
> 
> Just add one more rule:
> 
> user:portray(Chars) :-
>      portray_text_option(enabled, true),
>      '$skip_list'(Length, Chars, _Tail),
>      portray_text_option(min_length, MinLen),
>      Length >= MinLen,
>      mostly_chars(Chars, 0.9),
>      portray_text_option(ellipsis, IfLonger),
>      quote2(C),
>      put_code(C),
>      maplist(char_code, Chars, Codes),
>      (   Length > IfLonger
>      ->  First is IfLonger - 5,
>          Skip is Length - 5,
>          skip_first(Skip, Codes, Rest),
>          put_n_codes(First, Codes, C),
>          format('...', [])
>      ;   Rest = Codes
>      ),
>      put_var_codes(Rest, C),
>      put_code(C).
> 
> The use of maplist/3 is elegant, and works since we do
> not print open lists, right?
> 
> Mild Shock schrieb:
>> Hi,
>>
>> The most radical approach is Novacore from
>> Dogelog Player. It consists of the following
>> major incisions in the ISO core standard:
>>
>> - We do not forbid chars, like for example
>>    using lists of the form [a,b,c], we also
>>    provide char_code/2 predicate bidirectionally.
>>
>> - We do not provide and _chars built-in
>>    predicates also there is nothing _strings. The
>>    Prolog system is clever enough to not put
>>    every atom it sees in an atom table. There
>>    is only a predicate table.
>>
>> - Some host languages have garbage collection that
>>    deduplicates Strings. For example some Java
>>    versions have an options to do that. But we
>>    do not have any efforts to deduplicate atoms,
>>    which are simply plain strings.
>>
>> - Some languages have constant pools. For example
>>    the Java byte code format includes a constant
>>    pool in every class header. We do not do that
>>    during transpilation , but we could of course.
>>    But it begs the question, why only deduplicate
>>    strings and not other constant expressions as well?
>>
>> - We are totally happy that we have only codes,
>>    there are chances that the host languages use
>>    tagged pointers to represent them. So they
>>    are represented similar to the tagged pointers
>>    in SWI-Prolog which works for small integers.
>>
>> - But the tagged pointer argument is moot,
>>    since atom length=1 entities can be also
>>    represented as tagged pointers, and some
>>    programming languages do that. Dogelog Player
>>    would use such tagged pointers without
>>    poluting the atom table.
>>
>> - What else?
>>
>> Bye
>>
>> Mild Shock schrieb:
>>>
>>> Technically SWI-Prolog doesn't prefer codes.
>>> Library `library(pure_input)` might prefer codes.
>>> But this is again an issue of improving the
>>> library by some non existent SWI-Prolog community.
>>>
>>> The ISO core standard is silent about a flag
>>> back_quotes, but has a lot of API requirements
>>> that support both codes and chars, for example it
>>> requires atom_codes/2 and atom_chars/2.
>>>
>>> Implementation wise there can be an issue,
>>> like one might decide to implement the atoms
>>> of length=1 more efficiently, since with Unicode
>>> there is now an explosion.
>>>
>>> Not sure whether Trealla Prolog and Scryer
>>> Prolog thought about this problem, that the
>>> atom table gets quite large. Whereas codes don't
>>> eat the atom table. Maybe they forbit predicates
>>>
>>> that have an atom of length=1 head:
>>>
>>> h(X) :-
>>>      write('Hello '), write(X), write('!'), nl.
>>>
>>> Does this still work?
>>>
>>> Mild Shock schrieb:
>>>> Concerning library(portray_text) which is in limbo:
>>>>
>>>>  > Libraries are (often) written for either
>>>> and thus the libraries make the choice.
>>>>
>>>> But who writes these libraries? The SWI Prolog
>>>> community. And who doesn’t improve these libraries,
>>>> instead floods the web with workaround tips?
>>>> The SWI Prolog community.
>>>>
>>>> Conclusion the SWI-Prolog community has itself
>>>> trapped in an ancient status quo, creating an island.
>>>> Cannot improve its own tooling, is not willing
>>>> to support code from else where that uses chars.
>>>>
>>>> Same with the missed AI Boom.
>>>>
>>>> (*) Code from elsewhere is dangerous, People
>>>> might use other Prolog systems than only SWI-Prolog,
>>>> like for exampe Trealla Prolog and Scryer Prolog.
>>>>
>>>> (**) Keeping the status quo is comfy. No need to
>>>> think in terms of programm code. Its like biology
>>>> teachers versus pathology staff, biology teachers
>>>> do not everyday see opened corpses.
>>>>
>>>>
>>>> Mild Shock schrieb:
>>>>>
>>>>> Inductive logic programming at 30
>>>>> https://arxiv.org/abs/2102.10556
>>>>>
>>>>> The paper contains not a single reference to autoencoders!
>>>>> Still they show this example:
>>>>>
>>>>> Fig. 1 ILP systems struggle with structured examples that
>>>>> exhibit observational noise. All three examples clearly
>>>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>>>> shifted and elongated letters. If we would be to learn a
>>>>> program that simply draws "ILP" in the middle of the picture,
>>>>> without noisy pixels and elongated letters, that would
>>>>> be a correct program.
>>>>>
>>>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>>>> turned into transformer was already reported here (*):
>>>>>
>>>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf 
>>>>>
>>>>>
>>>>> Well ILP might have its merits, maybe we should not ask
>>>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>>>> But its tricky, I am still trying to decode the da Vinci code of
>>>>>
>>>>> things like stacked tensors, are they related to k-literal clauses?
>>>>> The paper I referenced is found in this excellent video:
>>>>>
>>>>> The Making of ChatGPT (35 Year History)
>>>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>>>
>>>>
>>>
>>
> 

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

#14578 — The beauty of a double hook (Was: SWI-Prolog master not wide awake, doing day-sleeping)

Since it has a double hook, works fine simultaneously:

?- set_portray_text(enabled, false).
true.

?- X = [a,b,c].
X = [a, b, c].

?- X = [0'a,0'b,0'c].
X = [97, 98, 99].

And then:

?- set_prolog_flag(double_quotes, codes).
true.

?- set_prolog_flag(back_quotes, chars).
true.

?- set_portray_text(enabled, true).
true.

?- X = [a,b,c].
X = `abc`.

?- X = [0'a,0'b,0'c].
X = "abc".

Mild Shock schrieb:
> Hi,
> 
> Even the SWI-Prolog master not wide awake,
> doing day-sleeping.
> 
>  > I don’t know whether they realised that you
>  > cannot meaningfully support both in the same
>  > system and surely not in the same application.
> 
> Maybe you didn’t notice this nifty detail.
> Thats all you need:
> 
>  > The ISO core standard is silent about a flag back_quotes
> 
>  > Its more a naming problem. Have two libraries
> library(portray_codes) and library(portray_chars),
> Or one library(portray_text).
> 
> Just add one more rule:
> 
> user:portray(Chars) :-
>      portray_text_option(enabled, true),
>      '$skip_list'(Length, Chars, _Tail),
>      portray_text_option(min_length, MinLen),
>      Length >= MinLen,
>      mostly_chars(Chars, 0.9),
>      portray_text_option(ellipsis, IfLonger),
>      quote2(C),
>      put_code(C),
>      maplist(char_code, Chars, Codes),
>      (   Length > IfLonger
>      ->  First is IfLonger - 5,
>          Skip is Length - 5,
>          skip_first(Skip, Codes, Rest),
>          put_n_codes(First, Codes, C),
>          format('...', [])
>      ;   Rest = Codes
>      ),
>      put_var_codes(Rest, C),
>      put_code(C).
> 
> The use of maplist/3 is elegant, and works since we do
> not print open lists, right?
> 
> Mild Shock schrieb:
>> Hi,
>>
>> The most radical approach is Novacore from
>> Dogelog Player. It consists of the following
>> major incisions in the ISO core standard:
>>
>> - We do not forbid chars, like for example
>>    using lists of the form [a,b,c], we also
>>    provide char_code/2 predicate bidirectionally.
>>
>> - We do not provide and _chars built-in
>>    predicates also there is nothing _strings. The
>>    Prolog system is clever enough to not put
>>    every atom it sees in an atom table. There
>>    is only a predicate table.
>>
>> - Some host languages have garbage collection that
>>    deduplicates Strings. For example some Java
>>    versions have an options to do that. But we
>>    do not have any efforts to deduplicate atoms,
>>    which are simply plain strings.
>>
>> - Some languages have constant pools. For example
>>    the Java byte code format includes a constant
>>    pool in every class header. We do not do that
>>    during transpilation , but we could of course.
>>    But it begs the question, why only deduplicate
>>    strings and not other constant expressions as well?
>>
>> - We are totally happy that we have only codes,
>>    there are chances that the host languages use
>>    tagged pointers to represent them. So they
>>    are represented similar to the tagged pointers
>>    in SWI-Prolog which works for small integers.
>>
>> - But the tagged pointer argument is moot,
>>    since atom length=1 entities can be also
>>    represented as tagged pointers, and some
>>    programming languages do that. Dogelog Player
>>    would use such tagged pointers without
>>    poluting the atom table.
>>
>> - What else?
>>
>> Bye
>>
>> Mild Shock schrieb:
>>>
>>> Technically SWI-Prolog doesn't prefer codes.
>>> Library `library(pure_input)` might prefer codes.
>>> But this is again an issue of improving the
>>> library by some non existent SWI-Prolog community.
>>>
>>> The ISO core standard is silent about a flag
>>> back_quotes, but has a lot of API requirements
>>> that support both codes and chars, for example it
>>> requires atom_codes/2 and atom_chars/2.
>>>
>>> Implementation wise there can be an issue,
>>> like one might decide to implement the atoms
>>> of length=1 more efficiently, since with Unicode
>>> there is now an explosion.
>>>
>>> Not sure whether Trealla Prolog and Scryer
>>> Prolog thought about this problem, that the
>>> atom table gets quite large. Whereas codes don't
>>> eat the atom table. Maybe they forbit predicates
>>>
>>> that have an atom of length=1 head:
>>>
>>> h(X) :-
>>>      write('Hello '), write(X), write('!'), nl.
>>>
>>> Does this still work?
>>>
>>> Mild Shock schrieb:
>>>> Concerning library(portray_text) which is in limbo:
>>>>
>>>>  > Libraries are (often) written for either
>>>> and thus the libraries make the choice.
>>>>
>>>> But who writes these libraries? The SWI Prolog
>>>> community. And who doesn’t improve these libraries,
>>>> instead floods the web with workaround tips?
>>>> The SWI Prolog community.
>>>>
>>>> Conclusion the SWI-Prolog community has itself
>>>> trapped in an ancient status quo, creating an island.
>>>> Cannot improve its own tooling, is not willing
>>>> to support code from else where that uses chars.
>>>>
>>>> Same with the missed AI Boom.
>>>>
>>>> (*) Code from elsewhere is dangerous, People
>>>> might use other Prolog systems than only SWI-Prolog,
>>>> like for exampe Trealla Prolog and Scryer Prolog.
>>>>
>>>> (**) Keeping the status quo is comfy. No need to
>>>> think in terms of programm code. Its like biology
>>>> teachers versus pathology staff, biology teachers
>>>> do not everyday see opened corpses.
>>>>
>>>>
>>>> Mild Shock schrieb:
>>>>>
>>>>> Inductive logic programming at 30
>>>>> https://arxiv.org/abs/2102.10556
>>>>>
>>>>> The paper contains not a single reference to autoencoders!
>>>>> Still they show this example:
>>>>>
>>>>> Fig. 1 ILP systems struggle with structured examples that
>>>>> exhibit observational noise. All three examples clearly
>>>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>>>> shifted and elongated letters. If we would be to learn a
>>>>> program that simply draws "ILP" in the middle of the picture,
>>>>> without noisy pixels and elongated letters, that would
>>>>> be a correct program.
>>>>>
>>>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>>>> turned into transformer was already reported here (*):
>>>>>
>>>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf 
>>>>>
>>>>>
>>>>> Well ILP might have its merits, maybe we should not ask
>>>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>>>> But its tricky, I am still trying to decode the da Vinci code of
>>>>>
>>>>> things like stacked tensors, are they related to k-literal clauses?
>>>>> The paper I referenced is found in this excellent video:
>>>>>
>>>>> The Making of ChatGPT (35 Year History)
>>>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>>>
>>>>
>>>
>>
> 

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

#14579 — The beauty of a dual use hook (Was: SWI-Prolog master not wide awake, doing day-sleeping)

Full source code here:

swi2.pl.log
https://github.com/SWI-Prolog/swipl-devel/issues/1373#issuecomment-2997214639

Since it has a dual use hook, works fine simultaneously:

?- set_portray_text(enabled, false).
true.

?- X = [a,b,c].
X = [a, b, c].

?- X = [0'a,0'b,0'c].
X = [97, 98, 99].

And then:

?- set_prolog_flag(double_quotes, codes).
true.

?- set_prolog_flag(back_quotes, chars).
true.

?- set_portray_text(enabled, true).
true.

?- X = [a,b,c].
X = `abc`.

?- X = [0'a,0'b,0'c].
X = "abc".

Mild Shock schrieb:
> Hi,
> 
> Even the SWI-Prolog master not wide awake,
> doing day-sleeping.
> 
>  > I don’t know whether they realised that you
>  > cannot meaningfully support both in the same
>  > system and surely not in the same application.
> 
> Maybe you didn’t notice this nifty detail.
> Thats all you need:
> 
>  > The ISO core standard is silent about a flag back_quotes
> 
>  > Its more a naming problem. Have two libraries
> library(portray_codes) and library(portray_chars),
> Or one library(portray_text).
> 
> Just add one more rule:
> 
> user:portray(Chars) :-
>      portray_text_option(enabled, true),
>      '$skip_list'(Length, Chars, _Tail),
>      portray_text_option(min_length, MinLen),
>      Length >= MinLen,
>      mostly_chars(Chars, 0.9),
>      portray_text_option(ellipsis, IfLonger),
>      quote2(C),
>      put_code(C),
>      maplist(char_code, Chars, Codes),
>      (   Length > IfLonger
>      ->  First is IfLonger - 5,
>          Skip is Length - 5,
>          skip_first(Skip, Codes, Rest),
>          put_n_codes(First, Codes, C),
>          format('...', [])
>      ;   Rest = Codes
>      ),
>      put_var_codes(Rest, C),
>      put_code(C).
> 
> The use of maplist/3 is elegant, and works since we do
> not print open lists, right?
> 
> Mild Shock schrieb:
>> Hi,
>>
>> The most radical approach is Novacore from
>> Dogelog Player. It consists of the following
>> major incisions in the ISO core standard:
>>
>> - We do not forbid chars, like for example
>>    using lists of the form [a,b,c], we also
>>    provide char_code/2 predicate bidirectionally.
>>
>> - We do not provide and _chars built-in
>>    predicates also there is nothing _strings. The
>>    Prolog system is clever enough to not put
>>    every atom it sees in an atom table. There
>>    is only a predicate table.
>>
>> - Some host languages have garbage collection that
>>    deduplicates Strings. For example some Java
>>    versions have an options to do that. But we
>>    do not have any efforts to deduplicate atoms,
>>    which are simply plain strings.
>>
>> - Some languages have constant pools. For example
>>    the Java byte code format includes a constant
>>    pool in every class header. We do not do that
>>    during transpilation , but we could of course.
>>    But it begs the question, why only deduplicate
>>    strings and not other constant expressions as well?
>>
>> - We are totally happy that we have only codes,
>>    there are chances that the host languages use
>>    tagged pointers to represent them. So they
>>    are represented similar to the tagged pointers
>>    in SWI-Prolog which works for small integers.
>>
>> - But the tagged pointer argument is moot,
>>    since atom length=1 entities can be also
>>    represented as tagged pointers, and some
>>    programming languages do that. Dogelog Player
>>    would use such tagged pointers without
>>    poluting the atom table.
>>
>> - What else?
>>
>> Bye
>>
>> Mild Shock schrieb:
>>>
>>> Technically SWI-Prolog doesn't prefer codes.
>>> Library `library(pure_input)` might prefer codes.
>>> But this is again an issue of improving the
>>> library by some non existent SWI-Prolog community.
>>>
>>> The ISO core standard is silent about a flag
>>> back_quotes, but has a lot of API requirements
>>> that support both codes and chars, for example it
>>> requires atom_codes/2 and atom_chars/2.
>>>
>>> Implementation wise there can be an issue,
>>> like one might decide to implement the atoms
>>> of length=1 more efficiently, since with Unicode
>>> there is now an explosion.
>>>
>>> Not sure whether Trealla Prolog and Scryer
>>> Prolog thought about this problem, that the
>>> atom table gets quite large. Whereas codes don't
>>> eat the atom table. Maybe they forbit predicates
>>>
>>> that have an atom of length=1 head:
>>>
>>> h(X) :-
>>>      write('Hello '), write(X), write('!'), nl.
>>>
>>> Does this still work?
>>>
>>> Mild Shock schrieb:
>>>> Concerning library(portray_text) which is in limbo:
>>>>
>>>>  > Libraries are (often) written for either
>>>> and thus the libraries make the choice.
>>>>
>>>> But who writes these libraries? The SWI Prolog
>>>> community. And who doesn’t improve these libraries,
>>>> instead floods the web with workaround tips?
>>>> The SWI Prolog community.
>>>>
>>>> Conclusion the SWI-Prolog community has itself
>>>> trapped in an ancient status quo, creating an island.
>>>> Cannot improve its own tooling, is not willing
>>>> to support code from else where that uses chars.
>>>>
>>>> Same with the missed AI Boom.
>>>>
>>>> (*) Code from elsewhere is dangerous, People
>>>> might use other Prolog systems than only SWI-Prolog,
>>>> like for exampe Trealla Prolog and Scryer Prolog.
>>>>
>>>> (**) Keeping the status quo is comfy. No need to
>>>> think in terms of programm code. Its like biology
>>>> teachers versus pathology staff, biology teachers
>>>> do not everyday see opened corpses.
>>>>
>>>>
>>>> Mild Shock schrieb:
>>>>>
>>>>> Inductive logic programming at 30
>>>>> https://arxiv.org/abs/2102.10556
>>>>>
>>>>> The paper contains not a single reference to autoencoders!
>>>>> Still they show this example:
>>>>>
>>>>> Fig. 1 ILP systems struggle with structured examples that
>>>>> exhibit observational noise. All three examples clearly
>>>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>>>> shifted and elongated letters. If we would be to learn a
>>>>> program that simply draws "ILP" in the middle of the picture,
>>>>> without noisy pixels and elongated letters, that would
>>>>> be a correct program.
>>>>>
>>>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>>>> turned into transformer was already reported here (*):
>>>>>
>>>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf 
>>>>>
>>>>>
>>>>> Well ILP might have its merits, maybe we should not ask
>>>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>>>> But its tricky, I am still trying to decode the da Vinci code of
>>>>>
>>>>> things like stacked tensors, are they related to k-literal clauses?
>>>>> The paper I referenced is found in this excellent video:
>>>>>
>>>>> The Making of ChatGPT (35 Year History)
>>>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>>>
>>>>
>>>
>>
> 

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

#14580 — maplist(char_code, Chars, Codes) is bidirectional (Was: The beauty of a dual use hook)

Using again my super powered library(portray_text):

?- set_prolog_flag(double_quotes, codes).
true.

?- set_prolog_flag(back_quotes, chars).
true.

?- set_portray_text(enabled, true).
true.

?- maplist(char_code, `abc`, X).
X = "abc".

?- maplist(char_code, X, "abc").
X = `abc`.

So if you have a Prolog system that has chars, you
could bootstrap as follows:

atom_codes(X, Y) :-
   var(X), !,
   atom_chars(Z, Y),
   maplist(char_code, X, Z).
atom_codes(X, Y) :-
   atom_chars(X, Z),
   maplist(char_code, Z, Y).

Or if you have a Prolog system that has codes, you
could bootstrap as follows:

atom_chars(X, Y) :-
   var(X), !,
   atom_codes(Z, Y),
   maplist(char_code, Z, X).
atom_chars(X, Y) :-
   atom_codes(X, Z),
   maplist(char_code, Y, Z).

Mild Shock schrieb:
> Full source code here:
> 
> swi2.pl.log
> https://github.com/SWI-Prolog/swipl-devel/issues/1373#issuecomment-2997214639 
> 
> 
> Since it has a dual use hook, works fine simultaneously:
> 
> ?- set_portray_text(enabled, false).
> true.
> 
> ?- X = [a,b,c].
> X = [a, b, c].
> 
> ?- X = [0'a,0'b,0'c].
> X = [97, 98, 99].
> 
> And then:
> 
> ?- set_prolog_flag(double_quotes, codes).
> true.
> 
> ?- set_prolog_flag(back_quotes, chars).
> true.
> 
> ?- set_portray_text(enabled, true).
> true.
> 
> ?- X = [a,b,c].
> X = `abc`.
> 
> ?- X = [0'a,0'b,0'c].
> X = "abc".
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Even the SWI-Prolog master not wide awake,
>> doing day-sleeping.
>>
>>  > I don’t know whether they realised that you
>>  > cannot meaningfully support both in the same
>>  > system and surely not in the same application.
>>
>> Maybe you didn’t notice this nifty detail.
>> Thats all you need:
>>
>>  > The ISO core standard is silent about a flag back_quotes
>>
>>  > Its more a naming problem. Have two libraries
>> library(portray_codes) and library(portray_chars),
>> Or one library(portray_text).
>>
>> Just add one more rule:
>>
>> user:portray(Chars) :-
>>      portray_text_option(enabled, true),
>>      '$skip_list'(Length, Chars, _Tail),
>>      portray_text_option(min_length, MinLen),
>>      Length >= MinLen,
>>      mostly_chars(Chars, 0.9),
>>      portray_text_option(ellipsis, IfLonger),
>>      quote2(C),
>>      put_code(C),
>>      maplist(char_code, Chars, Codes),
>>      (   Length > IfLonger
>>      ->  First is IfLonger - 5,
>>          Skip is Length - 5,
>>          skip_first(Skip, Codes, Rest),
>>          put_n_codes(First, Codes, C),
>>          format('...', [])
>>      ;   Rest = Codes
>>      ),
>>      put_var_codes(Rest, C),
>>      put_code(C).
>>
>> The use of maplist/3 is elegant, and works since we do
>> not print open lists, right?
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> The most radical approach is Novacore from
>>> Dogelog Player. It consists of the following
>>> major incisions in the ISO core standard:
>>>
>>> - We do not forbid chars, like for example
>>>    using lists of the form [a,b,c], we also
>>>    provide char_code/2 predicate bidirectionally.
>>>
>>> - We do not provide and _chars built-in
>>>    predicates also there is nothing _strings. The
>>>    Prolog system is clever enough to not put
>>>    every atom it sees in an atom table. There
>>>    is only a predicate table.
>>>
>>> - Some host languages have garbage collection that
>>>    deduplicates Strings. For example some Java
>>>    versions have an options to do that. But we
>>>    do not have any efforts to deduplicate atoms,
>>>    which are simply plain strings.
>>>
>>> - Some languages have constant pools. For example
>>>    the Java byte code format includes a constant
>>>    pool in every class header. We do not do that
>>>    during transpilation , but we could of course.
>>>    But it begs the question, why only deduplicate
>>>    strings and not other constant expressions as well?
>>>
>>> - We are totally happy that we have only codes,
>>>    there are chances that the host languages use
>>>    tagged pointers to represent them. So they
>>>    are represented similar to the tagged pointers
>>>    in SWI-Prolog which works for small integers.
>>>
>>> - But the tagged pointer argument is moot,
>>>    since atom length=1 entities can be also
>>>    represented as tagged pointers, and some
>>>    programming languages do that. Dogelog Player
>>>    would use such tagged pointers without
>>>    poluting the atom table.
>>>
>>> - What else?
>>>
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>>
>>>> Technically SWI-Prolog doesn't prefer codes.
>>>> Library `library(pure_input)` might prefer codes.
>>>> But this is again an issue of improving the
>>>> library by some non existent SWI-Prolog community.
>>>>
>>>> The ISO core standard is silent about a flag
>>>> back_quotes, but has a lot of API requirements
>>>> that support both codes and chars, for example it
>>>> requires atom_codes/2 and atom_chars/2.
>>>>
>>>> Implementation wise there can be an issue,
>>>> like one might decide to implement the atoms
>>>> of length=1 more efficiently, since with Unicode
>>>> there is now an explosion.
>>>>
>>>> Not sure whether Trealla Prolog and Scryer
>>>> Prolog thought about this problem, that the
>>>> atom table gets quite large. Whereas codes don't
>>>> eat the atom table. Maybe they forbit predicates
>>>>
>>>> that have an atom of length=1 head:
>>>>
>>>> h(X) :-
>>>>      write('Hello '), write(X), write('!'), nl.
>>>>
>>>> Does this still work?
>>>>
>>>> Mild Shock schrieb:
>>>>> Concerning library(portray_text) which is in limbo:
>>>>>
>>>>>  > Libraries are (often) written for either
>>>>> and thus the libraries make the choice.
>>>>>
>>>>> But who writes these libraries? The SWI Prolog
>>>>> community. And who doesn’t improve these libraries,
>>>>> instead floods the web with workaround tips?
>>>>> The SWI Prolog community.
>>>>>
>>>>> Conclusion the SWI-Prolog community has itself
>>>>> trapped in an ancient status quo, creating an island.
>>>>> Cannot improve its own tooling, is not willing
>>>>> to support code from else where that uses chars.
>>>>>
>>>>> Same with the missed AI Boom.
>>>>>
>>>>> (*) Code from elsewhere is dangerous, People
>>>>> might use other Prolog systems than only SWI-Prolog,
>>>>> like for exampe Trealla Prolog and Scryer Prolog.
>>>>>
>>>>> (**) Keeping the status quo is comfy. No need to
>>>>> think in terms of programm code. Its like biology
>>>>> teachers versus pathology staff, biology teachers
>>>>> do not everyday see opened corpses.
>>>>>
>>>>>
>>>>> Mild Shock schrieb:
>>>>>>
>>>>>> Inductive logic programming at 30
>>>>>> https://arxiv.org/abs/2102.10556
>>>>>>
>>>>>> The paper contains not a single reference to autoencoders!
>>>>>> Still they show this example:
>>>>>>
>>>>>> Fig. 1 ILP systems struggle with structured examples that
>>>>>> exhibit observational noise. All three examples clearly
>>>>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>>>>> shifted and elongated letters. If we would be to learn a
>>>>>> program that simply draws "ILP" in the middle of the picture,
>>>>>> without noisy pixels and elongated letters, that would
>>>>>> be a correct program.
>>>>>>
>>>>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>>>>> turned into transformer was already reported here (*):
>>>>>>
>>>>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>>>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf 
>>>>>>
>>>>>>
>>>>>> Well ILP might have its merits, maybe we should not ask
>>>>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>>>>> But its tricky, I am still trying to decode the da Vinci code of
>>>>>>
>>>>>> things like stacked tensors, are they related to k-literal clauses?
>>>>>> The paper I referenced is found in this excellent video:
>>>>>>
>>>>>> The Making of ChatGPT (35 Year History)
>>>>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>>>>
>>>>>
>>>>
>>>
>>
> 

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

#14581 — I really have lost all hope and given up (Was: maplist(char_code, Chars, Codes) is bidirectional)

So the SWI-Prolog master wrote:

 > I wouldn’t call it an “ancient status”.

Its ancient status because its not Unicode
ready. It says, it doesn’t account for the
new universal atom and strings in SWI-Prolog.

Historical note: Unversal strings marked the
transition from Python 2.x to Python 3.x.

- we might be able to use the current locale
   to include the appropriate code page.
   (Does that really make sense?)

https://www.swi-prolog.org/pldoc/doc_for?object=is_text_code/1

But anyway I have retracted my swi2.pl.log
from GitHub and blocked Jan. W. for the first
time in my life. I really have lost all hope
concerning SWI-Prolog and given up

once and for ever...

Mild Shock schrieb:
> Using again my super powered library(portray_text):
> 
> ?- set_prolog_flag(double_quotes, codes).
> true.
> 
> ?- set_prolog_flag(back_quotes, chars).
> true.
> 
> ?- set_portray_text(enabled, true).
> true.
> 
> ?- maplist(char_code, `abc`, X).
> X = "abc".
> 
> ?- maplist(char_code, X, "abc").
> X = `abc`.
> 
> So if you have a Prolog system that has chars, you
> could bootstrap as follows:
> 
> atom_codes(X, Y) :-
>    var(X), !,
>    atom_chars(Z, Y),
>    maplist(char_code, X, Z).
> atom_codes(X, Y) :-
>    atom_chars(X, Z),
>    maplist(char_code, Z, Y).
> 
> Or if you have a Prolog system that has codes, you
> could bootstrap as follows:
> 
> atom_chars(X, Y) :-
>    var(X), !,
>    atom_codes(Z, Y),
>    maplist(char_code, Z, X).
> atom_chars(X, Y) :-
>    atom_codes(X, Z),
>    maplist(char_code, Y, Z).
> 
> Mild Shock schrieb:
>> Full source code here:
>>
>> swi2.pl.log
>> https://github.com/SWI-Prolog/swipl-devel/issues/1373#issuecomment-2997214639 
>>
>>
>> Since it has a dual use hook, works fine simultaneously:
>>
>> ?- set_portray_text(enabled, false).
>> true.
>>
>> ?- X = [a,b,c].
>> X = [a, b, c].
>>
>> ?- X = [0'a,0'b,0'c].
>> X = [97, 98, 99].
>>
>> And then:
>>
>> ?- set_prolog_flag(double_quotes, codes).
>> true.
>>
>> ?- set_prolog_flag(back_quotes, chars).
>> true.
>>
>> ?- set_portray_text(enabled, true).
>> true.
>>
>> ?- X = [a,b,c].
>> X = `abc`.
>>
>> ?- X = [0'a,0'b,0'c].
>> X = "abc".
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Even the SWI-Prolog master not wide awake,
>>> doing day-sleeping.
>>>
>>>  > I don’t know whether they realised that you
>>>  > cannot meaningfully support both in the same
>>>  > system and surely not in the same application.
>>>
>>> Maybe you didn’t notice this nifty detail.
>>> Thats all you need:
>>>
>>>  > The ISO core standard is silent about a flag back_quotes
>>>
>>>  > Its more a naming problem. Have two libraries
>>> library(portray_codes) and library(portray_chars),
>>> Or one library(portray_text).
>>>
>>> Just add one more rule:
>>>
>>> user:portray(Chars) :-
>>>      portray_text_option(enabled, true),
>>>      '$skip_list'(Length, Chars, _Tail),
>>>      portray_text_option(min_length, MinLen),
>>>      Length >= MinLen,
>>>      mostly_chars(Chars, 0.9),
>>>      portray_text_option(ellipsis, IfLonger),
>>>      quote2(C),
>>>      put_code(C),
>>>      maplist(char_code, Chars, Codes),
>>>      (   Length > IfLonger
>>>      ->  First is IfLonger - 5,
>>>          Skip is Length - 5,
>>>          skip_first(Skip, Codes, Rest),
>>>          put_n_codes(First, Codes, C),
>>>          format('...', [])
>>>      ;   Rest = Codes
>>>      ),
>>>      put_var_codes(Rest, C),
>>>      put_code(C).
>>>
>>> The use of maplist/3 is elegant, and works since we do
>>> not print open lists, right?
>>>
>>> Mild Shock schrieb:
>>>> Hi,
>>>>
>>>> The most radical approach is Novacore from
>>>> Dogelog Player. It consists of the following
>>>> major incisions in the ISO core standard:
>>>>
>>>> - We do not forbid chars, like for example
>>>>    using lists of the form [a,b,c], we also
>>>>    provide char_code/2 predicate bidirectionally.
>>>>
>>>> - We do not provide and _chars built-in
>>>>    predicates also there is nothing _strings. The
>>>>    Prolog system is clever enough to not put
>>>>    every atom it sees in an atom table. There
>>>>    is only a predicate table.
>>>>
>>>> - Some host languages have garbage collection that
>>>>    deduplicates Strings. For example some Java
>>>>    versions have an options to do that. But we
>>>>    do not have any efforts to deduplicate atoms,
>>>>    which are simply plain strings.
>>>>
>>>> - Some languages have constant pools. For example
>>>>    the Java byte code format includes a constant
>>>>    pool in every class header. We do not do that
>>>>    during transpilation , but we could of course.
>>>>    But it begs the question, why only deduplicate
>>>>    strings and not other constant expressions as well?
>>>>
>>>> - We are totally happy that we have only codes,
>>>>    there are chances that the host languages use
>>>>    tagged pointers to represent them. So they
>>>>    are represented similar to the tagged pointers
>>>>    in SWI-Prolog which works for small integers.
>>>>
>>>> - But the tagged pointer argument is moot,
>>>>    since atom length=1 entities can be also
>>>>    represented as tagged pointers, and some
>>>>    programming languages do that. Dogelog Player
>>>>    would use such tagged pointers without
>>>>    poluting the atom table.
>>>>
>>>> - What else?
>>>>
>>>> Bye
>>>>
>>>> Mild Shock schrieb:
>>>>>
>>>>> Technically SWI-Prolog doesn't prefer codes.
>>>>> Library `library(pure_input)` might prefer codes.
>>>>> But this is again an issue of improving the
>>>>> library by some non existent SWI-Prolog community.
>>>>>
>>>>> The ISO core standard is silent about a flag
>>>>> back_quotes, but has a lot of API requirements
>>>>> that support both codes and chars, for example it
>>>>> requires atom_codes/2 and atom_chars/2.
>>>>>
>>>>> Implementation wise there can be an issue,
>>>>> like one might decide to implement the atoms
>>>>> of length=1 more efficiently, since with Unicode
>>>>> there is now an explosion.
>>>>>
>>>>> Not sure whether Trealla Prolog and Scryer
>>>>> Prolog thought about this problem, that the
>>>>> atom table gets quite large. Whereas codes don't
>>>>> eat the atom table. Maybe they forbit predicates
>>>>>
>>>>> that have an atom of length=1 head:
>>>>>
>>>>> h(X) :-
>>>>>      write('Hello '), write(X), write('!'), nl.
>>>>>
>>>>> Does this still work?
>>>>>
>>>>> Mild Shock schrieb:
>>>>>> Concerning library(portray_text) which is in limbo:
>>>>>>
>>>>>>  > Libraries are (often) written for either
>>>>>> and thus the libraries make the choice.
>>>>>>
>>>>>> But who writes these libraries? The SWI Prolog
>>>>>> community. And who doesn’t improve these libraries,
>>>>>> instead floods the web with workaround tips?
>>>>>> The SWI Prolog community.
>>>>>>
>>>>>> Conclusion the SWI-Prolog community has itself
>>>>>> trapped in an ancient status quo, creating an island.
>>>>>> Cannot improve its own tooling, is not willing
>>>>>> to support code from else where that uses chars.
>>>>>>
>>>>>> Same with the missed AI Boom.
>>>>>>
>>>>>> (*) Code from elsewhere is dangerous, People
>>>>>> might use other Prolog systems than only SWI-Prolog,
>>>>>> like for exampe Trealla Prolog and Scryer Prolog.
>>>>>>
>>>>>> (**) Keeping the status quo is comfy. No need to
>>>>>> think in terms of programm code. Its like biology
>>>>>> teachers versus pathology staff, biology teachers
>>>>>> do not everyday see opened corpses.
>>>>>>
>>>>>>
>>>>>> Mild Shock schrieb:
>>>>>>>
>>>>>>> Inductive logic programming at 30
>>>>>>> https://arxiv.org/abs/2102.10556
>>>>>>>
>>>>>>> The paper contains not a single reference to autoencoders!
>>>>>>> Still they show this example:
>>>>>>>
>>>>>>> Fig. 1 ILP systems struggle with structured examples that
>>>>>>> exhibit observational noise. All three examples clearly
>>>>>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>>>>>> shifted and elongated letters. If we would be to learn a
>>>>>>> program that simply draws "ILP" in the middle of the picture,
>>>>>>> without noisy pixels and elongated letters, that would
>>>>>>> be a correct program.
>>>>>>>
>>>>>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>>>>>> turned into transformer was already reported here (*):
>>>>>>>
>>>>>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>>>>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf 
>>>>>>>
>>>>>>>
>>>>>>> Well ILP might have its merits, maybe we should not ask
>>>>>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>>>>>> But its tricky, I am still trying to decode the da Vinci code of
>>>>>>>
>>>>>>> things like stacked tensors, are they related to k-literal clauses?
>>>>>>> The paper I referenced is found in this excellent video:
>>>>>>>
>>>>>>> The Making of ChatGPT (35 Year History)
>>>>>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

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

#14598 — Do Prologers know the Unicode Range? (Was: Most radical approach is Novacore from Dogelog Player)

The official replacement character is 0xFFFD:

 > Replacement Character
 > https://www.compart.com/de/unicode/U+FFFD

Well that is what people did in the past, replace
non-printables by the ever same code, instead of
using ‘\uXXXX’ notation. I have studied the

library(portray_text) extensively. And my conclusion
is still that it extremly ancient.

For example I find:

mostly_codes([H|T], Yes, No, MinFactor) :-
     integer(H),
     H >= 0,
     H =< 0x1ffff,
     [...]
    ;   catch(code_type(H, print),error(_,_),fail),
     [...]

https://github.com/SWI-Prolog/swipl-devel/blob/eddbde61be09b95eb3ca2e160e73c2340744a3d2/library/portray_text.pl#L235

Why even 0x1ffff and not 0x10ffff, this is a bug,
do you want to starve is_text_code/1 ? The official
Unicode range is 0x0 to 0x10ffff. Ulrich Neumerkel

often confused the range in some of his code snippets,
maybe based on a limited interpretation of Unicode.
But if one would switch to chars one could easily

support any Unicode code point even without
knowing the range. Just do this:

mostly_chars([H|T], Yes, No, MinFactor) :-
     atom(H),
     atom_length(H, 1),
     [...]
    ;  /* printable check not needed */
     [...]

Mild Shock schrieb:
> Hi,
> 
> The most radical approach is Novacore from
> Dogelog Player. It consists of the following
> major incisions in the ISO core standard:
> 
> - We do not forbid chars, like for example
>    using lists of the form [a,b,c], we also
>    provide char_code/2 predicate bidirectionally.
> 
> - We do not provide and _chars built-in
>    predicates also there is nothing _strings. The
>    Prolog system is clever enough to not put
>    every atom it sees in an atom table. There
>    is only a predicate table.
> 
> - Some host languages have garbage collection that
>    deduplicates Strings. For example some Java
>    versions have an options to do that. But we
>    do not have any efforts to deduplicate atoms,
>    which are simply plain strings.
> 
> - Some languages have constant pools. For example
>    the Java byte code format includes a constant
>    pool in every class header. We do not do that
>    during transpilation , but we could of course.
>    But it begs the question, why only deduplicate
>    strings and not other constant expressions as well?
> 
> - We are totally happy that we have only codes,
>    there are chances that the host languages use
>    tagged pointers to represent them. So they
>    are represented similar to the tagged pointers
>    in SWI-Prolog which works for small integers.
> 
> - But the tagged pointer argument is moot,
>    since atom length=1 entities can be also
>    represented as tagged pointers, and some
>    programming languages do that. Dogelog Player
>    would use such tagged pointers without
>    poluting the atom table.
> 
> - What else?
> 
> Bye
> 
> Mild Shock schrieb:
>>
>> Technically SWI-Prolog doesn't prefer codes.
>> Library `library(pure_input)` might prefer codes.
>> But this is again an issue of improving the
>> library by some non existent SWI-Prolog community.
>>
>> The ISO core standard is silent about a flag
>> back_quotes, but has a lot of API requirements
>> that support both codes and chars, for example it
>> requires atom_codes/2 and atom_chars/2.
>>
>> Implementation wise there can be an issue,
>> like one might decide to implement the atoms
>> of length=1 more efficiently, since with Unicode
>> there is now an explosion.
>>
>> Not sure whether Trealla Prolog and Scryer
>> Prolog thought about this problem, that the
>> atom table gets quite large. Whereas codes don't
>> eat the atom table. Maybe they forbit predicates
>>
>> that have an atom of length=1 head:
>>
>> h(X) :-
>>      write('Hello '), write(X), write('!'), nl.
>>
>> Does this still work?
>>
>> Mild Shock schrieb:
>>> Concerning library(portray_text) which is in limbo:
>>>
>>>  > Libraries are (often) written for either
>>> and thus the libraries make the choice.
>>>
>>> But who writes these libraries? The SWI Prolog
>>> community. And who doesn’t improve these libraries,
>>> instead floods the web with workaround tips?
>>> The SWI Prolog community.
>>>
>>> Conclusion the SWI-Prolog community has itself
>>> trapped in an ancient status quo, creating an island.
>>> Cannot improve its own tooling, is not willing
>>> to support code from else where that uses chars.
>>>
>>> Same with the missed AI Boom.
>>>
>>> (*) Code from elsewhere is dangerous, People
>>> might use other Prolog systems than only SWI-Prolog,
>>> like for exampe Trealla Prolog and Scryer Prolog.
>>>
>>> (**) Keeping the status quo is comfy. No need to
>>> think in terms of programm code. Its like biology
>>> teachers versus pathology staff, biology teachers
>>> do not everyday see opened corpses.
>>>
>>>
>>> Mild Shock schrieb:
>>>>
>>>> Inductive logic programming at 30
>>>> https://arxiv.org/abs/2102.10556
>>>>
>>>> The paper contains not a single reference to autoencoders!
>>>> Still they show this example:
>>>>
>>>> Fig. 1 ILP systems struggle with structured examples that
>>>> exhibit observational noise. All three examples clearly
>>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>>> shifted and elongated letters. If we would be to learn a
>>>> program that simply draws "ILP" in the middle of the picture,
>>>> without noisy pixels and elongated letters, that would
>>>> be a correct program.
>>>>
>>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>>> turned into transformer was already reported here (*):
>>>>
>>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf 
>>>>
>>>>
>>>> Well ILP might have its merits, maybe we should not ask
>>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>>> But its tricky, I am still trying to decode the da Vinci code of
>>>>
>>>> things like stacked tensors, are they related to k-literal clauses?
>>>> The paper I referenced is found in this excellent video:
>>>>
>>>> The Making of ChatGPT (35 Year History)
>>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>>
>>>
>>
> 

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

#14599 — Can Prologers produce 100% Prolog Code? (Was: Do Prologers know the Unicode Range?)

Somebody wrote:

 > It seems that it reads in as ðŸ‘\u008D but writes out as ðŸ‘\\x8D\\.

Can one then do ‘\uXXXX’ in 100% Prolog as
well? Even including surrogates? Of course,
here some DCG generator snippet from Dogelog

Player which is 100% Prolog. This is from the
Java backend, because I didn’t introduce ‘\uXXXX’
in my Prolog system, because it is not part of

ISO core standard. The ISO core standard would want '\xXX':

crossj_escape_code2(X) --> {X =< 0xFFFF}, !,
    {atom_integer(J, 16, X), atom_codes(J, H),
    length(H, N), M is 4-N}, [0'\\, 0'u],
    cross_escape_zeros(M),
    cross_escape_codes2(H).
crossj_escape_code2(X) --> {crossj_high_surrogate(X, Y),
    crossj_low_surrogate(X, Z)},
    crossj_escape_code2(Y),
    crossj_escape_code2(Z).

crossj_high_surrogate(X, Y) :- Y is (X >> 10) + 0xD7C0.

crossj_low_surrogate(X, Y) :- Y is (X /\ 0x3FF) + 0xDC00.

Mild Shock schrieb:
> The official replacement character is 0xFFFD:
> 
>  > Replacement Character
>  > https://www.compart.com/de/unicode/U+FFFD
> 
> Well that is what people did in the past, replace
> non-printables by the ever same code, instead of
> using ‘\uXXXX’ notation. I have studied the
> 
> library(portray_text) extensively. And my conclusion
> is still that it extremly ancient.
> 
> For example I find:
> 
> mostly_codes([H|T], Yes, No, MinFactor) :-
>      integer(H),
>      H >= 0,
>      H =< 0x1ffff,
>      [...]
>     ;   catch(code_type(H, print),error(_,_),fail),
>      [...]
> 
> https://github.com/SWI-Prolog/swipl-devel/blob/eddbde61be09b95eb3ca2e160e73c2340744a3d2/library/portray_text.pl#L235 
> 
> 
> Why even 0x1ffff and not 0x10ffff, this is a bug,
> do you want to starve is_text_code/1 ? The official
> Unicode range is 0x0 to 0x10ffff. Ulrich Neumerkel
> 
> often confused the range in some of his code snippets,
> maybe based on a limited interpretation of Unicode.
> But if one would switch to chars one could easily
> 
> support any Unicode code point even without
> knowing the range. Just do this:
> 
> mostly_chars([H|T], Yes, No, MinFactor) :-
>      atom(H),
>      atom_length(H, 1),
>      [...]
>     ;  /* printable check not needed */
>      [...]
> 
> Mild Shock schrieb:
>> Hi,
>>
>> The most radical approach is Novacore from
>> Dogelog Player. It consists of the following
>> major incisions in the ISO core standard:
>>
>> - We do not forbid chars, like for example
>>    using lists of the form [a,b,c], we also
>>    provide char_code/2 predicate bidirectionally.
>>
>> - We do not provide and _chars built-in
>>    predicates also there is nothing _strings. The
>>    Prolog system is clever enough to not put
>>    every atom it sees in an atom table. There
>>    is only a predicate table.
>>
>> - Some host languages have garbage collection that
>>    deduplicates Strings. For example some Java
>>    versions have an options to do that. But we
>>    do not have any efforts to deduplicate atoms,
>>    which are simply plain strings.
>>
>> - Some languages have constant pools. For example
>>    the Java byte code format includes a constant
>>    pool in every class header. We do not do that
>>    during transpilation , but we could of course.
>>    But it begs the question, why only deduplicate
>>    strings and not other constant expressions as well?
>>
>> - We are totally happy that we have only codes,
>>    there are chances that the host languages use
>>    tagged pointers to represent them. So they
>>    are represented similar to the tagged pointers
>>    in SWI-Prolog which works for small integers.
>>
>> - But the tagged pointer argument is moot,
>>    since atom length=1 entities can be also
>>    represented as tagged pointers, and some
>>    programming languages do that. Dogelog Player
>>    would use such tagged pointers without
>>    poluting the atom table.
>>
>> - What else?
>>
>> Bye
>>
>> Mild Shock schrieb:
>>>
>>> Technically SWI-Prolog doesn't prefer codes.
>>> Library `library(pure_input)` might prefer codes.
>>> But this is again an issue of improving the
>>> library by some non existent SWI-Prolog community.
>>>
>>> The ISO core standard is silent about a flag
>>> back_quotes, but has a lot of API requirements
>>> that support both codes and chars, for example it
>>> requires atom_codes/2 and atom_chars/2.
>>>
>>> Implementation wise there can be an issue,
>>> like one might decide to implement the atoms
>>> of length=1 more efficiently, since with Unicode
>>> there is now an explosion.
>>>
>>> Not sure whether Trealla Prolog and Scryer
>>> Prolog thought about this problem, that the
>>> atom table gets quite large. Whereas codes don't
>>> eat the atom table. Maybe they forbit predicates
>>>
>>> that have an atom of length=1 head:
>>>
>>> h(X) :-
>>>      write('Hello '), write(X), write('!'), nl.
>>>
>>> Does this still work?
>>>
>>> Mild Shock schrieb:
>>>> Concerning library(portray_text) which is in limbo:
>>>>
>>>>  > Libraries are (often) written for either
>>>> and thus the libraries make the choice.
>>>>
>>>> But who writes these libraries? The SWI Prolog
>>>> community. And who doesn’t improve these libraries,
>>>> instead floods the web with workaround tips?
>>>> The SWI Prolog community.
>>>>
>>>> Conclusion the SWI-Prolog community has itself
>>>> trapped in an ancient status quo, creating an island.
>>>> Cannot improve its own tooling, is not willing
>>>> to support code from else where that uses chars.
>>>>
>>>> Same with the missed AI Boom.
>>>>
>>>> (*) Code from elsewhere is dangerous, People
>>>> might use other Prolog systems than only SWI-Prolog,
>>>> like for exampe Trealla Prolog and Scryer Prolog.
>>>>
>>>> (**) Keeping the status quo is comfy. No need to
>>>> think in terms of programm code. Its like biology
>>>> teachers versus pathology staff, biology teachers
>>>> do not everyday see opened corpses.
>>>>
>>>>
>>>> Mild Shock schrieb:
>>>>>
>>>>> Inductive logic programming at 30
>>>>> https://arxiv.org/abs/2102.10556
>>>>>
>>>>> The paper contains not a single reference to autoencoders!
>>>>> Still they show this example:
>>>>>
>>>>> Fig. 1 ILP systems struggle with structured examples that
>>>>> exhibit observational noise. All three examples clearly
>>>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>>>> shifted and elongated letters. If we would be to learn a
>>>>> program that simply draws "ILP" in the middle of the picture,
>>>>> without noisy pixels and elongated letters, that would
>>>>> be a correct program.
>>>>>
>>>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>>>> turned into transformer was already reported here (*):
>>>>>
>>>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf 
>>>>>
>>>>>
>>>>> Well ILP might have its merits, maybe we should not ask
>>>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>>>> But its tricky, I am still trying to decode the da Vinci code of
>>>>>
>>>>> things like stacked tensors, are they related to k-literal clauses?
>>>>> The paper I referenced is found in this excellent video:
>>>>>
>>>>> The Making of ChatGPT (35 Year History)
>>>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>>>
>>>>
>>>
>>
> 

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

#14600 — Attention: Python versus Java (Was: Can Prologers produce 100% Prolog Code?)

Attention: Java is an example that doesn’t
understand \UXXXXXXXX, so one has to be careful
in inroducing \uXXXX and \UXXXXXXXX at the same time.

Although we have in Python that this works:

emoji = "\U0001F600"  # 😀 GRINNING FACE

Python universal strings can even distingush between
original code point, and surrogate translation, since
the strings can be up to 32-bit words. Java does

only accept for grinning face the surrogate
translation, since their strings are 16-bit words:

String emoji = "\uD83D\uDE00";  // 😀 GRINNING FACE

Mild Shock schrieb:
> Somebody wrote:
> 
>  > It seems that it reads in as ðŸ‘\u008D but writes out as ðŸ‘\\x8D\\.
> 
> Can one then do ‘\uXXXX’ in 100% Prolog as
> well? Even including surrogates? Of course,
> here some DCG generator snippet from Dogelog
> 
> Player which is 100% Prolog. This is from the
> Java backend, because I didn’t introduce ‘\uXXXX’
> in my Prolog system, because it is not part of
> 
> ISO core standard. The ISO core standard would want '\xXX':
> 
> crossj_escape_code2(X) --> {X =< 0xFFFF}, !,
>     {atom_integer(J, 16, X), atom_codes(J, H),
>     length(H, N), M is 4-N}, [0'\\, 0'u],
>     cross_escape_zeros(M),
>     cross_escape_codes2(H).
> crossj_escape_code2(X) --> {crossj_high_surrogate(X, Y),
>     crossj_low_surrogate(X, Z)},
>     crossj_escape_code2(Y),
>     crossj_escape_code2(Z).
> 
> crossj_high_surrogate(X, Y) :- Y is (X >> 10) + 0xD7C0.
> 
> crossj_low_surrogate(X, Y) :- Y is (X /\ 0x3FF) + 0xDC00.
> 
> Mild Shock schrieb:
>> The official replacement character is 0xFFFD:
>>
>>  > Replacement Character
>>  > https://www.compart.com/de/unicode/U+FFFD
>>
>> Well that is what people did in the past, replace
>> non-printables by the ever same code, instead of
>> using ‘\uXXXX’ notation. I have studied the
>>
>> library(portray_text) extensively. And my conclusion
>> is still that it extremly ancient.
>>
>> For example I find:
>>
>> mostly_codes([H|T], Yes, No, MinFactor) :-
>>      integer(H),
>>      H >= 0,
>>      H =< 0x1ffff,
>>      [...]
>>     ;   catch(code_type(H, print),error(_,_),fail),
>>      [...]
>>
>> https://github.com/SWI-Prolog/swipl-devel/blob/eddbde61be09b95eb3ca2e160e73c2340744a3d2/library/portray_text.pl#L235 
>>
>>
>> Why even 0x1ffff and not 0x10ffff, this is a bug,
>> do you want to starve is_text_code/1 ? The official
>> Unicode range is 0x0 to 0x10ffff. Ulrich Neumerkel
>>
>> often confused the range in some of his code snippets,
>> maybe based on a limited interpretation of Unicode.
>> But if one would switch to chars one could easily
>>
>> support any Unicode code point even without
>> knowing the range. Just do this:
>>
>> mostly_chars([H|T], Yes, No, MinFactor) :-
>>      atom(H),
>>      atom_length(H, 1),
>>      [...]
>>     ;  /* printable check not needed */
>>      [...]
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> The most radical approach is Novacore from
>>> Dogelog Player. It consists of the following
>>> major incisions in the ISO core standard:
>>>
>>> - We do not forbid chars, like for example
>>>    using lists of the form [a,b,c], we also
>>>    provide char_code/2 predicate bidirectionally.
>>>
>>> - We do not provide and _chars built-in
>>>    predicates also there is nothing _strings. The
>>>    Prolog system is clever enough to not put
>>>    every atom it sees in an atom table. There
>>>    is only a predicate table.
>>>
>>> - Some host languages have garbage collection that
>>>    deduplicates Strings. For example some Java
>>>    versions have an options to do that. But we
>>>    do not have any efforts to deduplicate atoms,
>>>    which are simply plain strings.
>>>
>>> - Some languages have constant pools. For example
>>>    the Java byte code format includes a constant
>>>    pool in every class header. We do not do that
>>>    during transpilation , but we could of course.
>>>    But it begs the question, why only deduplicate
>>>    strings and not other constant expressions as well?
>>>
>>> - We are totally happy that we have only codes,
>>>    there are chances that the host languages use
>>>    tagged pointers to represent them. So they
>>>    are represented similar to the tagged pointers
>>>    in SWI-Prolog which works for small integers.
>>>
>>> - But the tagged pointer argument is moot,
>>>    since atom length=1 entities can be also
>>>    represented as tagged pointers, and some
>>>    programming languages do that. Dogelog Player
>>>    would use such tagged pointers without
>>>    poluting the atom table.
>>>
>>> - What else?
>>>
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>>
>>>> Technically SWI-Prolog doesn't prefer codes.
>>>> Library `library(pure_input)` might prefer codes.
>>>> But this is again an issue of improving the
>>>> library by some non existent SWI-Prolog community.
>>>>
>>>> The ISO core standard is silent about a flag
>>>> back_quotes, but has a lot of API requirements
>>>> that support both codes and chars, for example it
>>>> requires atom_codes/2 and atom_chars/2.
>>>>
>>>> Implementation wise there can be an issue,
>>>> like one might decide to implement the atoms
>>>> of length=1 more efficiently, since with Unicode
>>>> there is now an explosion.
>>>>
>>>> Not sure whether Trealla Prolog and Scryer
>>>> Prolog thought about this problem, that the
>>>> atom table gets quite large. Whereas codes don't
>>>> eat the atom table. Maybe they forbit predicates
>>>>
>>>> that have an atom of length=1 head:
>>>>
>>>> h(X) :-
>>>>      write('Hello '), write(X), write('!'), nl.
>>>>
>>>> Does this still work?
>>>>
>>>> Mild Shock schrieb:
>>>>> Concerning library(portray_text) which is in limbo:
>>>>>
>>>>>  > Libraries are (often) written for either
>>>>> and thus the libraries make the choice.
>>>>>
>>>>> But who writes these libraries? The SWI Prolog
>>>>> community. And who doesn’t improve these libraries,
>>>>> instead floods the web with workaround tips?
>>>>> The SWI Prolog community.
>>>>>
>>>>> Conclusion the SWI-Prolog community has itself
>>>>> trapped in an ancient status quo, creating an island.
>>>>> Cannot improve its own tooling, is not willing
>>>>> to support code from else where that uses chars.
>>>>>
>>>>> Same with the missed AI Boom.
>>>>>
>>>>> (*) Code from elsewhere is dangerous, People
>>>>> might use other Prolog systems than only SWI-Prolog,
>>>>> like for exampe Trealla Prolog and Scryer Prolog.
>>>>>
>>>>> (**) Keeping the status quo is comfy. No need to
>>>>> think in terms of programm code. Its like biology
>>>>> teachers versus pathology staff, biology teachers
>>>>> do not everyday see opened corpses.
>>>>>
>>>>>
>>>>> Mild Shock schrieb:
>>>>>>
>>>>>> Inductive logic programming at 30
>>>>>> https://arxiv.org/abs/2102.10556
>>>>>>
>>>>>> The paper contains not a single reference to autoencoders!
>>>>>> Still they show this example:
>>>>>>
>>>>>> Fig. 1 ILP systems struggle with structured examples that
>>>>>> exhibit observational noise. All three examples clearly
>>>>>> spell the word "ILP", with some alterations: 3 noisy pixels,
>>>>>> shifted and elongated letters. If we would be to learn a
>>>>>> program that simply draws "ILP" in the middle of the picture,
>>>>>> without noisy pixels and elongated letters, that would
>>>>>> be a correct program.
>>>>>>
>>>>>> I guess ILP is 30 years behind the AI boom. An early autoencoder
>>>>>> turned into transformer was already reported here (*):
>>>>>>
>>>>>> SERIAL ORDER, Michael I. Jordan - May 1986
>>>>>> https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf 
>>>>>>
>>>>>>
>>>>>> Well ILP might have its merits, maybe we should not ask
>>>>>> for a marriage of LLM and Prolog, but Autoencoders and ILP.
>>>>>> But its tricky, I am still trying to decode the da Vinci code of
>>>>>>
>>>>>> things like stacked tensors, are they related to k-literal clauses?
>>>>>> The paper I referenced is found in this excellent video:
>>>>>>
>>>>>> The Making of ChatGPT (35 Year History)
>>>>>> https://www.youtube.com/watch?v=OFS90-FX6pg
>>>>>>
>>>>>
>>>>
>>>
>>
> 

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web