The code version of python -i

[Abdur-Rahmaan Janhangeer]

Greetings,

If i have a file name flower.py and i add x = 1 in it.
When i run python -i flower.py i get a shell
>>>

If type x i get 1
>>> x
1

The values are auto injected.

How do i start a shell by code with values already injected? Thanks

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The code version of python -i

[Peter Otten]

On 15/09/2021 15:39, Abdur-Rahmaan Janhangeer wrote:

Greetings,

If i have a file name flower.py and i add x = 1 in it.
When i run python -i flower.py i get a shell




If type x i get 1

x

1

The values are auto injected.

How do i start a shell by code with values already injected? Thanks

Kind Regards,


I tried

import code

x = 42
code.interact(local=globals())

but didn't bother to read the documentation at

https://docs.python.org/3/library/code.html

and thus do not know what the limitations might be.

--
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

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.


--
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

Oops "speed did never hurt anybody". Don't be
evil, I am talking about unarmed drones.

See also:

Drone Programming With Python Course
https://www.youtube.com/watch?v=LmEcyQnfpDA

Mostowski Collapse schrieb:

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.




--
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

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 15:37:19 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.

By that I don'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 
much performance but really the solidity/structure of the language per se...

Julio



--
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Thu, Sep 16, 2021 at 3:17 AM Mostowski Collapse  wrote:
>
> I really wonder why my Python implementation
> is a factor 40 slower than my JavaScript implementation.
> Structurally its the same code.
>

Very hard to know. Your code is detailed and complicated. Do they
produce identical results? Are you using the same sort of
floating-point data everywhere, or is one integer and the other float?
What's going on with all the globals, the continuations, etc? My
suspicion is that you're trying to write weird, wonky Python code, and
then are surprised that it doesn't perform well.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[alister via Python-list]

On Thu, 16 Sep 2021 03:26:39 +1000, Chris Angelico wrote:

> On Thu, Sep 16, 2021 at 3:17 AM Mostowski Collapse
>  wrote:
>>
>> I really wonder why my Python implementation is a factor 40 slower than
>> my JavaScript implementation.
>> Structurally its the same code.
>>
>>
> Very hard to know. Your code is detailed and complicated. Do they
> produce identical results? Are you using the same sort of floating-point
> data everywhere, or is one integer and the other float?
> What's going on with all the globals, the continuations, etc? My
> suspicion is that you're trying to write weird, wonky Python code, and
> then are surprised that it doesn't perform well.
> 
> ChrisA

And this demonstrates how an experienced Python programmer can make an 
almost spot on diagnosis without even checking the source code.

@ this stage I would recommend watching some presentations on you tube

this one https://www.youtube.com/watch?v=wf-BqAjZb8M by Raymond Hettinger 
is brilliant as it highlights there is more to checking code than just 
making sure it looks nice & runs correctly.



-- 
Lemmings don't grow older, they just die.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

If you find a "wonky" spot, I can replace it by "non-wonky"
code. I noticed some differences between Python Dicts
and JavaScript objects. Python tends to throw more exceptions.

So in Python I now do the following:

   peek = kb.get(functor, NotImplemented)
   if peek is not NotImplemented:

In JavaScript I can directly do:

peek = kb[functor];
if (peek !== undefined)

But if get() in Python is implemented under the hood with
exception handling. i.e. using the exception prone [] and
then in case an exception is thrown, returning the

default value, then Python get() will probably be quite slow.
Since usually exceptions are slow.

Chris Angelico schrieb am Mittwoch, 15. September 2021 um 19:27:13 UTC+2:
> On Thu, Sep 16, 2021 at 3:17 AM Mostowski Collapse  
> wrote: 
> > 
> > I really wonder why my Python implementation 
> > is a factor 40 slower than my JavaScript implementation. 
> > Structurally its the same code. 
> >
> Very hard to know. Your code is detailed and complicated. Do they 
> produce identical results? Are you using the same sort of 
> floating-point data everywhere, or is one integer and the other float? 
> What's going on with all the globals, the continuations, etc? My 
> suspicion is that you're trying to write weird, wonky Python code, and 
> then are surprised that it doesn't perform well. 
> 
> ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

Do you mean, replace this:

i = 0
while i < len(term.args) - 1:
mark_term(term.args[i])
i += 1
term = term.args[i] 

By this:

for i,term in enumerate(term.args):
mark_term(term.args[i]) 

This wouldn't be correct anymore. The
recursive call is only for the arguments
except for the last one one. 

alister schrieb am Mittwoch, 15. September 2021 um 20:17:23 UTC+2:
> On Wed, 15 Sep 2021 18:23:10 +0200, Mostowski Collapse wrote: 
> 
> > 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:
>  
> 
> this is probably a string contender 
> 
> i = 0 
> while i < len(term.args) - 1: 
> mark_term(term.args[i]) 
> i += 1 
> term = term.args[i] 
> 
> try replacing with something more pythonic 
> 
> for index,term in enumerate(term.args): 
> mark_term(term.args[i]) 
> 
> 
> & possibly go all the way to changing it into a comprehension 
> 
> there are other similar anti patterns throughout this code. 
> 
> any time you are manually keeping a counter as an index into a list,tupple 
> other iterable YOU ARE DOING IT WRONG! 
> 
> Do not write javascript in python, write python 
> 
> 
> 
> -- 
> Two percent of zero is almost nothing. 
> 
> 
> 
> 
> -- 
> Whoever dies with the most toys wins.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[alister via Python-list]

