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

Groups > comp.lang.javascript > #40030 > unrolled thread

ANN: Dogelog Runtime, Prolog to the Moon (2021)

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

Contents

  ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <janburse@fastmail.fm> - 2021-05-02 23:05 +0200
    Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mina Arvuti lähedal <ya12983@mail.com> - 2021-05-25 18:44 -0700
    Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <janburse@fastmail.fm> - 2021-06-09 14:59 +0200
    Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-06-12 16:59 -0700
      Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-06-12 17:01 -0700
        Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-06-17 01:45 -0700
          Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <janburse@fastmail.fm> - 2021-06-23 14:57 +0200
            Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-06-25 04:00 -0700
              Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-06-25 05:02 -0700
                Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-07-10 16:50 -0700
                  Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-07-12 01:04 -0700
                    Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-08-02 09:48 -0700
                      Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-08-11 08:28 -0700
                        Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-08-12 10:40 -0700
                          Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-08-12 10:42 -0700
                            Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-08-14 06:04 -0700
                              Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-09-02 09:38 -0700
                                Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-09-05 05:13 -0700
    Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <janburse@fastmail.fm> - 2021-09-13 17:09 +0200
      Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <janburse@fastmail.fm> - 2021-09-15 16:11 +0200
        Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Julio Di Egidio <julio@diegidio.name> - 2021-09-15 08:46 -0700
          Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Julio Di Egidio <julio@diegidio.name> - 2021-09-15 08:49 -0700
            Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <janburse@fastmail.fm> - 2021-09-15 18:49 +0200
              Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-09-16 13:27 -0700
                Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-09-16 14:48 -0700
                  Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-09-19 13:28 -0700
                    Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) John Harris <niam@jghnorth.org.uk.invalid> - 2021-09-20 18:11 +0100
                      Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-09-20 11:04 -0700
                        Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-09-20 15:16 -0700
                          Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-09-23 09:19 -0700
                            Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-09-23 09:39 -0700
                              Re: ANN: Dogelog Runtime, Prolog to the Moon (2021) Mostowski Collapse <bursejan@gmail.com> - 2021-09-24 06:19 -0700

Page 2 of 2 — ← Prev page 1 [2]

#40382

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

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

#40383

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

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

#40384

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
> 

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

#40385

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 
> >

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

#40386

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 
> > >

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

#40393

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.

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

#40395

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

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

#40396

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

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

#40397

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

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

#40410

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

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

#40411

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

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

#40414

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web