Meanwhile maintaining a JavaScript and
Python version in parallel.

The Standard Python version of Dogelog runtime
is annoyingly slow. So we gave it a try with
andother Python, and it was 6x times faster.

We could test GraalVM. We worked around the missing
match in Python 3.8 by replacing it with if-then-else.
Performance is a little better, we find:

/* Standard Python Version, Warm Run */
?- time(fibo(23,X)).
% Wall 3865 ms, gc 94 ms, 71991 lips
X = 46368.

/* GraalVM Python Version, Warm Warm Run */
?- time(fibo(23,X)).
% Wall 695 ms, gc 14 ms, 400356 lips
X = 46368.

See also:

JDK 1.8 GraalVM Python is 6x faster than Standard Python
https://twitter.com/dogelogch/status/1437395917167112193

JDK 1.8 GraalVM Python is 6x faster than Standard Python
https://www.facebook.com/groups/dogelog

Mostowski Collapse wrote:
> Dear All,
>
> Ok a simple mark and sweep works, and
> a simple trigger mechanism does the job:
>
> ANN: Dogelog Runtime, Prolog to the Moon (2021)
> https://qiita.com/j4n_bur53/items/17f86429745426bd14fd
>
> And we are 10x times faster than TauProlog! LoL
>
> Best Regards

I am not testing this use-case. But a related
use-case might highlight why speed did never
hurt anybody.

Lets say you program a flying drone with Python,
and the measurement is from the drone sensor
and communication systems.

Lets say you are using the idle time between
measurements for some complex planning. It
is then not true that you have anyway

to wait for the measurement.

Hope this helps!

BTW: If somebody knows another Python implementation
I am happy to test this implementation as well.
I am assuming that the standard Python python.exe

I tested amounts to CPython? Not sure. And the
GraalVM is practically the same as JPython? Not
sure either.

> Opinion: Anyone who is counting on Python for truly fast compute
speed is probably using Python for the wrong purpose. Here, we use
Python to control Test Equipment, to set up the equipment and ask for a
measurement, get it, and proceed to the next measurement; and at the end
produce a nice formatted report. If we wrote the test script in C or
Rust or whatever it could not run substantially faster because it is
communicating with the test equipment, setting it up and waiting for
responses, and that is where the vast majority of the time goes.
Especially if the measurement result requires averaging it can take a
while. In my opinion this is an ideal use for Python, not just because
the speed of Python is not important, but also because we can easily
find people who know Python, who like coding in Python, and will join
the company to program in Python ... and stay with us.
> --- Joseph S.

Mostowski Collapse schrieb:
> Meanwhile maintaining a JavaScript and
> Python version in parallel.
>
> The Standard Python version of Dogelog runtime
> is annoyingly slow. So we gave it a try with
> andother Python, and it was 6x times faster.
>
> We could test GraalVM. We worked around the missing
> match in Python 3.8 by replacing it with if-then-else.
> Performance is a little better, we find:
>
> /* Standard Python Version, Warm Run */
> ?- time(fibo(23,X)).
> % Wall 3865 ms, gc 94 ms, 71991 lips
> X = 46368.
>
> /* GraalVM Python Version, Warm Warm Run */
> ?- time(fibo(23,X)).
> % Wall 695 ms, gc 14 ms, 400356 lips
> X = 46368.
>
> See also:
>
> JDK 1.8 GraalVM Python is 6x faster than Standard Python
> https://twitter.com/dogelogch/status/1437395917167112193
>
> JDK 1.8 GraalVM Python is 6x faster than Standard Python
> https://www.facebook.com/groups/dogelog
>
> Mostowski Collapse wrote:
>> Dear All,
>>
>> Ok a simple mark and sweep works, and
>> a simple trigger mechanism does the job:
>>
>> ANN: Dogelog Runtime, Prolog to the Moon (2021)
>> https://qiita.com/j4n_bur53/items/17f86429745426bd14fd
>>
>> And we are 10x times faster than TauProlog! LoL
>>
>> Best Regards
>

On Wednesday, 15 September 2021 at 16:11:48 UTC+2, Mostowski Collapse wrote:

> > Opinion: Anyone who is counting on Python for truly fast compute
> speed is probably using Python for the wrong purpose.

You just don't know anything about this environment: those who need fast computation rather use *libraries* where all the performance critical parts are written in native code... and that's pretty customary in Python.

That doesn't mean Python is flawless, indeed (IMO) it isn't in so many ways: to the point that, for more professional solutions in the maths/statistics realms in particular, people rather use R: yet, the primary reason is not so not so much performance but really the solidity/structure of the language per se...

Julio

