Stefan Krah added the comment:
Argh, forget the second Haskell example: inf / 0 is fine.
--
___
Python tracker
<http://bugs.python.org/issue22444>
___
___
Pytho
Stefan Krah added the comment:
Ok, so it is a debug thing in the current NumPy sources.
IMO ultimately the getbufferproc needs to return valid strides, even
if the first value isn't used.
For that matter, the getbufferproc is free to translate the multi-
dimensional corner case array to
Stefan Krah added the comment:
I think it would help discussing your options if the patch passes test_buffer
first. Currently it segfaults because shape can be NULL. Also, code in
memoryobject.c relies on the fact that ndim==0 means contiguous.
Then, it would help enormously if you give
Stefan Krah added the comment:
Thanks! I still have to review the patch in depth, but generally
I'm +1 now for relaxing the contiguity check.
Curiously enough the existing code already considered e.g. shape=[1],
strides=[-5] as conti
New submission from Stefan Behnel:
Fractions are great for all sorts of exact computations (including
money/currency calculations), but are quite slow due to the need for
normalisation at instantiation time.
I adapted the existing telco benchmark to use Fraction instead of Decimal to
make
Stefan Behnel added the comment:
I just thought that it might also be nice to have a direct comparison with
Decimal, so here's an updated benchmark that has an option "--use-decimal" to
run the same code with Decimal instead of Fraction.
Decimal is about 66x faster with Py3.4
Stefan Krah added the comment:
Since the functions in abstract.c have been committed by Travis Oliphant:
Could there have been a reason why the {shape=[1], strides=[-5]}
case was considered but the general case was not?
Or is it generally accepted among the numpy devs that not considering
the
Stefan Behnel added the comment:
As I said, where ever exact calculations are needed. I use them for currency
calculations, for example, as they inherently avoid rounding errors during the
calculations regardless of the relative size of values. They are basically like
Decimal but with
Stefan Behnel added the comment:
I admit that I keep meeting developers who are not aware of their merits,
simply because many other programming languages don't have them available.
Specifically, many developers with a Java background firmly believe that
BigDecimal is the only way to do
New submission from Stefan Behnel:
Fractions are an excellent way to do exact money calculations and largely beat
Decimal in terms of simplicity, accuracy and safety. Clearly not in terms of
speed, though.
The current implementation does some heavy type checking and dispatching in
__new__
Stefan Behnel added the comment:
Speed improvements for fractions should have their own ticket(s). I created
issue 22464 for this.
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
Adding Mark Dickinson to the noisy list who mentioned having worked on a C
implementation for gcd(). I think this would be a good thing to try. However,
the most important part would be to restructure and specialise
Fraction.__new__().
--
nosy
Stefan Behnel added the comment:
Here is a straight forward patch that special cases int values in the
constructor. It gives me a 35% speedup in the benchmark.
--
keywords: +patch
Added file: http://bugs.python.org/file36687/special_case_int.patch
Changes by Stefan Behnel :
--
type: -> performance
___
Python tracker
<http://bugs.python.org/issue22464>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Behnel added the comment:
Updated patch - there is a somewhat hidden attempt in the code to keep
nominator and denominater plain int values, not subtypes. That means that it's
safer to restrict the optimisation to plain ints as well, which should still
hit >95% of the u
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file36689/special_case_int3.patch
___
Python tracker
<http://bugs.python.org/issue22464>
___
___
Python-bug
Stefan Behnel added the comment:
The second isn't a big difference because it only hits plain instantiations
from integers. They are less likely to be performance critical than those from
a quotient, which happen for all calculations.
It's more for symmetr
Stefan Behnel added the comment:
I found one more place where special casing helps: equal comparisons to
integers, e.g. f == 0 or f == 1 or so. timeit shows me a speedup by a factor of
three for this, with only a tiny slow-down when comparing fractions on both
sides.
I put all of them in one
Stefan Behnel added the comment:
Benchmark profile after the patch:
5930670 function calls (5930288 primitive calls) in 3.748 seconds
Ordered by: internal time
ncalls tottime percall cumtime percall filename:lineno(function)
5196320.8280.0000.8280.000
Stefan Krah added the comment:
Alexander Belopolsky wrote:
> Raymond suggested that "The PEP 3141 should be revised to say that floor
> division is defined to return a value that is *equal* to an Integral".
I guess it should say "equal to an Integral or a special value&
Stefan Behnel added the comment:
Here is another little optimisation that removes the redundant property lookups
for the denominator in __add__() and __sub__().
New profile:
5291182 function calls (5290800 primitive calls) in 3.596 seconds
Ordered by: internal time
ncalls
Stefan Champailler added the comment:
I don't know if this is 100% related, but here I go. Here's a session in a
windows console (cmd.exe) :
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\stc>chcp 65001
Active code p
Stefan Champailler added the comment:
In my previous comment, I've shown :
print '€'
which is not valid python 3.4.1 (don't why the interpreter didn't complaing
though). So I tested again with missing parenthesis added :
C:\PORT-STCA2\pl-PRIVATE\horse>chcp 6500
Stefan Champailler added the comment:
Dear Drekin,
> The crash you see is maybe not a crash at all. First it has nothing
> to do with printing, the problem is reading of your input line.
I guessed that, but thanks for pointing out.
> So maybe Python REPL then thinks the input just
Stefan Behnel added the comment:
This simple Cython variant of gcd() is substantially faster for me (you may
consider it pseudo-code for a C implementation):
def _gcd(a, b):
# Try doing all computation in C space. If the numbers are too large
# at the beginning, retry until they are
Stefan Behnel added the comment:
BTW, the last two patches (int4 and redundant_property) are ready to be
applied. Anyone?
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Champailler added the comment:
Thank you all for your quick and good answers. This level of responsiveness is
truly amazing.
I've played a bit with IPython and it works just fine. I can type the eurosign
drectly with "Alt Gr - E" (so I didn't enter a unicode
Stefan Behnel added the comment:
I suggest adding a new implementation instead of replacing the current function
in the fractions module. As Mark noted, the current gcd() is more of a
sideeffect of the fractions module, but there's no real need to change that. It
works perfectly ok for a
New submission from Stefan Krah:
The following URL contains copyrighted verbatim text from bytereef.org:
https://pypi.python.org/pypi/m3-cdecimal
I'm not surprised, since the ongoing Walmartization of Open Source
has little regard for authors.
--
messages: 227461
nosy:
Stefan Krah added the comment:
I don't see a license on PKG-INFO itself. Furthermore, even if
it is legal, it (again) shows an utter disregard for authors and
their stated preferences.
I'm not surprised though, given that even existing names are
reassigned in an autocrat
Stefan Krah added the comment:
Sorry, Donald, the actions on PyPI deserve wider exposure.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Yeah right, obviously I don't *really* care about the issue (ethics
in open source software, in case you did not understand).
--
___
Python tracker
<http://bugs.python.org/is
New submission from Stefan Behnel:
fractions.gcd() is required for normalising numerator and denominator of the
Fraction data type. Some speed improvements were applied to Fraction in issue
22464, now the gcd() function takes up about half of the instantiation time in
the benchmark in issue
Stefan Behnel added the comment:
I created issue 22486 about the gcd() performance. I think we can close this
ticket - I don't see any more obvious low hanging fruit and future findings can
have their own ticket.
Out of interest, I modified the fractions module to compile Fraction in
Stefan Behnel added the comment:
That's what the patch does anyway. +1
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
Also see issue 22486. There is an unmerged C implementation in the old issue
1682 that would go into the math module.
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
http://bugs.python.org/file9486/lehmer_gcd.patch
(see #1682)
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Stefan Behnel added the comment:
The problem is that this changes the behaviour of fractions.gcd() w.r.t.
negative numbers. It's a public function, so we should keep it for backwards
compatibility reasons, *especially* when adding a new function in the math
module.
--
compo
Stefan Behnel added the comment:
Oh, and thanks for working on it, Serhiy! :)
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
The thing is, if we add something new in a substantially more exposed place
(the math module), then why break legacy code *in addition*? Just leaving it
the way it is won't harm anyone, really.
--
___
Python tr
Stefan Behnel added the comment:
IMHO, the most straight forward way for a new gcd() function to work would be
to always, predictably return a non-negative value and let users handle all
cases themselves where a negative sign of any or all input values has a
specific meaning to them. That&#
Stefan Behnel added the comment:
+1 for Mark & Terry, just for the record
--
___
Python tracker
<http://bugs.python.org/issue22477>
___
___
Python-bugs-list ma
Stefan Behnel added the comment:
Sorry for reopening this, but I found one more thing. Division is pretty heavy
on PyLong objects and there doesn't seem to be an internal optimisation for
division by 1 and -1. Since many Fraction input values can already be
normalised for some reason
New submission from Stefan Behnel:
The attached patch adds fast paths for PyLong division by 1 and -1, as well as
dividing 0 by something. This was found helpful for fractions normalisation, as
the GCD that is divided by can often be |1|, but firing up the whole division
machinery for this
Stefan Behnel added the comment:
I tried it, but it seems better to open a new ticket for this as there are
behavioural changes. See #22501.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Stefan Behnel added the comment:
Attaching a similar patch for long_mul().
--
Added file: http://bugs.python.org/file36730/mul_by_1_fast_path.patch
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
> Any optimization requires a benchmark. What is the speedup?
I gave numbers in ticket #22464.
"""
Since many Fraction input values can already be normalised for some reason, the
following change shaves off almost 3
Stefan Behnel added the comment:
@Serhiy: moving the fast path into l_divmod() has the disadvantage of making it
even more complex because we'd then also want to determine the modulus, but
only if requested, and it can be 1, 0 or -1, depending on the second value.
Sounds like a lot more
Stefan Behnel added the comment:
Combined patch for both mul and div that fixes the return value of
long_true_div(), as found by Serhiy, and removes the useless change in
long_divrem(), as found by Antoine. Thanks!
All test_long.py tests pass now.
--
Added file: http
Stefan Behnel added the comment:
@Serhiy: please ignore my comment in msg227599. I'll submit a patch that moves
the specialisation to l_divmod().
--
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
Thanks for the reviews, here's a new patch.
--
Added file: http://bugs.python.org/file36732/mul_div_by_1_fast_path_2.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Stefan Behnel :
Removed file: http://bugs.python.org/file36732/mul_div_by_1_fast_path_2.patch
___
Python tracker
<http://bugs.python.org/issue22501>
___
___
Stefan Behnel added the comment:
Sorry, last patch version contained a "use before type check" bug.
--
Added file: http://bugs.python.org/file36733/mul_div_by_1_fast_path_3.patch
___
Python tracker
<http://bugs.python.o
Stefan Behnel added the comment:
Here is an incremental patch that adds fast paths for adding and subtracting 0.
Question: the module calls long_long() in some places (e.g. long_abs()) and
thus forces the return type to be exactly a PyLong and not a subtype. My
changes use a plain "i
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file36736/mul_div_by_1_fast_path_3.patch
___
Python tracker
<http://bugs.python.org/issue22501>
___
___
Pytho
Stefan Behnel added the comment:
Ok, updating both patches.
--
Added file: http://bugs.python.org/file36735/add_sub_0_fast_path_2.patch
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
I reran the fractions benchmark over the final result and the overall gain
turned out to be, well, small. It's a clearly reproducible 2-3% faster. That's
not bad for the macro impact of a micro-optimisation, but it's not a clear
argument for thr
Stefan Krah added the comment:
I'm seeing the same, it could be an Ubuntu issue:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1348275
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Ok, here's my take on the situation:
1) As far as Python is concerned, shape[0] == 1 was already special-cased, so
people could not rely on canonical Fortran or C strides anyway.
2) Accessing an element via strides should be done using PyBuffer_GetPo
Stefan Behnel added the comment:
Thanks, Serhiy. However, something is wrong with the implementation. The
benchmark runs into an infinite loop (it seems). And so do the previous
patches. Does it work for you?
--
___
Python tracker
<h
Stefan Behnel added the comment:
I compiled it with 30 bit digits, in case that's relevant. (It might be.)
--
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
This is what hangs for me:
math.gcd(1216342683557601535506311712, 436522681849110124616458784)
"a" and "b" keep switching between both values, but otherwise, the loop just
keeps running.
The old fractions.gcd
Stefan Behnel added the comment:
I can confirm that it works with 15 bit digits.
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Python-bug
Stefan Behnel added the comment:
Since Serhiy gave another round of valid feedback, here's an updated patch.
--
Added file: http://bugs.python.org/file36739/mul_div_by_1_fast_path_3.patch
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
I callgrinded it again and it confirmed that the gain when doing this inside of
long_div() and friends is way lower than doing it right in Fraction.__new__().
It's not safe to do there, though, as "is" tests on integers are generally not
a good
Stefan Krah added the comment:
Sometimes I've used memoryview slices to model pointers in C code.
memoryview could have limited number methods for pointer arithmetic on the
buf pointer. Arithmetic would return new slices, so in fact everything would
be safe with respect to bounds checkin
Stefan Behnel added the comment:
Patch 7 works for me. Why are the two Py_ABS() calls at the end needed when we
start off the algorithm with long_abs()?
The Lehmer code is complex (I guess that's why you added the pure Euclidean
implementation), but it's the right algorithm to us
Stefan Behnel added the comment:
One more comment: I also benchmarked the change in long_true_div() now and
found that it's only a minor improvement for large numbers and a
*pessimisation* for small numbers:
Before:
$ ./python -m timeit -s 'x = 5' 'x / -1'
1000
Stefan Behnel added the comment:
My personal take is: if there is an implementation in the stdlib, it should be
the one that's most widely applicable. And that includes large numbers. We have
a working implementation that is algorithmically faster for large numbers, so I
can't
Stefan Behnel added the comment:
> That does seem odd -- how can you have 'b' of something?
Don't ask this kind of question as long as any math guys are listening.
But seriously, I consider this proposal reasonable. If the problem is that the
counter values can be non-inte
Stefan Behnel added the comment:
I'd raise an exception whenever the values of the Counter turn out to be
uncomparable. If users manage to fill Counters with non-number values that are
comparable amongst each other, or even if each key has a value of a different
type, why not just su
Stefan Krah added the comment:
FWIW, I think it would be good to make this change early in the
3.5 release cycle, so issues can be found. Sebastian, do you
have an idea when the change will be decided in numpy?
Regarding the discussion here ...
https://github.com/numpy/numpy/issues/5085
Stefan Krah added the comment:
Okay, the whole thing isn't that urgent either.
Sorry for the confusion w.r.t slicing: I misremembered what the
latest numpy version did:
a)
>>> x = np.array([[1,2,3,]])
>>> x.strides
(9223372036854775807, 8)
b)
>>&g
Stefan Krah added the comment:
libmpdec has always been a separate project, predating the integration
into Python-3.3. Before the Python-3.3 release, Jim Jewett suggested
a cleaner library/module separation (and he was right, it made the
code much more readable).
Then distributors wanted
Stefan Krah added the comment:
Of course Windows is a problem. I do not know how to implement
--with-system-libmpdec on Windows.
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
Any objections to merging the last patch?
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
There are not such changes in patch 7. The fractions.gcd() function is
unchanged but no longer used by the Fraction type, which now uses math.gcd()
internally instead.
--
___
Python tracker
<http://bugs.python.
Stefan Behnel added the comment:
+1
I mean, there is already such a type check in Fraction.__init__(), but I can
see a case for also optimising fraction.gcd() for exact ints.
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
Sure.
--
keywords: +patch
Added file: http://bugs.python.org/file36813/undocument_tp_print.patch
___
Python tracker
<http://bugs.python.org/issue19
Stefan Behnel added the comment:
> Proper escaping should be added to the _escape_attrib() function into
> /xml/etree/ElementTree.py (and equivalent for cElementTree).
Agreed. Can you provide a patch?
--
versions: -Python 2.7
___
Python t
Changes by Stefan Behnel :
Removed file: http://bugs.python.org/file36813/undocument_tp_print.patch
___
Python tracker
<http://bugs.python.org/issue19477>
___
___
Pytho
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file36815/undocument_tp_print.patch
___
Python tracker
<http://bugs.python.org/issue19477>
___
___
Python-bug
Stefan Behnel added the comment:
> it might be worth at least considering how a 'one or more parameter' gcd
> compares on performance grounds with a two parameter one.
There shouldn't be a difference in practice. The bulk of the work is in the
algorithm that finds the GC
Stefan Krah added the comment:
Trent, did the HPUX CFLAGS/LDFLAGS change on the buildbots? I think
_decimal used to compile on the PA-RISC bot, but now there is an error.
Perhaps -AC99 or something like that is missing.
--
___
Python tracker
<h
Stefan Krah added the comment:
Antoine, could you add --with-system-libmpdec to my FreeBSD and Fedora
bots? Sorry for bothering you with all these obscure options. :)
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue19
New submission from Stefan Krah:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/3601/steps/test/logs/stdio
==
FAIL: test_wait_for_handle (test.test_asyncio.test_windows_events.ProactorTests
Changes by Stefan Krah :
--
keywords: +buildbot
___
Python tracker
<http://bugs.python.org/issue19952>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Should be done now. Can you check they work fine?
Thank you! Works OK.
--
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Matthias, my target is to release mpdecimal-2.4 on January 9th 2014.
I saw that you started to package mpdecimal-2.3:
http://packages.debian.org/pt/source/sid/misc/mpdecimal
I hope that it can be changed to 2.4: Packaging 2.3 would create
some confusion
New submission from Stefan Krah:
Hi Alexandre, the following leaks appear after 64c6d52793be. I'm
not sure yet if they're caused or just exposed by the changeset.
Code:
==
import sys
import pickle
sys.exit(0)
==
==8118== 864 (192 direct, 672 indirect)
Stefan Krah added the comment:
This patch fixes the leak, but needs review (I do not know the _pickle module
very well).
--
keywords: +patch
Added file: http://bugs.python.org/file33119/issue19972.patch
___
Python tracker
<http://bugs.python.
Changes by Stefan Krah :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue19972>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
See #11826 for more details where the freefunc is called. Perhaps the.
docs or the PEP need an update.
--
___
Python tracker
<http://bugs.python.org/issue19
Stefan Krah added the comment:
The docs say:
inquiry m_clear
A clear function to call during GC clearing of the module object, or NULL
if not needed.
freefunc m_free
A function to call during deallocation of the module object, or NULL if not
needed.
So I assume that GC clearing is
Stefan Behnel added the comment:
I agree that this is an improvement, but isn't it a bit late for removing a
public field from a public header file in 3.4, without any preceding
deprecation?
--
nosy: +scoder
___
Python tracker
Stefan Behnel added the comment:
> what's the migration path for C API users that were relying on that struct
> field?
Depends on how you use it, I guess. In many cases (at least for Cython and
likely some other low-level tools), it could be as simple as
#if PY_VERSION_HEX &
Stefan Behnel added the comment:
> frameobject.h is not included in Python.h, so the
> classic #include "Python.h" doesn't give you access to PyFrameObject
> structure. You have to add a second #include "frameobject.h".
Ah, right. I keep misremembering that, be
New submission from Stefan Krah:
I was just reading the _pickle sources and it appears that AC does not
generate a second arg for METH_NOARGS functions:
#define _PICKLE_PICKLERMEMOPROXY_CLEAR_METHODDEF\
{"clear", (PyCFunction)_pickle_PicklerMemoProxy_clear, M
Stefan Krah added the comment:
STINNER Victor wrote:
> If you prefer to add the unused parameter, what do you propose to avoid
> compiler warnings if unused parameters are checked?
This works quite portably in _decimal (I don't get warnings from gcc, icc,
suncc, Visual Studio,
Stefan Krah added the comment:
Stefan Krah wrote:
> The macro I posted really works on all obscure buildbot platforms.
N.B. clang also defines __GNUC__, as does the intel compiler.
--
___
Python tracker
<http://bugs.python.org/issu
3501 - 3600 of 4952 matches
Mail list logo
