Jurjen N.E. Bos added the comment:
It is part of the Apache Common collections
--
___
Python tracker
<https://bugs.python.org/issue44931>
___
___
Python-bug
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:
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 :
--
type: -> performance
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue44931>
___
___
Python-bugs-lis
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.
--
files:
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:
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
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, 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
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:
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
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:
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 optim
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
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: Interpreter C
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
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:
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
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 other
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/issue24
Jurjen N.E. Bos <j...@users.sourceforge.net> 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 <rep...@bugs.python.org>
<https://
Jurjen N.E. Bos <j...@users.sourceforge.net> 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. Oth
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
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
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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
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
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([]
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
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
not all(map(ne
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:
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
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 'a'+'b'
...
print(*f())
ab
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:
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 to make a useable
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)
stdin(3)__init__()
(Pdb) a
Traceback (most recent call last):
File .\pdb.py, line 1132, in do_args
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 (most recent call last):
File stdin
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
try: r = repr(dict
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 memory
New submission from Jurjen N.E. Bos j...@users.sourceforge.net:
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
42 matches
Mail list logo