On Wednesday, 15 September 2021 at 17:46:15 UTC+2, Julio Di Egidio wrote:
> On Wednesday, 15 September 2021 at 16:11:48 UTC+2, Mostowski Collapse wrote:
>
> > > Opinion: Anyone who is counting on Python for truly fast compute
> > speed is probably using Python for the wrong purpose.
> You just don't know anything about this environment: those who need fast computation rather use *libraries* where all the performance critical parts are written in native code... and that's pretty customary in Python.
>
> That doesn't mean Python is flawless, indeed (IMO) it isn't in so many ways: to the point that, for more professional solutions in the maths/statistics realms in particular, people rather use R: yet, the primary reason is not so not so much performance but really the solidity/structure of the language per se...

Good grief, I thought we were in comp-lang-python... You are indeed just *off-topic* here: I mean, an announcement for a JS-based engine is welcome, but you posting your Python implementation diary in this group is as off-topic as it can be.

*Plonk*

Julio

I am having a cross language problem.

I really wonder why my Python implementation
is a factor 40 slower than my JavaScript implementation.
Structurally its the same code.

You can check yourself:

Python Version:
https://github.com/jburse/dogelog-moon/blob/main/devel/runtimepy/machine.py

JavaScript Version:
https://github.com/jburse/dogelog-moon/blob/main/devel/runtime/machine.js

Its the same while, if-then-else, etc.. its the same
classes Variable, Compound etc.. Maybe I could speed
it up by some details. For example to create an array
of length n, I use in Python:

temp = [NotImplemented] * code[pos]
pos += 1

Whereas in JavaScript I use, also
in exec_build2():

temp = new Array(code[pos++]);

So I hear Guido doesn't like ++. So in Python I use +=
and a separate statement as a workaround. But otherwise,
what about the creation of an array,

is the the idiom [_] * _ slow? I am assuming its
compiled away. Or does it really first create an
array of size 1 and then enlarge it?

Julio Di Egidio wrote:
> On Wednesday, 15 September 2021 at 17:46:15 UTC+2, Julio Di Egidio wrote:
>> On Wednesday, 15 September 2021 at 16:11:48 UTC+2, Mostowski Collapse wrote:
>>
>>>> Opinion: Anyone who is counting on Python for truly fast compute
>>> speed is probably using Python for the wrong purpose.
>> You just don't know anything about this environment: those who need fast computation rather use *libraries* where all the performance critical parts are written in native code... and that's pretty customary in Python.
>>
>> That doesn't mean Python is flawless, indeed (IMO) it isn't in so many ways: to the point that, for more professional solutions in the maths/statistics realms in particular, people rather use R: yet, the primary reason is not so not so much performance but really the solidity/structure of the language per se...
>
> Good grief, I thought we were in comp-lang-python... You are indeed just *off-topic* here: I mean, an announcement for a JS-based engine is welcome, but you posting your Python implementation diary in this group is as off-topic as it can be.
>
> *Plonk*
>
> Julio
>

A friend just sent me a Web Sudoku made with Dogelog Runtime
https://gist.github.com/jburse/c85297e97091caf22d306dd8c8be12fe#gistcomment-3895696

LoL

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 18:49:11 UTC+2:
> I am having a cross language problem.
>
> I really wonder why my Python implementation
> is a factor 40 slower than my JavaScript implementation.
> Structurally its the same code.
>
> You can check yourself:
>
> Python Version:
> https://github.com/jburse/dogelog-moon/blob/main/devel/runtimepy/machine.py
>
> JavaScript Version:
> https://github.com/jburse/dogelog-moon/blob/main/devel/runtime/machine.js
>
> Its the same while, if-then-else, etc.. its the same
> classes Variable, Compound etc.. Maybe I could speed
> it up by some details. For example to create an array
> of length n, I use in Python:
>
> temp = [NotImplemented] * code[pos]
> pos += 1
>
> Whereas in JavaScript I use, also
> in exec_build2():
>
> temp = new Array(code[pos++]);
>
> So I hear Guido doesn't like ++. So in Python I use +=
> and a separate statement as a workaround. But otherwise,
> what about the creation of an array,
>
> is the the idiom [_] * _ slow? I am assuming its
> compiled away. Or does it really first create an
> array of size 1 and then enlarge it?
> Julio Di Egidio wrote:
> > On Wednesday, 15 September 2021 at 17:46:15 UTC+2, Julio Di Egidio wrote:
> >> On Wednesday, 15 September 2021 at 16:11:48 UTC+2, Mostowski Collapse wrote:
> >>
> >>>> Opinion: Anyone who is counting on Python for truly fast compute
> >>> speed is probably using Python for the wrong purpose.
> >> You just don't know anything about this environment: those who need fast computation rather use *libraries* where all the performance critical parts are written in native code... and that's pretty customary in Python.
> >>
> >> That doesn't mean Python is flawless, indeed (IMO) it isn't in so many ways: to the point that, for more professional solutions in the maths/statistics realms in particular, people rather use R: yet, the primary reason is not so not so much performance but really the solidity/structure of the language per se...
> >
> > Good grief, I thought we were in comp-lang-python... You are indeed just *off-topic* here: I mean, an announcement for a JS-based engine is welcome, but you posting your Python implementation diary in this group is as off-topic as it can be.
> >
> > *Plonk*
> >
> > Julio
> >