On Wed, 15 Sep 2021 18:23:10 +0200, Mostowski Collapse wrote:

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


this is probably a string contender

i = 0
while i < len(term.args) - 1:
mark_term(term.args[i])
i += 1
term = term.args[i]

try replacing with something more pythonic

for index,term in enumerate(term.args):
 mark_term(term.args[i])


& possibly go all the way to changing it into a comprehension

there are other similar anti patterns throughout this code.

any time you are manually keeping a counter as an index into a list,tupple 
other iterable YOU ARE DOING IT WRONG!

Do not write javascript in python, write python



-- 
Two percent of zero is almost nothing.




-- 
Whoever dies with the most toys wins.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The code version of python -i

[Dennis Lee Bieber]

On Wed, 15 Sep 2021 16:08:32 +0200, Peter Otten <__pete...@web.de>
declaimed the following:

>
>I tried
>
>import code
>
>x = 42
>code.interact(local=globals())
>
>but didn't bother to read the documentation at
>
>https://docs.python.org/3/library/code.html
>
>and thus do not know what the limitations might be.

Well, offhand, I'd say you need to provide a function to be used for
raw_input (which will have to provide prompts, etc.).


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

Well I would be more than happy if an experienced
programmer can fine tune my code. My programming
experience in Python is only 4 weeks.

Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 14:56:35 UTC+2:
> The test harness, test cases and individual 
> results for all test cases are found here: 
> 
> And we could test GraalVM Python, results are from 14.09.2021, 
> tested with Dogelog Runtime 0.9.5, Python Version: 
> https://gist.github.com/jburse/f4e774ebb15cac722238b26b1a620f84#gistcomment-3892587

If you follow the above link, you also find:

Test Harness
https://gist.github.com/jburse/f4e774ebb15cac722238b26b1a620f84#file-suite2-pl

Test Cases
https://github.com/jburse/jekejeke-samples/tree/master/jekrun_bench/core/tests

CPU / RAM: Intel(R) Core(TM) i7-6700HQ, 32 GB
Standard Python: python.exe Python 3.10.0rc1
GraalVM Python: WSL 2, Python 3.8.5 (GraalVM CE Native 21.2.0)

alister schrieb am Mittwoch, 15. September 2021 um 20:22:56 UTC+2:
> On Thu, 16 Sep 2021 03:26:39 +1000, Chris Angelico wrote: 
> 
> > On Thu, Sep 16, 2021 at 3:17 AM Mostowski Collapse 
> >  wrote: 
> >> 
> >> I really wonder why my Python implementation is a factor 40 slower than 
> >> my JavaScript implementation. 
> >> Structurally its the same code. 
> >> 
> >> 
> > Very hard to know. Your code is detailed and complicated. Do they 
> > produce identical results? Are you using the same sort of floating-point 
> > data everywhere, or is one integer and the other float? 
> > What's going on with all the globals, the continuations, etc? My 
> > suspicion is that you're trying to write weird, wonky Python code, and 
> > then are surprised that it doesn't perform well. 
> > 
> > ChrisA
> And this demonstrates how an experienced Python programmer can make an 
> almost spot on diagnosis without even checking the source code. 
> 
> @ this stage I would recommend watching some presentations on you tube 
> 
> this one https://www.youtube.com/watch?v=wf-BqAjZb8M by Raymond Hettinger 
> is brilliant as it highlights there is more to checking code than just 
> making sure it looks nice & runs correctly. 
> 
> 
> 
> -- 
> Lemmings don't grow older, they just die.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[alister via Python-list]

On Wed, 15 Sep 2021 11:31:48 -0700, Mostowski Collapse wrote:

> There is a further problem with this:
> 
>> for i,term in enumerate(term.args):
>> mark_term(term.args[i])
> 
> It should read:
> 
> for i,help in enumerate(term.args):
> mark_term(help)
> 
> But then i isn't need.
even Better (i had only skimmed the code as I was certain I would find 
this, it is probably the No. 1 thing new python programmers get wrong
if your example is correct the it can be simplified even further to

for help in term.args:
mark_term(help)

& if help does not get used after this loop then a comprehension is even 
better
_ == [mark_term(help) for help in term.args]


the underscore character is python convention for an unneeded place-
holder variable.

> 
> Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:22:50
> UTC+2:
>> Do you mean, replace this:
>> i = 0 while i < len(term.args) - 1:
>> mark_term(term.args[i])
>> i += 1 term = term.args[i]
>> 
>> By this:
>> 
>> for i,term in enumerate(term.args):
>> mark_term(term.args[i])
>> 
>> This wouldn't be correct anymore. The recursive call is only for the
>> arguments except for the last one one.
>> alister schrieb am Mittwoch, 15. September 2021 um 20:17:23 UTC+2:
>> > On Wed, 15 Sep 2021 18:23:10 +0200, Mostowski Collapse wrote:
>> > 
>> > > 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:
>> > 
>> > 
>> > this is probably a string contender
>> > 
>> > i = 0 while i < len(term.args) - 1:
>> > mark_term(term.args[i])
>> > i += 1 term = term.args[i]
>> > 
>> > try replacing with something more pythonic
>> > 
>> > for index,term in enumerate(term.args):
>> > mark_term(term.args[i])
>> > 
>> > 
>> > & possibly go all the way to changing it into a comprehension
>> > 
>> > there are other similar anti patterns throughout this code.
>> > 
>> > any time you are manually keeping a counter as an index into a
>> > list,tupple other iterable YOU ARE DOING IT WRONG!
>> > 
>> > Do not write javascript in python, write python
>> > 
>> > 
>> > 
>> > --
>> > Two percent of zero is almost nothing.
>> > 
>> > 
>> > 
>> > 
>> > --
>> > Whoever dies with the most toys wins.





-- 
Pie are not square.  Pie are round.  Cornbread are square.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

There is a further problem with this:

> for i,term in enumerate(term.args): 
> mark_term(term.args[i]) 

It should read:

for i,help in enumerate(term.args): 
mark_term(help) 

But then i isn't need.

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:22:50 UTC+2:
> Do you mean, replace this:
> i = 0 
> while i < len(term.args) - 1:
> mark_term(term.args[i]) 
> i += 1 
> term = term.args[i] 
> 
> By this: 
> 
> for i,term in enumerate(term.args): 
> mark_term(term.args[i]) 
> 
> This wouldn't be correct anymore. The 
> recursive call is only for the arguments 
> except for the last one one.
> alister schrieb am Mittwoch, 15. September 2021 um 20:17:23 UTC+2: 
> > On Wed, 15 Sep 2021 18:23:10 +0200, Mostowski Collapse wrote: 
> > 
> > > 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: 
> >  
> > 
> > this is probably a string contender 
> > 
> > i = 0 
> > while i < len(term.args) - 1: 
> > mark_term(term.args[i]) 
> > i += 1 
> > term = term.args[i] 
> > 
> > try replacing with something more pythonic 
> > 
> > for index,term in enumerate(term.args): 
> > mark_term(term.args[i]) 
> > 
> > 
> > & possibly go all the way to changing it into a comprehension 
> > 
> > there are other similar anti patterns throughout this code. 
> > 
> > any time you are manually keeping a counter as an index into a list,tupple 
> > other iterable YOU ARE DOING IT WRONG! 
> > 
> > Do not write javascript in python, write python 
> > 
> > 
> > 
> > -- 
> > Two percent of zero is almost nothing. 
> > 
> > 
> > 
> > 
> > -- 
> > Whoever dies with the most toys wins.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[alister via Python-list]

On Wed, 15 Sep 2021 18:40:52 +, alister wrote:

> On Wed, 15 Sep 2021 11:31:48 -0700, Mostowski Collapse wrote:
> 
>> There is a further problem with this:
>> 
>>> for i,term in enumerate(term.args):
>>> mark_term(term.args[i])
>> 
>> It should read:
>> 
>> for i,help in enumerate(term.args):
>> mark_term(help)
>> 
>> But then i isn't need.
> even Better (i had only skimmed the code as I was certain I would find
> this, it is probably the No. 1 thing new python programmers get wrong if
> your example is correct the it can be simplified even further to
> 
> for help in term.args:
> mark_term(help)
> 
> & if help does not get used after this loop then a comprehension is even
> better _ == [mark_term(help) for help in term.args]
> 
> 
> the underscore character is python convention for an unneeded place-
> holder variable.
> 
> 
I also notice you are using match case - this was only introduced in 
python 10 so it is very new (i had not seen it before)
the break statements are probably not necessary as if ii understand this 
feature correctly python does not fall-through & execute every subsequent 
case after a successful match.

& finally the netiquette in this forum is to interleave of bottom post 
rather than top post, it makes it easier to follow the thread.
 




-- 
Don't quit now, we might just as well lock the door and throw away the 
key.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

And how do you iterate over the first n-1 elements
of a list with n elements? This is what my code does:

i = 0
while i < len(term.args) - 1:
mark_term(term.args[i])
i += 1
term = term.args[i] 

You can try yourself:

% python3
>>> foo = ["a", "b", "c"]
>>> i = 0
>>> while i < len(foo) - 1:
... print("mark_term", foo[i])
... i += 1
... 
mark_term a
mark_term b
>>> foo = foo[i]
>>> foo
'c'

alister schrieb am Mittwoch, 15. September 2021 um 20:41:12 UTC+2:
> On Wed, 15 Sep 2021 11:31:48 -0700, Mostowski Collapse wrote: 
> 
> > There is a further problem with this: 
> > 
> >> for i,term in enumerate(term.args): 
> >> mark_term(term.args[i]) 
> > 
> > It should read: 
> > 
> > for i,help in enumerate(term.args): 
> > mark_term(help) 
> > 
> > But then i isn't need.
> even Better (i had only skimmed the code as I was certain I would find 
> this, it is probably the No. 1 thing new python programmers get wrong 
> if your example is correct the it can be simplified even further to 
> 
> for help in term.args: 
> mark_term(help) 
> 
> & if help does not get used after this loop then a comprehension is even 
> better 
> _ == [mark_term(help) for help in term.args] 
> 
> 
> the underscore character is python convention for an unneeded place- 
> holder variable.
> > 
> > Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:22:50 
> > UTC+2: 
> >> Do you mean, replace this: 
> >> i = 0 while i < len(term.args) - 1: 
> >> mark_term(term.args[i]) 
> >> i += 1 term = term.args[i] 
> >> 
> >> By this: 
> >> 
> >> for i,term in enumerate(term.args): 
> >> mark_term(term.args[i]) 
> >> 
> >> This wouldn't be correct anymore. The recursive call is only for the 
> >> arguments except for the last one one. 
> >> alister schrieb am Mittwoch, 15. September 2021 um 20:17:23 UTC+2: 
> >> > On Wed, 15 Sep 2021 18:23:10 +0200, Mostowski Collapse wrote: 
> >> > 
> >> > > 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: 
> >> >  
> >> > 
> >> > this is probably a string contender 
> >> > 
> >> > i = 0 while i < len(term.args) - 1: 
> >> > mark_term(term.args[i]) 
> >> > i += 1 term = term.args[i] 
> >> > 
> >> > try replacing with something more pythonic 
> >> > 
> >> > for index,term in enumerate(term.args): 
> >> > mark_term(term.args[i]) 
> >> > 
> >> > 
> >> > & possibly go all the way to changing it into a comprehension 
> >> > 
> >> > there are other similar anti patterns throughout this code. 
> >> > 
> >> > any time you are manually keeping a counter as an index into a 
> >> > list,tupple other iterable YOU ARE DOING IT WRONG! 
> >> > 
> >> > Do not write javascript in python, write python 
> >> > 
> >> > 
> >> > 
> >> > -- 
> >> > Two percent of zero is almost nothing. 
> >> > 
> >> > 
> >> > 
> >> > 
> >> > -- 
> >> > Whoever dies with the most toys wins.
> -- 
> Pie are not square. Pie are round. Cornbread are square.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

There is a Python 3.8 compatible version here:

https://github.com/jburse/dogelog-moon/blob/main/devel/runtimepy/machine2.py

I have replaced match by if-then-else. So as to
be able to test with GraalVM. GraalVM is still faster
despite using if-then-else.

But GraalVM needs some time to JIT the code.
You need to make some cold runs before you
see kicking it being fast.

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:48:31 UTC+2:
> And how do you iterate over the first n-1 elements 
> of a list with n elements? This is what my code does:
> i = 0 
> while i < len(term.args) - 1: 
> mark_term(term.args[i]) 
> i += 1 
> term = term.args[i]
> You can try yourself: 
> 
> % python3 
> >>> foo = ["a", "b", "c"] 
> >>> i = 0 
> >>> while i < len(foo) - 1: 
> ... print("mark_term", foo[i]) 
> ... i += 1 
> ... 
> mark_term a 
> mark_term b 
> >>> foo = foo[i] 
> >>> foo 
> 'c'
> alister schrieb am Mittwoch, 15. September 2021 um 20:41:12 UTC+2: 
> > On Wed, 15 Sep 2021 11:31:48 -0700, Mostowski Collapse wrote: 
> > 
> > > There is a further problem with this: 
> > > 
> > >> for i,term in enumerate(term.args): 
> > >> mark_term(term.args[i]) 
> > > 
> > > It should read: 
> > > 
> > > for i,help in enumerate(term.args): 
> > > mark_term(help) 
> > > 
> > > But then i isn't need. 
> > even Better (i had only skimmed the code as I was certain I would find 
> > this, it is probably the No. 1 thing new python programmers get wrong 
> > if your example is correct the it can be simplified even further to 
> > 
> > for help in term.args: 
> > mark_term(help) 
> > 
> > & if help does not get used after this loop then a comprehension is even 
> > better 
> > _ == [mark_term(help) for help in term.args] 
> > 
> > 
> > the underscore character is python convention for an unneeded place- 
> > holder variable. 
> > > 
> > > Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:22:50 
> > > UTC+2: 
> > >> Do you mean, replace this: 
> > >> i = 0 while i < len(term.args) - 1: 
> > >> mark_term(term.args[i]) 
> > >> i += 1 term = term.args[i] 
> > >> 
> > >> By this: 
> > >> 
> > >> for i,term in enumerate(term.args): 
> > >> mark_term(term.args[i]) 
> > >> 
> > >> This wouldn't be correct anymore. The recursive call is only for the 
> > >> arguments except for the last one one. 
> > >> alister schrieb am Mittwoch, 15. September 2021 um 20:17:23 UTC+2: 
> > >> > On Wed, 15 Sep 2021 18:23:10 +0200, Mostowski Collapse wrote: 
> > >> > 
> > >> > > 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: 
> > >> >  
> > >> > 
> > >> > this is probably a string contender 
> > >> > 
> > >> > i = 0 while i < len(term.args) - 1: 
> > >> > mark_term(term.args[i]) 
> > >> > i += 1 term = term.args[i] 
> > >> > 
> > >> > try replacing with something more pythonic 
> > >> > 
> > >> > for index,term in enumerate(term.args): 
> > >> > mark_term(term.args[i]) 
> > >> > 
> > >> > 
> > >> > & possibly go all the way to changing it into a comprehension 
> > >> > 
> > >> > there are other similar anti patterns throughout this code. 
> > >> > 
> > >> > any time you are manually keeping a counter as an index into a 
> > >> > list,tupple other iterable YOU ARE DOING IT WRONG! 
> > >> > 
> > >> > Do not write javascript in python, write python 
> > >> > 
> > >> > 
> > >> > 
> > >> > -- 
> > >> > Two percent of zero is almost nothing. 
> > >> > 
> > >> > 
> > >> > 
> > >> > 
> > >> > -- 
> > >> > Whoever dies with the most toys wins. 
> > -- 
> > Pie are not square. Pie are round. Cornbread are square.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Thu, Sep 16, 2021 at 5:15 AM Mostowski Collapse  wrote:
>
> If you find a "wonky" spot, I can replace it by "non-wonky"
> code. I noticed some differences between Python Dicts
> and JavaScript objects. Python tends to throw more exceptions.
>
> So in Python I now do the following:
>
>peek = kb.get(functor, NotImplemented)
>if peek is not NotImplemented:
>
> In JavaScript I can directly do:
>
> peek = kb[functor];
> if (peek !== undefined)
>
> But if get() in Python is implemented under the hood with
> exception handling. i.e. using the exception prone [] and
> then in case an exception is thrown, returning the
>
> default value, then Python get() will probably be quite slow.
> Since usually exceptions are slow.
>

No, you're thinking in terms of microoptimizations. Exception handling
isn't THAT slow. I'm talking more about how everything's getting
packaged up and then unpackaged (the repeated use of the "Compound"
class looks highly suboptimal), rather than reworking your algorithm
to behave more cleanly.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

What could be slow, repeatedly requesting the "args"
field. Maybe I should do:

help = term.args
i = 0
while i < len(help) - 1:
mark_term(help[i])
i += 1
term = help[i] 

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:48:31 UTC+2:
> And how do you iterate over the first n-1 elements 
> of a list with n elements? This is what my code does:
> i = 0 
> while i < len(term.args) - 1: 
> mark_term(term.args[i]) 
> i += 1 
> term = term.args[i]
> You can try yourself: 
> 
> % python3 
> >>> foo = ["a", "b", "c"] 
> >>> i = 0 
> >>> while i < len(foo) - 1: 
> ... print("mark_term", foo[i]) 
> ... i += 1 
> ... 
> mark_term a 
> mark_term b 
> >>> foo = foo[i] 
> >>> foo 
> 'c'
> alister schrieb am Mittwoch, 15. September 2021 um 20:41:12 UTC+2: 
> > On Wed, 15 Sep 2021 11:31:48 -0700, Mostowski Collapse wrote: 
> > 
> > > There is a further problem with this: 
> > > 
> > >> for i,term in enumerate(term.args): 
> > >> mark_term(term.args[i]) 
> > > 
> > > It should read: 
> > > 
> > > for i,help in enumerate(term.args): 
> > > mark_term(help) 
> > > 
> > > But then i isn't need. 
> > even Better (i had only skimmed the code as I was certain I would find 
> > this, it is probably the No. 1 thing new python programmers get wrong 
> > if your example is correct the it can be simplified even further to 
> > 
> > for help in term.args: 
> > mark_term(help) 
> > 
> > & if help does not get used after this loop then a comprehension is even 
> > better 
> > _ == [mark_term(help) for help in term.args] 
> > 
> > 
> > the underscore character is python convention for an unneeded place- 
> > holder variable. 
> > > 
> > > Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 20:22:50 
> > > UTC+2: 
> > >> Do you mean, replace this: 
> > >> i = 0 while i < len(term.args) - 1: 
> > >> mark_term(term.args[i]) 
> > >> i += 1 term = term.args[i] 
> > >> 
> > >> By this: 
> > >> 
> > >> for i,term in enumerate(term.args): 
> > >> mark_term(term.args[i]) 
> > >> 
> > >> This wouldn't be correct anymore. The recursive call is only for the 
> > >> arguments except for the last one one. 
> > >> alister schrieb am Mittwoch, 15. September 2021 um 20:17:23 UTC+2: 
> > >> > On Wed, 15 Sep 2021 18:23:10 +0200, Mostowski Collapse wrote: 
> > >> > 
> > >> > > 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: 
> > >> >  
> > >> > 
> > >> > this is probably a string contender 
> > >> > 
> > >> > i = 0 while i < len(term.args) - 1: 
> > >> > mark_term(term.args[i]) 
> > >> > i += 1 term = term.args[i] 
> > >> > 
> > >> > try replacing with something more pythonic 
> > >> > 
> > >> > for index,term in enumerate(term.args): 
> > >> > mark_term(term.args[i]) 
> > >> > 
> > >> > 
> > >> > & possibly go all the way to changing it into a comprehension 
> > >> > 
> > >> > there are other similar anti patterns throughout this code. 
> > >> > 
> > >> > any time you are manually keeping a counter as an index into a 
> > >> > list,tupple other iterable YOU ARE DOING IT WRONG! 
> > >> > 
> > >> > Do not write javascript in python, write python 
> > >> > 
> > >> > 
> > >> > 
> > >> > -- 
> > >> > Two percent of zero is almost nothing. 
> > >> > 
> > >> > 
> > >> > 
> > >> > 
> > >> > -- 
> > >> > Whoever dies with the most toys wins. 
> > -- 
> > Pie are not square. Pie are round. Cornbread are square.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The code version of python -i

[Abdur-Rahmaan Janhangeer]

Thanks folks will update with progress soon

>
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[alister via Python-list]

On Wed, 15 Sep 2021 11:48:18 -0700, Mostowski Collapse wrote:

> And how do you iterate over the first n-1 elements of a list with n
> elements? This is what my code does:
> 
> i = 0 while i < len(term.args) - 1:
> mark_term(term.args[i])
> i += 1 term = term.args[i]
> 
> You can try yourself:

use a slice
as a generic example you can try in the interactive interpreter (aka 
REPL):

>>>items = [1,2,3,4,5,6,7,8,9,0]
>>>for item in items[:-1]:
>>>print(item)

1
2
3
4
5
6
7
8
9

I should state for the record that I am no Python expert, I mainly visit 
this news group to learn.
sometimes from reading solutions & somtimes by trying to work out what 
the solution might be.

most productively by working out a solution & seeing if other posters 
agree (& working out why they don't)



-- 
The universe seems neither benign nor hostile, merely indifferent.
-- Sagan
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

But the end-result is still very weak:
% Wall 33810 ms, gc 980 ms, 284108 lips 

This is below 1 million LIPS. 
The JavaScript version of Dogelog does currently around 2 million LIPS. 
And SWI-Prolog can do around 20 million LIPS.

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 23:29:48 UTC+2:
> Thank you for the suggestion. The test harness 
> is invoked as follows. So it does already do time/1, 
> thats also how I did the comparison Standard Python 
> 
> and GraalVM Python, a file dogelog.py: 
> 
> import sys 
> # sys.path.append("\jekrun_bench\core\harness2\libpy") 
> sys.path.append("/mnt/c//jekrun_bench/core/harness2/libpy") 
> from index import init, consult 
> 
> init() 
> consult(":- ['suite2.p']. " 
> ":- time(suite). " 
> ":- nl. " 
> ":- time(suite). ") 
> 
> Here you see a GraalVM cold and warm run.The warm run is faster. 
> If you do a warm warm run, it even gets more faster, because of 
> JIT-ing, Just-in-Time machine compilation, 
> 
> via the GraalVM Truffles framework: 
> 
> $ export PATH=/graalvm-ce-java8-21.2.0/bin:$PATH 
> $ cd /mnt/c//jekrun_bench/core/harness2 
> $ graalpython /mnt/c//jekrun_bench/core/harness2/dogelog.py 
> nrev % Wall 6175 ms, gc 212 ms, 154473 lips 
> crypt % Wall 9327 ms, gc 63 ms, 112838 lips 
> deriv % Wall 4101 ms, gc 90 ms, 321890 lips 
> poly % Wall 3594 ms, gc 415 ms, 216299 lips 
> sortq % Wall 3427 ms, gc 67 ms, 290070 lips 
> tictac % Wall 2770 ms, gc 51 ms, 136580 lips 
> queens % Wall 3287 ms, gc 64 ms, 325617 lips 
> query % Wall 1432 ms, gc 77 ms, 382969 lips 
> mtak % Wall 2532 ms, gc 95 ms, 533881 lips 
> perfect % Wall 3980 ms, gc 76 ms, 290382 lips 
> % Wall 40745 ms, gc 1212 ms, 235751 lips 
> 
> nrev % Wall 4508 ms, gc 112 ms, 211595 lips 
> crypt % Wall 6063 ms, gc 61 ms, 173584 lips 
> deriv % Wall 3150 ms, gc 42 ms, 419070 lips 
> poly % Wall 3549 ms, gc 432 ms, 219042 lips 
> sortq % Wall 3196 ms, gc 63 ms, 311036 lips 
> tictac % Wall 2670 ms, gc 52 ms, 141695 lips 
> queens % Wall 3087 ms, gc 60 ms, 346713 lips 
> query % Wall 1434 ms, gc 25 ms, 382435 lips 
> mtak % Wall 2596 ms, gc 90 ms, 520719 lips 
> perfect % Wall 3521 ms, gc 43 ms, 328236 lips 
> % Wall 33810 ms, gc 980 ms, 284108 lips
> DFS schrieb am Mittwoch, 15. September 2021 um 23:15:07 UTC+2: 
> > On 9/15/2021 12:23 PM, Mostowski Collapse wrote: 
> > > 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? 
> > I'm sure you know you can put in timing statements to find bottlenecks. 
> > 
> > import time 
> > startTime = time.perf_counter() 
> > [code block] 
> > print("%.2f" % (time.perf_counter() - startTime))
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[DFS]

On 9/15/2021 12:23 PM, Mostowski Collapse wrote:

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?




I'm sure you know you can put in timing statements to find bottlenecks.

import time
startTime = time.perf_counter()
[code block]
print("%.2f" % (time.perf_counter() - startTime))



--
https://mail.python.org/mailman/listinfo/python-list

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

[alister via Python-list]

On Wed, 15 Sep 2021 11:56:47 -0700, Mostowski Collapse wrote:

> What could be slow, repeatedly requesting the "args"
> field. Maybe I should do:
> 
> help = term.args i = 0 while i < len(help) - 1:
> mark_term(help[i])
> i += 1 term = help[i]
> 
No this construct is a common error in new python programmers
 the next progression they make is when they discover the range function
items = [1, 2, 3, 4, 5, 6, 7, 8, 9, 0]
for x in range(len(list)):
print (items[x])

but that is equally inefficient

the pythonic way is as previously suggested

for item in items:
print(item)

then the management of the index is being handled by the python 
interpreter internally & is effectively machine code.
every time you increment your own pointer the interpreter has to process 
reading the next line, reading the variable , incrementing it & then 
using it. this is what makes your current code slow. 

 
if you ever find your self creating a variable purely to use as a pointer 
into a list then you are almost certainly taking the wrong approach.

 more usefull links
https://www.youtube.com/watch?v=zdJEYhA2AZQ






-- 
"Show me a good loser, and I'll show you a loser."
-- Vince Lombardi, football coach
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[DFS]

On 9/15/2021 5:10 PM, Mostowski Collapse wrote:

And how do you only iterate over n-1 elements?
I don't need a loop over all elements.

With array slicing?

Someting like:

for item in items[0:len(items)-2]:
___print(item)

Or with negative slicing indexes? Problem
is my length can be equal to one.

And when I have length equal to one, the
slice might not do the right thing?

LoL



From the python command prompt:

items = [1,2,3,4]

for itm in items:
print(itm)
1
2
3
4

for itm in items[:-2]:
print(itm)
1
2


for itm in items[:-3]:
print(itm)
1


for itm in items[:-4]:
print(itm)
(no result, no error thrown)


for itm in items[:-5]:
print(itm)
(no result, no error thrown)
--
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

And how do you only iterate over n-1 elements?
I don't need a loop over all elements.

With array slicing?

Someting like:

for item in items[0:len(items)-2]: 
___print(item) 

Or with negative slicing indexes? Problem
is my length can be equal to one.

And when I have length equal to one, the
slice might not do the right thing?

LoL

alister schrieb am Mittwoch, 15. September 2021 um 22:00:30 UTC+2:
> for item in items: 
> print(item) 

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

Ok you suggested:

>>>items = [1,2,3,4,5,6,7,8,9,0]
>>>for item in items[:-1]:
>>> print(item)

1
2
3
4
5
6
7
8
9 

Does this also work for length = 1? Ok let me try:

>>> foo = ["a","b","c"]
>>> for x in foo[:-1]:
... print(x)
...
a
b
>>> foo = ["a"]
>>> for x in foo[:-1]:
... print(x)
...

Oki Doki

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 23:10:50 UTC+2:
> And how do you only iterate over n-1 elements? 
> I don't need a loop over all elements. 
> 
> With array slicing? 
> 
> Someting like: 
> 
> for item in items[0:len(items)-2]: 
> ___print(item) 
> 
> Or with negative slicing indexes? Problem 
> is my length can be equal to one. 
> 
> And when I have length equal to one, the 
> slice might not do the right thing? 
> 
> LoL
> alister schrieb am Mittwoch, 15. September 2021 um 22:00:30 UTC+2: 
> > for item in items: 
> > print(item)
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

BTW: I could already make it faster, by not repeatedly
accessing .arg anymore. It went down from ca.:

171'000 ms

To this here:

140'000 ms

But only in the cold run. In the warm run it went back
to 171'000 ms. Possibly when my code is faster,
it will create objects more faster, and kill the Python GC.

Or it was because my Laptop went into screen black?
And throttled the CPU. Not sure.

Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 23:13:12 UTC+2:
> Ok you suggested:
> >>>items = [1,2,3,4,5,6,7,8,9,0] 
> >>>for item in items[:-1]: 
> >>> print(item) 
> 
> 1 
> 2 
> 3 
> 4 
> 5 
> 6 
> 7 
> 8 
> 9
> Does this also work for length = 1? Ok let me try:
> >>> foo = ["a","b","c"]
> >>> for x in foo[:-1]: 
> ... print(x) 
> ... 
> a 
> b 
> >>> foo = ["a"] 
> >>> for x in foo[:-1]: 
> ... print(x) 
> ... 
> 
> Oki Doki
> Mostowski Collapse schrieb am Mittwoch, 15. September 2021 um 23:10:50 UTC+2: 
> > And how do you only iterate over n-1 elements? 
> > I don't need a loop over all elements. 
> > 
> > With array slicing? 
> > 
> > Someting like: 
> > 
> > for item in items[0:len(items)-2]: 
> > ___print(item) 
> > 
> > Or with negative slicing indexes? Problem 
> > is my length can be equal to one. 
> > 
> > And when I have length equal to one, the 
> > slice might not do the right thing? 
> > 
> > LoL 
> > alister schrieb am Mittwoch, 15. September 2021 um 22:00:30 UTC+2: 
> > > for item in items: 
> > > print(item)
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mostowski Collapse]

Thank you for the suggestion. The test harness 
is invoked as follows. So it does already do time/1,
thats also how I did the comparison Standard Python

and GraalVM Python, a file dogelog.py:

import sys
# sys.path.append("\jekrun_bench\core\harness2\libpy")
sys.path.append("/mnt/c//jekrun_bench/core/harness2/libpy")
from index import init, consult

init()
consult(":- ['suite2.p']. "
":- time(suite). "
":- nl. "
":- time(suite). ")

Here you see a GraalVM cold and warm run.The warm run is faster. 
If you do a warm warm run, it even gets more faster, because of 
JIT-ing, Just-in-Time machine compilation, 

via the GraalVM Truffles framework:

$ export PATH=/graalvm-ce-java8-21.2.0/bin:$PATH
$ cd /mnt/c//jekrun_bench/core/harness2
$ graalpython /mnt/c//jekrun_bench/core/harness2/dogelog.py
nrev % Wall 6175 ms, gc 212 ms, 154473 lips
crypt % Wall 9327 ms, gc 63 ms, 112838 lips
deriv % Wall 4101 ms, gc 90 ms, 321890 lips
poly % Wall 3594 ms, gc 415 ms, 216299 lips
sortq % Wall 3427 ms, gc 67 ms, 290070 lips
tictac % Wall 2770 ms, gc 51 ms, 136580 lips
queens % Wall 3287 ms, gc 64 ms, 325617 lips
query % Wall 1432 ms, gc 77 ms, 382969 lips
mtak % Wall 2532 ms, gc 95 ms, 533881 lips
perfect % Wall 3980 ms, gc 76 ms, 290382 lips
% Wall 40745 ms, gc 1212 ms, 235751 lips

nrev % Wall 4508 ms, gc 112 ms, 211595 lips
crypt % Wall 6063 ms, gc 61 ms, 173584 lips
deriv % Wall 3150 ms, gc 42 ms, 419070 lips
poly % Wall 3549 ms, gc 432 ms, 219042 lips
sortq % Wall 3196 ms, gc 63 ms, 311036 lips
tictac % Wall 2670 ms, gc 52 ms, 141695 lips
queens % Wall 3087 ms, gc 60 ms, 346713 lips
query % Wall 1434 ms, gc 25 ms, 382435 lips
mtak % Wall 2596 ms, gc 90 ms, 520719 lips
perfect % Wall 3521 ms, gc 43 ms, 328236 lips
% Wall 33810 ms, gc 980 ms, 284108 lips

DFS schrieb am Mittwoch, 15. September 2021 um 23:15:07 UTC+2:
> On 9/15/2021 12:23 PM, Mostowski Collapse wrote: 
> > 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?
> I'm sure you know you can put in timing statements to find bottlenecks. 
> 
> import time 
> startTime = time.perf_counter() 
> [code block] 
> print("%.2f" % (time.perf_counter() - startTime))
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

On Thu, Sep 16, 2021 at 7:59 AM Mostowski Collapse  wrote:
>
> BTW: I could already make it faster, by not repeatedly
> accessing .arg anymore. It went down from ca.:
>
> 171'000 ms
>
> To this here:
>
> 140'000 ms
>
> But only in the cold run. In the warm run it went back
> to 171'000 ms. Possibly when my code is faster,
> it will create objects more faster, and kill the Python GC.
>
> Or it was because my Laptop went into screen black?
> And throttled the CPU. Not sure.
>

Instead of worrying about all these details, start by simplifying your
code. Focus on clean, simple, readable code, and don't microoptimize.
Specifically, focus on the core arithmetic that you're trying to do,
and get rid of all the bookkeeping overhead; most of that is a waste
of time. I mentioned earlier the repeated boxing and unboxing in
"Compound" objects - have you changed anything with those?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list