New submission from Jurjen N.E. Bos :
I found a very simple way to improve the speed of CPython a few percent on the
most common platforms (i.e. x86), at the cost of only a few lines of code in
ceval.c
The only problem is that I don't have any experience in patch submission.
Here ar
New submission from Jurjen N.E. Bos :
The Java class "BiDiMap" is very useful and doesn't seem to have an equivalent
in the Python libraries.
I wrote a proposed class that does just that.
Here's a simple implementation, that could be used as a starting point.
Change by Jurjen N.E. Bos :
--
type: -> performance
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue44931>
___
___
Python-bugs-lis
Jurjen N.E. Bos added the comment:
Give me a shout if you like this: I am happy to write a test suite, make a
patch, etc.
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Jurjen N.E. Bos :
--
title: Add "bidimap" to collections library -> Add "bidimap" to collections
library: a simple bidirectional map
___
Python tracker
<https://
Jurjen N.E. Bos added the comment:
It is part of the Apache Common collections
--
___
Python tracker
<https://bugs.python.org/issue44931>
___
___
Python-bug
Jurjen N.E. Bos added the comment:
I tried to make a pull request, but it fails on the format of news file name.
At least the tests all pass.
--
___
Python tracker
<https://bugs.python.org/issue24
Jurjen N.E. Bos added the comment:
All is fixed. The PR apparently is correct.
My first dent in the Python universe, however small :-)
--
___
Python tracker
<https://bugs.python.org/issue24
New submission from Jurjen N.E. Bos :
There's a trivial optimization in the round_size in hashtable.c:
a loop is used to compute the lowest power of two >= s,
while this can be done in one step with bit_length.
I am making a pull request for this.
--
components: Interpre
Change by Jurjen N.E. Bos :
--
keywords: +patch
pull_requests: +22692
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23833
___
Python tracker
<https://bugs.python.org/issu
Jurjen N.E. Bos added the comment:
Harsh, but fair.
I'll do a better job next time!
Op di 29 dec. 2020 13:42 schreef Serhiy Storchaka :
>
> Serhiy Storchaka added the comment:
>
> Since no benchmarking data was provided, I suggest to close this issue. We
> do not accept
New submission from Jurjen N.E. Bos :
When looking at the code of pow() with integer exponent, I noticed there is a
hard boundary between the binary and "fiveary" (actually 32-ary) computations.
Also, the fiveary wasn't really optimal.
So I wrote a proof of concept version o
Jurjen N.E. Bos added the comment:
Some more information for the interested:
The algorithm I made tries to smoothly change the"chunk size" with growing
length of the exponent. So the exponents that win the most (up to 14% fewer
multiplication) are the long exponents that are ju
Change by Jurjen N.E. Bos :
--
keywords: +patch
pull_requests: +23032
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24206
___
Python tracker
<https://bugs.python.org/issu
Jurjen N.E. Bos added the comment:
Well, measurements show that it saves more time than I thought (sometimes over
20%!), because there are other ways in which it saves time; I am quite happy
with that.
In the code I needed functions _Py_bit_length64 and _Py_bit_count64.
I thought these
Change by Jurjen N.E. Bos :
--
title: Addition chains for pow saves 10 % time! -> Addition chains for pow
saves 5-20% time for pow(int,int)
___
Python tracker
<https://bugs.python.org/issu
Jurjen N.E. Bos added the comment:
Well, I would argue that there is already quite a work going to for
crypto-sized computations in the integer code, as well as the crypto-oriented
.bit_count() function that was recently added.
For starters, the arguably crypto-oriented three argument pow
Jurjen N.E. Bos added the comment:
...not to mention the new gcd and lcm functions, and the fact that the number
conversion is linear for exponent-of-two bases, and the negative power modulo a
prime number!
--
___
Python tracker
<ht
Jurjen N.E. Bos added the comment:
Yes. That would make me happy. In the meantime I learned how to use git, so
maybe I'll do the pull request myself next time. Thanks for the work.
--
___
Python tracker
<https://bugs.python.org/is
New submission from Jurjen N.E. Bos :
The documentation of math.sin (and related trig functions) doesn't speak about
backward error.
In cPython, as far as I can see, there is no backward error at all, which is
quite uncommon.
This may vary between implementations; many math libraries of
Jurjen N.E. Bos added the comment:
I stand corrected; more on that later.
"backward error" is the mathematical term used for the accuracy of a
function. (Forward error is in the result proper; backward error means that you
calculate the correct result for a number that is very cl
Jurjen N.E. Bos added the comment:
I always use the following piece of code that can be trivially used to patch
the source.
It basically looks for a using line in the test string and finds it in the
source file. If there is a match, we know where we are. Otherwise it falls back
to the
Jurjen N.E. Bos added the comment:
Oh wait, I already posted that so long ago I forgot about it.
Oops.
Sorry about the repetition, folks.
- Jurjen
--
___
Python tracker
<https://bugs.python.org/issue24
Jurjen N.E. Bos added the comment:
Maybe we could use Pdb._getval_except(arg, frame=None) in the routine do_args.
If I understand the code, do_args does quite some work to get the value of name
in the context of the current frame, maybe just calling
self._getval_except(name, frame=self.curframe
Jurjen N.E. Bos added the comment:
I did figure it out.
It almost works, except when a argument lost its value, and the same name
exists in the global context.
To be more specific: I simplified do_args to the following code
(that obviously ugly by explicitly evaluating repr in context, but
that
New submission from Jurjen N.E. Bos:
One of the more interesting ways to use print is printing output of a
generator, as print(*generator()).
But if the generator generates a typeError, you get a very unhelpful error
message:
>>> #the way it works OK
>>> def f(): yield '
New submission from Jurjen N.E. Bos:
It all started when adding an __equals__ method to a self made class.
The effect was that my program slowed down enormously, which came as a surprise.
This is because when doing an operation that does linear search through a
container, the interpreter
Jurjen N.E. Bos added the comment:
Well, I partially agree. I see the following points:
Against my proposal:
- For *very* big containers, it can be slower in the case the object is early
in the container, as you pointed out.
- Current behaviour is easier to understand.
OTOH, fore the proposal
Jurjen N.E. Bos added the comment:
Oops. That was a hard lesson: 1) don't haste when posting 2) always run what
you post.
The point was the trick to define a custom __ne__ and not an __eq__ for an
object (not for the container it is in!) so you can use "in" at full speed. Then
New submission from Jurjen N.E. Bos:
The pool.imap and pool.imap_unordered functions are documented as "a lazy
version of Pool.map".
In fact, they aren't: they consume the iterator argument as a whole. This is
almost certainly not what the user wants: it uses unnecessary memo
New submission from Jurjen N.E. Bos:
The "args" command in pdb crashes when an argument cannot be printed.
Fortunately, this is easy to fix.
For version 3.3.3:
In function Pdb.do_args (lib/pdb.py, line 1120)
Change line 1131
self.message('%s = %r' % (name, dict[name]))
to
Jurjen N.E. Bos added the comment:
Thanks for your reaction.
The object is not printable, since I was debugging an __init__ of an object,
and some fields where being initialized:
class foo:
def __init__(self):
foo.bar = "hello"
def repr(self): return foo.bar
I tried
Jurjen N.E. Bos added the comment:
Oops. Here the correct example:
>>> class foo:
... def __init__(self):
... foo.bar = "hello"
... def __repr__(self): return foo.bar
...
>>> pdb.runcall(foo)
> (3)__init__()
(Pdb) a
Traceback (most recent call last):
Jurjen N.E. Bos added the comment:
I am not good at this. Sorry for the mess.
Here is a good example, and a good patch:
>>> class foo:
... def __init__(self):
... foo.bar = "hello"
... def __repr__(self): return foo.bar
...
>>> pdb.runcall(foo)
Traceback (mo
New submission from Jurjen N.E. Bos:
I found a pretty obscure bug/documentation issue.
It only happens if you use global variables in static methods under doctest.
The thing is that this code fails under doctest, while anyone would expect it
to work at first sight:
class foo:
@staticmethod
New submission from Jurjen N.E. Bos:
When looking for a "neat" way to create an empty generator, I saw on
stackOverflow that the crowd wasn't sure what was the "least ugly" way to do it.
Proposals where:
def emptyIter(): return; yield
or
def emptyIter(): return iter([]
Jurjen N.E. Bos added the comment:
I am not as good in making nice patches, but that code can be improved upon a
bit as follows:
+if isinstance(obj, str) and source_lines is not None:
+# This will find __test__ string doctests if and only if the string
Jurjen N.E. Bos added the comment:
Oops. Lousy editing, I should have used return instead of break.
These 6 lines can be inserted in lib/doctest at line 1100:
+if isinstance(obj, str) and source_lines is not None:
+# This will find __test__ string doctests if and only if the
New submission from Jurjen N.E. Bos:
Inspired by the recently new discovered 49th Mersenne prime number I wrote a
module to do high speed long/int to decimal conversion. I can now output the
new Mersenne number in 18.5 minutes (instead of several hours) on my machine.
For numbers longer than
Jurjen N.E. Bos added the comment:
Thanks for the tip. I'll consider making it a recipe.
- Jurjen
--
___
Python tracker
<http://bugs.python.org/is
Jurjen N.E. Bos added the comment:
OMG is decimal that fast?
Maybe I should change the issue then to "documentation missing": it nowhere
says in the documentation that decimal has optimized multiprecision
computations. It only says that precision "can be as large as needed for a
Jurjen N.E. Bos added the comment:
That reference you gave says that the binary version is faster than the Python
version, but here the _complexity_ actually changed by a lot.
Only people who know the library by name will notice that it is this fast.
But you are right, for 99% of the people it
42 matches
Mail list logo