The new release 0.9.6 is quite speedy:

"Maailman vaikein"
850002400720000009004000000000107002305000900040000000000080070017000000000036040
time(solve(Puzzle))
% Wall 41354 ms, gc 520 ms, 3143029 lips
in Browser

See also:

Preview: New para/1 instruction for Dogelog runtime. (Jekejeke)
https://twitter.com/dogelogch/status/1438586282502983682

Preview: New para/1 instruction for Dogelog runtime. (Jekejeke)
https://www.facebook.com/groups/dogelog

Mostowski Collapse schrieb am Donnerstag, 16. September 2021 um 22:27:41 UTC+2:
> A friend just sent me a Web Sudoku made with Dogelog Runtime
> https://gist.github.com/jburse/c85297e97091caf22d306dd8c8be12fe#gistcomment-3895696
>
> LoL
> Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 18:49:11 UTC+2:
> > I am having a cross language problem.
> >
> > I really wonder why my Python implementation
> > is a factor 40 slower than my JavaScript implementation.
> > Structurally its the same code.
> >
> > You can check yourself:
> >
> > Python Version:
> > https://github.com/jburse/dogelog-moon/blob/main/devel/runtimepy/machine.py
> >
> > JavaScript Version:
> > https://github.com/jburse/dogelog-moon/blob/main/devel/runtime/machine.js
> >
> > Its the same while, if-then-else, etc.. its the same
> > classes Variable, Compound etc.. Maybe I could speed
> > it up by some details. For example to create an array
> > of length n, I use in Python:
> >
> > temp = [NotImplemented] * code[pos]
> > pos += 1
> >
> > Whereas in JavaScript I use, also
> > in exec_build2():
> >
> > temp = new Array(code[pos++]);
> >
> > So I hear Guido doesn't like ++. So in Python I use +=
> > and a separate statement as a workaround. But otherwise,
> > what about the creation of an array,
> >
> > is the the idiom [_] * _ slow? I am assuming its
> > compiled away. Or does it really first create an
> > array of size 1 and then enlarge it?
> > Julio Di Egidio wrote:
> > > On Wednesday, 15 September 2021 at 17:46:15 UTC+2, Julio Di Egidio wrote:
> > >> On Wednesday, 15 September 2021 at 16:11:48 UTC+2, Mostowski Collapse wrote:
> > >>
> > >>>> Opinion: Anyone who is counting on Python for truly fast compute
> > >>> speed is probably using Python for the wrong purpose.
> > >> You just don't know anything about this environment: those who need fast computation rather use *libraries* where all the performance critical parts are written in native code... and that's pretty customary in Python.
> > >>
> > >> That doesn't mean Python is flawless, indeed (IMO) it isn't in so many ways: to the point that, for more professional solutions in the maths/statistics realms in particular, people rather use R: yet, the primary reason is not so not so much performance but really the solidity/structure of the language per se...
> > >
> > > Good grief, I thought we were in comp-lang-python... You are indeed just *off-topic* here: I mean, an announcement for a JS-based engine is welcome, but you posting your Python implementation diary in this group is as off-topic as it can be.
> > >
> > > *Plonk*
> > >
> > > Julio
> > >

Do you say Python should not be used to implement
such things? In my opinion, Python has a high potential
to implement Prolog, because it has also ast.parse()

and compile(). But I do not yet have a showcase that uses
these features of Python to compile Prolog. I dont work 24/7
and I cannot clone myself. Currently the Prolog code is interpreted.

I have a prototype where Prolog code is compiled into JavaScript,
but I did not yet try this approach with Python. Here you see how
JavaScript closures are generated, a first prototype:

const alt4 = make_defined([new Clause(1, [0, 0], function(
display, actual, cont) {return(new Compound(".", [new Compound(
"==", [deref(actual.args[0]), "end_of_file"]), new Compound(
".", [new Compound("$CUT", [deref(display[0])]), cont
])]))}, 0, undefined), new Clause(1, [0, 0], function(
display, actual, cont) {return(new Compound(".", [new Compound(
"expand_include", [deref(actual.args[0]), deref(actual.args[1]
), display[0] = new Variable()]), new Compound(".",
[new Compound("handle_term", [deref(display[0])]), new Compound(
".", ["fail", cont])])]))}, -1, undefined)]);

