Mark Dickinson dicki...@gmail.com added the comment:
I think Greg's patch looks fine, modulo updating it to apply cleanly to
py3k.
I couldn't resist tinkering a bit, though: factoring out the complement
operations (for a, b and z) into a separate function gives (IMO) cleaner
and more direct
Martin v. Löwis mar...@v.loewis.de added the comment:
Mark, if you want to get reviews, it might be useful to upload the patch
to Rietveld (as the diff is difficult to read). However, I would trust
you to get it right, anyway, so feel free to go ahead and apply it.
--
Mark Dickinson dicki...@gmail.com added the comment:
Applied in r75697 (trunk) and r75698 (py3k).
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1087418
Antoine Pitrou pit...@free.fr added the comment:
The type is an important performance factor but most uses of it are for
small ints ( 2**32 or 2**64), so your approach wouldn't make much of a
difference.
Besides, there are already some improvements in the py3k branch (for
example, longs now use
Mark Dickinson dicki...@gmail.com added the comment:
[Greg]
It would seem to me that a more suitable implementation would be to
store numbers as 32*k-bit 2's complement integers; I've used this in
C++ libraries. Compared to the rad-15 sign/magnitude approach, it may
seem trickier to do
Mark Dickinson dicki...@gmail.com added the comment:
Here's the inline assembly version, for comparison:
#define SUM2_BIN64(sumhigh, sumlow, ahigh, alow, bhigh, blow)\
__asm__ (addq\t%5, %1\n\t\
adcq\t%3, %0
Gregory Smith gregsm...@users.sourceforge.net added the comment:
Antoine, most uses of it are for small ints ( 2**32 or 2**64), ,
that's my point exactly, the current long type is quite slow for those
cases because of sign-magnitude implementation.
I don't see a problem with sign-magnitude for
Martin v. Löwis mar...@v.loewis.de added the comment:
I would be happy to do a design doc for this and write some of the inner
loops, but if (a) it's already being done or (b) there's no chance of it
being deployed then it would be a waste of time...
if there was definite interest in it (and
Mark Dickinson dicki...@gmail.com added the comment:
Most operations are add and subtract, and in each such operation you
need to look at both signs, and decide if you want to really add or
subtract, and if you are subtracting, you then have to do a magnitude
test to see which way - all of
Changes by Tracy Poff tracy.p...@gmail.com:
--
nosy: +sopoforic
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1087418
___
___
Python-bugs-list
Gregory Smith gregsm...@users.sourceforge.net added the comment:
Actually, my view for 3.x is this: I do agree hugely with the 'top
level' decision to only have one type that handles everything, and
obviously the easiest way to get there is to just use the existing long
type. However, though the
Changes by Daniel Diniz aja...@gmail.com:
--
nosy: +marketdickinson
stage: - test needed
type: - performance
versions: +Python 2.7, Python 3.1 -Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1087418
Christian Heimes added the comment:
It's probably useful for Python 3.0 since the old int type is gone.
--
nosy: +tiran
priority: low - normal
versions: +Python 2.6, Python 3.0
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1087418
13 matches
Mail list logo
