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
It’s a self-supervised form of ILP.
No autoencoders anywhere at all.
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
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
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
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
Ivar Jacobson defines a variation point as follows:
A variation point identifies one or more locations at
which the variation will occur.
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]).
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
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
Libraries are (often) written for eitherand thus the libraries make the choice.
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
Concerning library(portray_text) which is in limbo:
Libraries are (often) written for eitherand 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
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 eitherand 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
I don’t know whether they realised that you
cannot meaningfully support both in the same
system and surely not in the same application.
The ISO core standard is silent about a flag back_quoteslibrary(portray_codes) and library(portray_chars),
Its more a naming problem. Have two libraries
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 eitherand 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
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 librarieslibrary(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 eitherand 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
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 librarieslibrary(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 eitherand 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
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_quoteslibrary(portray_codes) and library(portray_chars),
Its more a naming problem. Have two libraries
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 eitherand 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
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
What is holy is only for Dogelog Player!
Do not give dogs what is holy, and do not
throw your pearls before pigs, lest they
trample them underfoot and turn to attack you.
-- Matthew 7:6
https://www.biblegateway.com/passage/?search=Matthew%207%3A6
I have deleted my posts and the swi2.pl.log proposal:
between(C, 0'0, 0'9), Digit is C-0'0.`
Just rewrite it to:
0'0 =< [Digit], [Digit] =< 0'9, [Digit] is C-0'0`.
The [X] in an evaluation is dual use again:
?- X is [a].
X = 97.
?- X is [0'a].
X = 97.
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
Oops should read:
0'0 =< [C], [C] =< 0'9, Digit is [C]-0'0`.
Mild Shock schrieb:
What is holy is only for Dogelog Player!
Do not give dogs what is holy, and do not
throw your pearls before pigs, lest they
trample them underfoot and turn to attack you.
-- Matthew 7:6
https://www.biblegateway.com/passage/?search=Matthew%207%3A6
I have deleted my posts and the swi2.pl.log proposal:
between(C, 0'0, 0'9), Digit is C-0'0.`
Just rewrite it to:
0'0 =< [Digit], [Digit] =< 0'9, [Digit] is C-0'0`.
The [X] in an evaluation is dual use again:
?- X is [a].
X = 97.
?- X is [0'a].
X = 97.
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
Hi,
What WG17 could do to prevent segregation.
It could specify:
- The back_quotes flag. Not really something
new , most Prolog systems have it already.
- The [X] evaluable function. Not really something
new , most Prolog systems have it already. For
example DEC-10 Prolog (10 November 1982) had it
already, The new thing for some Prolog systems
would be its non-strict evaluation strategy
and the dual use:
[X] (a list of just one element) evaluates to X if X is an
integer. Since a quoted string is just a list of integers,
this allows a quoted character to be used in place of its
ASCII code; e.g. "A" behaves within arithmetic expressions
as the integer 65.
https://userweb.fct.unl.pt/~lmp/publications/online-papers/DECsystem-10%20PROLOG%20USER%27S%20MANUAL.pdf
Instead what is WG17 doing?
- Introducing a notation for open strings:
[a, b, c|X] = "abc" || X
With a new separator ||, giving possibly much more
headache to Prolog system implementors than a flag
and an evaluable function.
Bye
Mild Shock schrieb:
Oops should read:
0'0 =< [C], [C] =< 0'9, Digit is [C]-0'0`.
Mild Shock schrieb:
What is holy is only for Dogelog Player!
Do not give dogs what is holy, and do not
throw your pearls before pigs, lest they
trample them underfoot and turn to attack you.
-- Matthew 7:6
https://www.biblegateway.com/passage/?search=Matthew%207%3A6
I have deleted my posts and the swi2.pl.log proposal:
between(C, 0'0, 0'9), Digit is C-0'0.`
Just rewrite it to:
0'0 =< [Digit], [Digit] =< 0'9, [Digit] is C-0'0`.
The [X] in an evaluation is dual use again:
?- X is [a].
X = 97.
?- X is [0'a].
X = 97.
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
Replacement Character
https://www.compart.com/de/unicode/U+FFFD
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 eitherand 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
Those that use a large part pay a pretty
high price in terms of memory and currently
also time for code points > 0xffff
:rocket: Call for Papers: Integrating Logical
Reasoning & Large Language Models (LLMs) :brain:
https://swi-prolog.discourse.group/t/9065
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
Those that use a large part pay a pretty
high price in terms of memory and currently
also time for code points > 0xffff
Emojis are typically above 0xffff. And from this
announcement its seem, Emojis are a big part with
keeping up with the AI Boom:
:rocket: Call for Papers: Integrating Logical
Reasoning & Large Language Models (LLMs) :brain:
https://swi-prolog.discourse.group/t/9065
But it would cost you nothing to support this here in
library(portray_text):
/* SWI-Prolog 9.3.24 */
?- X = [a,b,c]
X = `abc`
It is extremly trivial to implement, its not really
rocket science. It doesn need much brains and
it works also for Emojis:
/* Scryer Prolog 0.9.4-411 */
?- X = [a,b,c].
X = "abc".
?- X = ['🚀', a, '🧠', b, c].
X = "🚀a🧠bc".
In Scryer Prolog it shows double quotes and not
back quotes, because of the different default settings
of the Prolog flags double_quotes and back_quotes.
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
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
Name: Bart Demoen
Dissertation: Stability and Equilibrium for Clasical infinite Systems Advisor: Andre Frans Maria Verbeure https://www.genealogy.math.ndsu.nodak.edu/id.php?id=70951
Gap in Section 7.6.2 and some Insecurity Arising from it
?- call((Z=!, a(X), Z)).
Z = !
X = 1 ?;
Z = !
X = 2
yes
?- findall(Z-X,call((Z=!, a(X), Z)),L).
L = [!-1]
https://groups.google.com/g/comp.lang.prolog/c/FNou9Z-A_Zs/m/NSSTmbx4E4wJ
PLEASE, DO NOT ALARM THIS NEWSGROUP ABOUT "FUNNY" RESULTS
WITHOUT TELLING US WHICH SYSTEM CAUSED THE RESULTS
Inductive logic programming at 30
https://arxiv.org/abs/2102.10556
The paper contains not a single reference to autoencoders!
Hi,
But I shouldn't waste too much time.
One shouldn't punish people for just
being plain stupid.
Like for example this clueless french
philosopher who had a lot of troubles
with non-classical logic.
His brain tried to eliminate non-classical
logic, it was keen on avoiding non-classical
logic. A typical species of a human with
an extremly small brain, again working
in the wrong place!
Bye
P.S.: Maybe this a Poincaré thingy? Poincaré
was a strong critic of logicism (as championed
by Frege and Russell) and of Hilbert’s
formalist program.
But, he did not formally use or promote systems
like intuitionistic logic, modal logic, or
relevance logic. His logical framework remained
within the bounds of classical logic,
though he was skeptical of excessive formalism.
He thought formal systems could miss the creative
and synthetic nature of mathematical
invention.
Henri Poincaré believed that mathematical
and scientific creativity came from a deep,
unconscious intuition that could not be
captured by mechanical reasoning or formal
systems. He famously wrote about how insights
came not from plodding logic but from sudden
illuminations — leaps of creative synthesis.
But now we have generative AI — models like GPT — that:
- produce poetry, proofs, stories, and code,
- combine ideas in novel ways,
- and do so by processing patterns in massive
datasets, without conscious understanding.
And that does seem to contradict Poincaré's belief
that true invention cannot come from automation.
Mild Shock schrieb:
Hi,
But I shouldn't waste too much time.
One shouldn't punish people for just
being plain stupid.
Like for example this clueless french
philosopher who had a lot of troubles
with non-classical logic.
His brain tried to eliminate non-classical
logic, it was keen on avoiding non-classical
logic. A typical species of a human with
an extremly small brain, again working
in the wrong place!
Bye
P.S.: Maybe this a Poincaré thingy? Poincaré
was a strong critic of logicism (as championed
by Frege and Russell) and of Hilbert’s
formalist program.
But, he did not formally use or promote systems
like intuitionistic logic, modal logic, or
relevance logic. His logical framework remained
within the bounds of classical logic,
though he was skeptical of excessive formalism.
He thought formal systems could miss the creative
and synthetic nature of mathematical
invention.
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 eitherand 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
BTW: I see what you did here:
doge.pl: $(PROG)
$(file >$@,false :- \+true. ?- ['$<'],$(MAIN).)
https://github.com/hurufu/prolog-all/blob/main/rules.mk
Yes, I do not yet have a -g option.
Maybe should change that... The issue is a
little tricky. Only recently I managed to handle
some stuff that is tied to to the command line
after the Novacore has been loaded.
For example the top-level is now entered after
the Novacore is loaded, and the top-level loads
in itself library(session) etc.. To have a -g option
there is a dependency on
library(charsio), to convert a string into a term,
which is not part of Novacore itself. So maybe I could
do the same for a -g option, so that I can keep
the Novacore small, load
library(charsio) depending on the command line.
I just did yesterday something to make the Novacore
smaller. And handling a -g option this way could
be a viable way to keep it small.
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 eitherand 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
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
Henri Poincaré believed that mathematical
and scientific creativity came from a deep,
unconscious intuition that could not be
captured by mechanical reasoning or formal
systems. He famously wrote about how insights
came not from plodding logic but from sudden
illuminations — leaps of creative synthesis.
But now we have generative AI — models like GPT — that:
- produce poetry, proofs, stories, and code,
- combine ideas in novel ways,
- and do so by processing patterns in massive
datasets, without conscious understanding.
And that does seem to contradict Poincaré's belief
that true invention cannot come from automation.
Hi,
Will the world build on American Stacks?
Or is the american dream over?
How it started, 1 month go:
Nvidia CEO Jensen Huang on AI, Musk and Trump https://www.youtube.com/watch?v=c-XAL2oYelI
How its going, now:
Are you still talking about Jeffrey Epstein? https://www.bbc.com/news/articles/cm2m879neljo
Bye
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
Henri Poincaré believed that mathematical
and scientific creativity came from a deep,
unconscious intuition that could not be
captured by mechanical reasoning or formal
systems. He famously wrote about how insights
came not from plodding logic but from sudden
illuminations — leaps of creative synthesis.
But now we have generative AI — models like GPT — that:
- produce poetry, proofs, stories, and code,
- combine ideas in novel ways,
- and do so by processing patterns in massive
datasets, without conscious understanding.
And that does seem to contradict Poincaré's belief
that true invention cannot come from automation.
Mild Shock schrieb:
Hi,
But I shouldn't waste too much time.
One shouldn't punish people for just
being plain stupid.
Like for example this clueless french
philosopher who had a lot of troubles
with non-classical logic.
His brain tried to eliminate non-classical
logic, it was keen on avoiding non-classical
logic. A typical species of a human with
an extremly small brain, again working
in the wrong place!
Bye
P.S.: Maybe this a Poincaré thingy? Poincaré
was a strong critic of logicism (as championed
by Frege and Russell) and of Hilbert’s
formalist program.
But, he did not formally use or promote systems
like intuitionistic logic, modal logic, or
relevance logic. His logical framework remained
within the bounds of classical logic,
though he was skeptical of excessive formalism.
He thought formal systems could miss the creative
and synthetic nature of mathematical
invention.
Hi,
Rota often celebrated symbolic, analogical, and
conceptual understanding over brute calculation.
This philosophy has come full circle in modern AI:
- Large Language Models (LLMs) like GPT-4 don't
just store facts — they recognize patterns,
make analogies, and generate new structures
from old ones.
- Rota’s work in combinatorics, symbolic logic, and
operator theory is essentially pattern-based
manipulation — exactly the kind of reasoning LLMs
aim to emulate at scale.
Rota had a clear aesthetic. He valued clean formalisms,
symbolic beauty, and well-defined structures. Rota wanted
mathematics to mean something — to be not just correct,
but intelligible and expressive.
In contrast, modern AI (especially LLMs like GPT) thrives
on the messy, including: Noisy data , Inconsistency ,
Uncertainty, Contradiction. AI engineers today are mining
meaning from noise.
What counts as “structure” is often just the best
pragmatic/effective description available at that moment.
Bye
Mild Shock schrieb:
Hi,
Will the world build on American Stacks?
Or is the american dream over?
How it started, 1 month go:
Nvidia CEO Jensen Huang on AI, Musk and Trump
https://www.youtube.com/watch?v=c-XAL2oYelI
How its going, now:
Are you still talking about Jeffrey Epstein?
https://www.bbc.com/news/articles/cm2m879neljo
Bye
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
Hi,
An example of human intelligence, is of course the
name "Rational Term" for cyclic terms set forth by
Alain Colmerauer. Since it plays with "Rational Numbers".
A subset of cyclic terms can indeed represent
rational numbers, and they give a nice counter
example to transitivity:
?- problem(X,Y,Z).
X = _S1-7-9-1, % where
_S1 = _S1-6-8-0-6-2-8,
Y = _S2-1-6-1-5-4-6-1, % where
_S2 = _S2-0-9-2,
Z = _S3-3-0, % where
_S3 = _S3-8-1
The Fuzzer 2 from 2025 does just what I did in 2023,
expanding rational numbers into rational terms:
% fuzzy(-Term)
fuzzy(X) :-
random_between(1,100,A),
random_between(1,100,B),
random_between(1,10,M),
fuzzy_chunk(M,A,B,C,X,Y),
random_between(1,10,L),
fuzzy_chunk(L,C,B,_,Y,Z),
Z = Y.
% fuzzy_chunk(+Integer,+Integer,+Integer,-Integer,+Term,-Term)
fuzzy_chunk(0, A, _, A, X, X) :- !.
fuzzy_chunk(N, A, B, C, Y-D, X) :-
M is N-1,
D is A // B,
H is 10*(A - B*D),
fuzzy_chunk(M, H, B, C, Y, X).
Bye
Mild Shock schrieb:
Hi,
Rota often celebrated symbolic, analogical, and
conceptual understanding over brute calculation.
This philosophy has come full circle in modern AI:
- Large Language Models (LLMs) like GPT-4 don't
just store facts — they recognize patterns,
make analogies, and generate new structures
from old ones.
- Rota’s work in combinatorics, symbolic logic, and
operator theory is essentially pattern-based
manipulation — exactly the kind of reasoning LLMs
aim to emulate at scale.
Rota had a clear aesthetic. He valued clean formalisms,
symbolic beauty, and well-defined structures. Rota wanted
mathematics to mean something — to be not just correct,
but intelligible and expressive.
In contrast, modern AI (especially LLMs like GPT) thrives
on the messy, including: Noisy data , Inconsistency ,
Uncertainty, Contradiction. AI engineers today are mining
meaning from noise.
What counts as “structure” is often just the best
pragmatic/effective description available at that moment.
Bye
Mild Shock schrieb:
Hi,
Will the world build on American Stacks?
Or is the american dream over?
How it started, 1 month go:
Nvidia CEO Jensen Huang on AI, Musk and Trump
https://www.youtube.com/watch?v=c-XAL2oYelI
How its going, now:
Are you still talking about Jeffrey Epstein?
https://www.bbc.com/news/articles/cm2m879neljo
Bye
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
Hi,
Ok I have to correct "Rational Term" was less
common, what was more in use "Rational Trees",
but they might have also talked about finitely
represented infinite tree. Rational trees itself
probably an echo from Dmitry Mirimanoffs
(1861–1945) “extraordinaire” sets.
Dmitry Semionovitch Mirimanoff (Russian:
Дми́трий Семёнович Мирима́нов; 13 September 1861, Pereslavl-Zalessky, Russia – 5 January 1945, Geneva,
Switzerland) was a member of the Moscow Mathematical
Society in 1897.[1] And later became a doctor of
mathematical sciences in 1900, in Geneva, and
taught at the universities of Geneva and Lausanne. https://en.wikipedia.org/wiki/Dmitry_Mirimanoff
This year we can again celebrate another researcher,
who died in 2023, Peter Aczel R.I.P., who made
as well some thoughtful deviance from orthodoxy.
Peter Aczel Memorial Conference on 10th September 2025.
Logic Colloquium will take place at the University
of Manchester (UK) from 11th to 12th September 2025 https://sites.google.com/view/blc2025/home
Have Fun!
Bye
Mild Shock schrieb:
Hi,
An example of human intelligence, is of course the
name "Rational Term" for cyclic terms set forth by
Alain Colmerauer. Since it plays with "Rational Numbers".
A subset of cyclic terms can indeed represent
rational numbers, and they give a nice counter
example to transitivity:
?- problem(X,Y,Z).
X = _S1-7-9-1, % where
_S1 = _S1-6-8-0-6-2-8,
Y = _S2-1-6-1-5-4-6-1, % where
_S2 = _S2-0-9-2,
Z = _S3-3-0, % where
_S3 = _S3-8-1
The Fuzzer 2 from 2025 does just what I did in 2023,
expanding rational numbers into rational terms:
% fuzzy(-Term)
fuzzy(X) :-
random_between(1,100,A),
random_between(1,100,B),
random_between(1,10,M),
fuzzy_chunk(M,A,B,C,X,Y),
random_between(1,10,L),
fuzzy_chunk(L,C,B,_,Y,Z),
Z = Y.
% fuzzy_chunk(+Integer,+Integer,+Integer,-Integer,+Term,-Term)
fuzzy_chunk(0, A, _, A, X, X) :- !.
fuzzy_chunk(N, A, B, C, Y-D, X) :-
M is N-1,
D is A // B,
H is 10*(A - B*D),
fuzzy_chunk(M, H, B, C, Y, X).
Bye
Mild Shock schrieb:
Hi,
Rota often celebrated symbolic, analogical, and
conceptual understanding over brute calculation.
This philosophy has come full circle in modern AI:
- Large Language Models (LLMs) like GPT-4 don't
just store facts — they recognize patterns,
make analogies, and generate new structures
from old ones.
- Rota’s work in combinatorics, symbolic logic, and
operator theory is essentially pattern-based
manipulation — exactly the kind of reasoning LLMs
aim to emulate at scale.
Rota had a clear aesthetic. He valued clean formalisms,
symbolic beauty, and well-defined structures. Rota wanted
mathematics to mean something — to be not just correct,
but intelligible and expressive.
In contrast, modern AI (especially LLMs like GPT) thrives
on the messy, including: Noisy data , Inconsistency ,
Uncertainty, Contradiction. AI engineers today are mining
meaning from noise.
What counts as “structure” is often just the best
pragmatic/effective description available at that moment.
Bye
Mild Shock schrieb:
Hi,
Will the world build on American Stacks?
Or is the american dream over?
How it started, 1 month go:
Nvidia CEO Jensen Huang on AI, Musk and Trump
https://www.youtube.com/watch?v=c-XAL2oYelI
How its going, now:
Are you still talking about Jeffrey Epstein?
https://www.bbc.com/news/articles/cm2m879neljo
Bye
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
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 eitherand 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
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
you do need a theory of terms, and a specific one
Hi,
Ok I have to correct "Rational Term" was less
common, what was more in use "Rational Trees",
but they might have also talked about finitely
represented infinite tree. Rational trees itself
probably an echo from Dmitry Mirimanoffs
(1861–1945) “extraordinaire” sets.
Dmitry Semionovitch Mirimanoff (Russian:
Дми́трий Семёнович Мирима́нов; 13 September 1861, Pereslavl-Zalessky, Russia – 5 January 1945, Geneva,
Switzerland) was a member of the Moscow Mathematical
Society in 1897.[1] And later became a doctor of
mathematical sciences in 1900, in Geneva, and
taught at the universities of Geneva and Lausanne. https://en.wikipedia.org/wiki/Dmitry_Mirimanoff
This year we can again celebrate another researcher,
who died in 2023, Peter Aczel R.I.P., who made
as well some thoughtful deviance from orthodoxy.
Peter Aczel Memorial Conference on 10th September 2025.
Logic Colloquium will take place at the University
of Manchester (UK) from 11th to 12th September 2025 https://sites.google.com/view/blc2025/home
Have Fun!
Bye
Mild Shock schrieb:
Hi,
An example of human intelligence, is of course the
name "Rational Term" for cyclic terms set forth by
Alain Colmerauer. Since it plays with "Rational Numbers".
A subset of cyclic terms can indeed represent
rational numbers, and they give a nice counter
example to transitivity:
?- problem(X,Y,Z).
X = _S1-7-9-1, % where
_S1 = _S1-6-8-0-6-2-8,
Y = _S2-1-6-1-5-4-6-1, % where
_S2 = _S2-0-9-2,
Z = _S3-3-0, % where
_S3 = _S3-8-1
The Fuzzer 2 from 2025 does just what I did in 2023,
expanding rational numbers into rational terms:
% fuzzy(-Term)
fuzzy(X) :-
random_between(1,100,A),
random_between(1,100,B),
random_between(1,10,M),
fuzzy_chunk(M,A,B,C,X,Y),
random_between(1,10,L),
fuzzy_chunk(L,C,B,_,Y,Z),
Z = Y.
% fuzzy_chunk(+Integer,+Integer,+Integer,-Integer,+Term,-Term)
fuzzy_chunk(0, A, _, A, X, X) :- !.
fuzzy_chunk(N, A, B, C, Y-D, X) :-
M is N-1,
D is A // B,
H is 10*(A - B*D),
fuzzy_chunk(M, H, B, C, Y, X).
Bye
Mild Shock schrieb:
Hi,
Rota often celebrated symbolic, analogical, and
conceptual understanding over brute calculation.
This philosophy has come full circle in modern AI:
- Large Language Models (LLMs) like GPT-4 don't
just store facts — they recognize patterns,
make analogies, and generate new structures
from old ones.
- Rota’s work in combinatorics, symbolic logic, and
operator theory is essentially pattern-based
manipulation — exactly the kind of reasoning LLMs
aim to emulate at scale.
Rota had a clear aesthetic. He valued clean formalisms,
symbolic beauty, and well-defined structures. Rota wanted
mathematics to mean something — to be not just correct,
but intelligible and expressive.
In contrast, modern AI (especially LLMs like GPT) thrives
on the messy, including: Noisy data , Inconsistency ,
Uncertainty, Contradiction. AI engineers today are mining
meaning from noise.
What counts as “structure” is often just the best
pragmatic/effective description available at that moment.
Bye
Mild Shock schrieb:
Hi,
Will the world build on American Stacks?
Or is the american dream over?
How it started, 1 month go:
Nvidia CEO Jensen Huang on AI, Musk and Trump
https://www.youtube.com/watch?v=c-XAL2oYelI
How its going, now:
Are you still talking about Jeffrey Epstein?
https://www.bbc.com/news/articles/cm2m879neljo
Bye
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
seemingly interesting paper. In stead
particular, his final coa[l]gebra theorem
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 52:08:08 |
| Calls: | 12,115 |
| Calls today: | 6 |
| Files: | 15,010 |
| Messages: | 6,518,584 |
| Posted today: | 1 |