add("next_term", 1, new Clause(2, [0], function(display, actual,
cont) {return(new Compound(".", [new Compound("read_term",
[deref(actual.args[0]), display[0] = new Variable(),
new Compound(".", [new Compound("variable_names", [
display[1] = new Variable()]), "[]"])]), new Compound(
".", [new Compound(alt4, [deref(display[0]), deref(
display[1])]), cont])]))}, -1, undefined));

https://github.com/jburse/dogelog-moon/issues/184

Will do the same for Python in the next weeks. Then later this approach
will be combined with a few planned optimizations. So far got a 25%
speed increase for JavaScript with this new compilation scheme, but

there is no official release out yet, that features this approach. And
there should be much more in it, also for Python.

On 19/09/2021 21:28, Mostowski Collapse wrote:

<snip>
> const alt4 = make_defined([new Clause(1, [0, 0], function(
> display, actual, cont) {return(new Compound(".", [new Compound(
> "==", [deref(actual.args[0]), "end_of_file"]), new Compound(
> ".", [new Compound("$CUT", [deref(display[0])]), cont
> ])]))}, 0, undefined), new Clause(1, [0, 0], function(
> display, actual, cont) {return(new Compound(".", [new Compound(
> "expand_include", [deref(actual.args[0]), deref(actual.args[1]
> ), display[0] = new Variable()]), new Compound(".",
> [new Compound("handle_term", [deref(display[0])]), new Compound(
> ".", ["fail", cont])])]))}, -1, undefined)]);
>
> add("next_term", 1, new Clause(2, [0], function(display, actual,
> cont) {return(new Compound(".", [new Compound("read_term",
> [deref(actual.args[0]), display[0] = new Variable(),
> new Compound(".", [new Compound("variable_names", [
> display[1] = new Variable()]), "[]"])]), new Compound(
> ".", [new Compound(alt4, [deref(display[0]), deref(
> display[1])]), cont])]))}, -1, undefined));
<snip>

Please don't show us unreadable code.

John

Its not supposed to be readable. Its machine generated.

John Harris schrieb am Montag, 20. September 2021 um 19:11:49 UTC+2:
> On 19/09/2021 21:28, Mostowski Collapse wrote:
>
> <snip>
> > const alt4 = make_defined([new Clause(1, [0, 0], function(
> > display, actual, cont) {return(new Compound(".", [new Compound(
> > "==", [deref(actual.args[0]), "end_of_file"]), new Compound(
> > ".", [new Compound("$CUT", [deref(display[0])]), cont
> > ])]))}, 0, undefined), new Clause(1, [0, 0], function(
> > display, actual, cont) {return(new Compound(".", [new Compound(
> > "expand_include", [deref(actual.args[0]), deref(actual.args[1]
> > ), display[0] = new Variable()]), new Compound(".",
> > [new Compound("handle_term", [deref(display[0])]), new Compound(
> > ".", ["fail", cont])])]))}, -1, undefined)]);
> >
> > add("next_term", 1, new Clause(2, [0], function(display, actual,
> > cont) {return(new Compound(".", [new Compound("read_term",
> > [deref(actual.args[0]), display[0] = new Variable(),
> > new Compound(".", [new Compound("variable_names", [
> > display[1] = new Variable()]), "[]"])]), new Compound(
> > ".", [new Compound(alt4, [deref(display[0]), deref(
> > display[1])]), cont])]))}, -1, undefined));
> <snip>
>
> Please don't show us unreadable code.
>
> John

Woa! There is some competition for JavaScript and
node.exe. PyPy is faster! Faster than GraalVM. Now
I get for my usual Python benchmark, figures in
milliseconds:

Standard GraalVM PyPy
170'996 28'523 9'755

Not bad. Only like 2x times slower than node.exe.
Now imaging I can realize the ast.parse() and
compile() idea as well! (Made an experiment
today, testing some corner with evaluation)

BTW: Here the full results. Was using:
pypy3.7-v7.3.5-win64\pypy3.exe

Test Standard GraalVM PyPy
nrev 20'389 3'611 1'254
crypt 17'103 3'248 960
deriv 20'808 3'111 1'250
poly 17'518 3'045 1'149
qsort 20'191 3'243 1'127
tictac 13'761 2'469 783
queens 17'691 3'242 1'024
query 6'161 1'155 313
mtak 17'209 2'300 907
perfect 20'165 3'099 988
calc N/A N/A N/A
Total 170'996 28'523 9'755

Mostowski Collapse schrieb am Montag, 20. September 2021 um 20:04:42 UTC+2:
> Its not supposed to be readable. Its machine generated.
> John Harris schrieb am Montag, 20. September 2021 um 19:11:49 UTC+2:
> > On 19/09/2021 21:28, Mostowski Collapse wrote:
> >
> > <snip>
> > > const alt4 = make_defined([new Clause(1, [0, 0], function(
> > > display, actual, cont) {return(new Compound(".", [new Compound(
> > > "==", [deref(actual.args[0]), "end_of_file"]), new Compound(
> > > ".", [new Compound("$CUT", [deref(display[0])]), cont
> > > ])]))}, 0, undefined), new Clause(1, [0, 0], function(
> > > display, actual, cont) {return(new Compound(".", [new Compound(
> > > "expand_include", [deref(actual.args[0]), deref(actual.args[1]
> > > ), display[0] = new Variable()]), new Compound(".",
> > > [new Compound("handle_term", [deref(display[0])]), new Compound(
> > > ".", ["fail", cont])])]))}, -1, undefined)]);
> > >
> > > add("next_term", 1, new Clause(2, [0], function(display, actual,
> > > cont) {return(new Compound(".", [new Compound("read_term",
> > > [deref(actual.args[0]), display[0] = new Variable(),
> > > new Compound(".", [new Compound("variable_names", [
> > > display[1] = new Variable()]), "[]"])]), new Compound(
> > > ".", [new Compound(alt4, [deref(display[0]), deref(
> > > display[1])]), cont])]))}, -1, undefined));
> > <snip>
> >
> > Please don't show us unreadable code.
> >
> > John

A nice project could now be to redo this one,
see how the prover would perform:

FLiP, a Logical Framework in Python
http://staff.washington.edu/jon/flip/www/index.html

The prover is listed here:

Proof checkers - Joseph Vidal-Rosset
https://www.vidal-rosset.net/proof_checkers.html

Ha Ha, the prover was just right in front of my nose
all the time. But before venturing into such a quest,
need to add occurs check to the Dogelog runtime.

I had some very good dynamic optimization for
occurs check in Jekejeke Prolog, but for Dogelog
runtime everything is new, need to figure out what

optimizations could be applied there. There is a ticket
for occurs check already on GitHub:

Bring occurs check to Dogelog runtime #143
https://github.com/jburse/dogelog-moon/issues/143

Mostowski Collapse schrieb am Dienstag, 21. September 2021 um 00:16:38 UTC+2:
> Woa! There is some competition for JavaScript and
> node.exe. PyPy is faster! Faster than GraalVM. Now
> I get for my usual Python benchmark, figures in
> milliseconds:
>
> Standard GraalVM PyPy
> 170'996 28'523 9'755
>
> Not bad. Only like 2x times slower than node.exe.
> Now imaging I can realize the ast.parse() and
> compile() idea as well! (Made an experiment
> today, testing some corner with evaluation)
>
> BTW: Here the full results. Was using:
> pypy3.7-v7.3.5-win64\pypy3.exe
>
> Test Standard GraalVM PyPy
> nrev 20'389 3'611 1'254
> crypt 17'103 3'248 960
> deriv 20'808 3'111 1'250
> poly 17'518 3'045 1'149
> qsort 20'191 3'243 1'127
> tictac 13'761 2'469 783
> queens 17'691 3'242 1'024
> query 6'161 1'155 313
> mtak 17'209 2'300 907
> perfect 20'165 3'099 988
> calc N/A N/A N/A
> Total 170'996 28'523 9'755
> Mostowski Collapse schrieb am Montag, 20. September 2021 um 20:04:42 UTC+2:
> > Its not supposed to be readable. Its machine generated.
> > John Harris schrieb am Montag, 20. September 2021 um 19:11:49 UTC+2:
> > > On 19/09/2021 21:28, Mostowski Collapse wrote:
> > >
> > > <snip>
> > > > const alt4 = make_defined([new Clause(1, [0, 0], function(
> > > > display, actual, cont) {return(new Compound(".", [new Compound(
> > > > "==", [deref(actual.args[0]), "end_of_file"]), new Compound(
> > > > ".", [new Compound("$CUT", [deref(display[0])]), cont
> > > > ])]))}, 0, undefined), new Clause(1, [0, 0], function(
> > > > display, actual, cont) {return(new Compound(".", [new Compound(
> > > > "expand_include", [deref(actual.args[0]), deref(actual.args[1]
> > > > ), display[0] = new Variable()]), new Compound(".",
> > > > [new Compound("handle_term", [deref(display[0])]), new Compound(
> > > > ".", ["fail", cont])])]))}, -1, undefined)]);
> > > >
> > > > add("next_term", 1, new Clause(2, [0], function(display, actual,
> > > > cont) {return(new Compound(".", [new Compound("read_term",
> > > > [deref(actual.args[0]), display[0] = new Variable(),
> > > > new Compound(".", [new Compound("variable_names", [
> > > > display[1] = new Variable()]), "[]"])]), new Compound(
> > > > ".", [new Compound(alt4, [deref(display[0]), deref(
> > > > display[1])]), cont])]))}, -1, undefined));
> > > <snip>
> > >
> > > Please don't show us unreadable code.
> > >
> > > John

That I get censored on Python pipermail, is possibly an
out burst of taking Python too literal, like here:

Monty Python - She's a witch!
https://www.youtube.com/watch?v=zrzMhU_4m-g

But we can turn this into a FLiP, a Logical Framework in Python exercise:

"There are ways of telling whether she's a witch."
"What do you do with witches?" "Burn them!"
Ax.(Witch(x) -> Burn(x)) (1) Given
"Why do witches burn?" "'Cause they're made of wood!"
Ax.(Wood(x) -> Witch(x)) (2) Given
"How do we tell if she's made of wood?" "Does wood sink in water?" "It floats!"
Ax.(Floats(x) -> Wood(x)) (3) Given
"What also floats in water?" "A duck!"
Floats(duck) (4) Given
"Exactly! So, logically ..."
"If she weights the same as a duck, she's made of wood!"
Ax.Ay.((Floats(x) & (weight(x) = weight(y))) -> Floats(y)) (5) Given
"We shall use my largest scales. ... Remove the supports!"
weight(duck) = weight(girl) (6) Given
Ay.((Floats(duck) & (weight(duck) = weight(y))) -> Floats(y)) (7) A-Elimination (5)
(Floats(duck) & (weight(duck) = weight(girl))) -> Floats(girl) (8) A-Elimination (7)
Floats(duck) & (weight(duck) = weight(girl)) (9) And-Introduction (4) (6)
Floats(girl) (10) Implication-Elimination (Modus Ponens) (8) (9)
Floats(girl) -> Wood(girl) (11) A-Elimination (3)
Wood(girl) (12) Implication-Elimination (Modus Ponens) (11) (10)
"A witch! A witch!"
Wood(girl) -> Witch(girl) (13) A-Elimination (2)
Witch(girl) (14) Implication-Elimination (Modus Ponens) (13) (12)
"Burn her! Burn!"
Witch(girl) -> Burn(girl) (15) A-Elimination (1)
Burn(girl) (16) Implication-Elimination (Modus Ponens) (15) (14)
http://staff.washington.edu/jon/flip/www/witch.html

Mostowski Collapse schrieb am Donnerstag, 23. September 2021 um 18:19:53 UTC+2:
> A nice project could now be to redo this one,
> see how the prover would perform:
>
> FLiP, a Logical Framework in Python
> http://staff.washington.edu/jon/flip/www/index.html
>
> The prover is listed here:
>
> Proof checkers - Joseph Vidal-Rosset
> https://www.vidal-rosset.net/proof_checkers.html
>
> Ha Ha, the prover was just right in front of my nose
> all the time. But before venturing into such a quest,
> need to add occurs check to the Dogelog runtime.
>
> I had some very good dynamic optimization for
> occurs check in Jekejeke Prolog, but for Dogelog
> runtime everything is new, need to figure out what
>
> optimizations could be applied there. There is a ticket
> for occurs check already on GitHub:
>
> Bring occurs check to Dogelog runtime #143
> https://github.com/jburse/dogelog-moon/issues/143
> Mostowski Collapse schrieb am Dienstag, 21. September 2021 um 00:16:38 UTC+2:
> > Woa! There is some competition for JavaScript and
> > node.exe. PyPy is faster! Faster than GraalVM. Now
> > I get for my usual Python benchmark, figures in
> > milliseconds:
> >
> > Standard GraalVM PyPy
> > 170'996 28'523 9'755
> >
> > Not bad. Only like 2x times slower than node.exe.
> > Now imaging I can realize the ast.parse() and
> > compile() idea as well! (Made an experiment
> > today, testing some corner with evaluation)
> >
> > BTW: Here the full results. Was using:
> > pypy3.7-v7.3.5-win64\pypy3.exe
> >
> > Test Standard GraalVM PyPy
> > nrev 20'389 3'611 1'254
> > crypt 17'103 3'248 960
> > deriv 20'808 3'111 1'250
> > poly 17'518 3'045 1'149
> > qsort 20'191 3'243 1'127
> > tictac 13'761 2'469 783
> > queens 17'691 3'242 1'024
> > query 6'161 1'155 313
> > mtak 17'209 2'300 907
> > perfect 20'165 3'099 988
> > calc N/A N/A N/A
> > Total 170'996 28'523 9'755
> > Mostowski Collapse schrieb am Montag, 20. September 2021 um 20:04:42 UTC+2:
> > > Its not supposed to be readable. Its machine generated.
> > > John Harris schrieb am Montag, 20. September 2021 um 19:11:49 UTC+2:
> > > > On 19/09/2021 21:28, Mostowski Collapse wrote:
> > > >
> > > > <snip>
> > > > > const alt4 = make_defined([new Clause(1, [0, 0], function(
> > > > > display, actual, cont) {return(new Compound(".", [new Compound(
> > > > > "==", [deref(actual.args[0]), "end_of_file"]), new Compound(
> > > > > ".", [new Compound("$CUT", [deref(display[0])]), cont
> > > > > ])]))}, 0, undefined), new Clause(1, [0, 0], function(
> > > > > display, actual, cont) {return(new Compound(".", [new Compound(
> > > > > "expand_include", [deref(actual.args[0]), deref(actual.args[1]
> > > > > ), display[0] = new Variable()]), new Compound(".",
> > > > > [new Compound("handle_term", [deref(display[0])]), new Compound(
> > > > > ".", ["fail", cont])])]))}, -1, undefined)]);
> > > > >
> > > > > add("next_term", 1, new Clause(2, [0], function(display, actual,
> > > > > cont) {return(new Compound(".", [new Compound("read_term",
> > > > > [deref(actual.args[0]), display[0] = new Variable(),
> > > > > new Compound(".", [new Compound("variable_names", [
> > > > > display[1] = new Variable()]), "[]"])]), new Compound(
> > > > > ".", [new Compound(alt4, [deref(display[0]), deref(
> > > > > display[1])]), cont])]))}, -1, undefined));
> > > > <snip>
> > > >
> > > > Please don't show us unreadable code.
> > > >
> > > > John

In reference to:
https://groups.google.com/g/comp.lang.python/c/-F7dLYmN9sM/m/lN1rwbIgAgAJ

Mark Lawrence is also not visible on pipermail? Ha Ha, thats
the problem with this censoring, its like cherry picking, allmost
like the aledged organ trade in republic of china, We now

have the case that somebody picked up some link via another
Python channel, like the uncensored google groups, but on the
pipermail channel even the original link is not visible.

The annoying thing nowadays, you don't get an email anymore
that tells you "We are sorry, but we have banned you", this would
be too flattering and possibly make you famous, it all works now

under the hood as reported here:

What Are Shadowbans?
Shadowbans block a user or individual pieces of content
without letting the offending user know they’ve been blocked.
https://builtin.com/marketing/shadowban

I must admit, I have applauded when Donald Trump was
banned from twitter, but this "management" of programming
language groups gets ridiculous.

Mostowski Collapse schrieb am Donnerstag, 23. September 2021 um 18:39:58 UTC+2:
> That I get censored on Python pipermail, is possibly an
> out burst of taking Python too literal, like here:
>
> Monty Python - She's a witch!
> https://www.youtube.com/watch?v=zrzMhU_4m-g
>
> But we can turn this into a FLiP, a Logical Framework in Python exercise:
>
> "There are ways of telling whether she's a witch."
> "What do you do with witches?" "Burn them!"
> Ax.(Witch(x) -> Burn(x)) (1) Given
> "Why do witches burn?" "'Cause they're made of wood!"
> Ax.(Wood(x) -> Witch(x)) (2) Given
> "How do we tell if she's made of wood?" "Does wood sink in water?" "It floats!"
> Ax.(Floats(x) -> Wood(x)) (3) Given
> "What also floats in water?" "A duck!"
> Floats(duck) (4) Given
> "Exactly! So, logically ..."
> "If she weights the same as a duck, she's made of wood!"
> Ax.Ay.((Floats(x) & (weight(x) = weight(y))) -> Floats(y)) (5) Given
> "We shall use my largest scales. ... Remove the supports!"
> weight(duck) = weight(girl) (6) Given
> Ay.((Floats(duck) & (weight(duck) = weight(y))) -> Floats(y)) (7) A-Elimination (5)
> (Floats(duck) & (weight(duck) = weight(girl))) -> Floats(girl) (8) A-Elimination (7)
> Floats(duck) & (weight(duck) = weight(girl)) (9) And-Introduction (4) (6)
> Floats(girl) (10) Implication-Elimination (Modus Ponens) (8) (9)
> Floats(girl) -> Wood(girl) (11) A-Elimination (3)
> Wood(girl) (12) Implication-Elimination (Modus Ponens) (11) (10)
> "A witch! A witch!"
> Wood(girl) -> Witch(girl) (13) A-Elimination (2)
> Witch(girl) (14) Implication-Elimination (Modus Ponens) (13) (12)
> "Burn her! Burn!"
> Witch(girl) -> Burn(girl) (15) A-Elimination (1)
> Burn(girl) (16) Implication-Elimination (Modus Ponens) (15) (14)
> http://staff.washington.edu/jon/flip/www/witch.html
> Mostowski Collapse schrieb am Donnerstag, 23. September 2021 um 18:19:53 UTC+2:
> > A nice project could now be to redo this one,
> > see how the prover would perform:
> >
> > FLiP, a Logical Framework in Python
> > http://staff.washington.edu/jon/flip/www/index.html
> >
> > The prover is listed here:
> >
> > Proof checkers - Joseph Vidal-Rosset
> > https://www.vidal-rosset.net/proof_checkers.html
> >
> > Ha Ha, the prover was just right in front of my nose
> > all the time. But before venturing into such a quest,
> > need to add occurs check to the Dogelog runtime.
> >
> > I had some very good dynamic optimization for
> > occurs check in Jekejeke Prolog, but for Dogelog
> > runtime everything is new, need to figure out what
> >
> > optimizations could be applied there. There is a ticket
> > for occurs check already on GitHub:
> >
> > Bring occurs check to Dogelog runtime #143
> > https://github.com/jburse/dogelog-moon/issues/143
> > Mostowski Collapse schrieb am Dienstag, 21. September 2021 um 00:16:38 UTC+2:
> > > Woa! There is some competition for JavaScript and
> > > node.exe. PyPy is faster! Faster than GraalVM. Now
> > > I get for my usual Python benchmark, figures in
> > > milliseconds:
> > >
> > > Standard GraalVM PyPy
> > > 170'996 28'523 9'755
> > >
> > > Not bad. Only like 2x times slower than node.exe.
> > > Now imaging I can realize the ast.parse() and
> > > compile() idea as well! (Made an experiment
> > > today, testing some corner with evaluation)
> > >
> > > BTW: Here the full results. Was using:
> > > pypy3.7-v7.3.5-win64\pypy3.exe
> > >
> > > Test Standard GraalVM PyPy
> > > nrev 20'389 3'611 1'254
> > > crypt 17'103 3'248 960
> > > deriv 20'808 3'111 1'250
> > > poly 17'518 3'045 1'149
> > > qsort 20'191 3'243 1'127
> > > tictac 13'761 2'469 783
> > > queens 17'691 3'242 1'024
> > > query 6'161 1'155 313
> > > mtak 17'209 2'300 907
> > > perfect 20'165 3'099 988
> > > calc N/A N/A N/A
> > > Total 170'996 28'523 9'755
> > > Mostowski Collapse schrieb am Montag, 20. September 2021 um 20:04:42 UTC+2:
> > > > Its not supposed to be readable. Its machine generated.
> > > > John Harris schrieb am Montag, 20. September 2021 um 19:11:49 UTC+2:
> > > > > On 19/09/2021 21:28, Mostowski Collapse wrote:
> > > > >
> > > > > <snip>
> > > > > > const alt4 = make_defined([new Clause(1, [0, 0], function(
> > > > > > display, actual, cont) {return(new Compound(".", [new Compound(
> > > > > > "==", [deref(actual.args[0]), "end_of_file"]), new Compound(
> > > > > > ".", [new Compound("$CUT", [deref(display[0])]), cont
> > > > > > ])]))}, 0, undefined), new Clause(1, [0, 0], function(
> > > > > > display, actual, cont) {return(new Compound(".", [new Compound(
> > > > > > "expand_include", [deref(actual.args[0]), deref(actual.args[1]
> > > > > > ), display[0] = new Variable()]), new Compound(".",
> > > > > > [new Compound("handle_term", [deref(display[0])]), new Compound(
> > > > > > ".", ["fail", cont])])]))}, -1, undefined)]);
> > > > > >
> > > > > > add("next_term", 1, new Clause(2, [0], function(display, actual,
> > > > > > cont) {return(new Compound(".", [new Compound("read_term",
> > > > > > [deref(actual.args[0]), display[0] = new Variable(),
> > > > > > new Compound(".", [new Compound("variable_names", [
> > > > > > display[1] = new Variable()]), "[]"])]), new Compound(
> > > > > > ".", [new Compound(alt4, [deref(display[0]), deref(
> > > > > > display[1])]), cont])]))}, -1, undefined));
> > > > > <snip>
> > > > >
> > > > > Please don't show us unreadable code.
> > > > >
> > > > > John