Re: [Python-Dev] Fraction arithmetic (Was: Decimal ... float comparisons in py3k)

On Sat, Mar 20, 2010 at 11:41 AM, Paul Moore p.f.mo...@gmail.com wrote: On 20 March 2010 04:20, Nick Coghlan ncogh...@gmail.com wrote: In the case of floats and Decimals, there's no ambiguity here that creates any temptation to guess - to determine a true/false result for a comparison, floats

Re: [Python-Dev] Decimal - float comparisons in py3k.

On Sat, Mar 20, 2010 at 3:17 PM, Case Vanhorsen cas...@gmail.com wrote: On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson dicki...@gmail.com wrote: What external modules are there that rely on existing hash behaviour? I'm only aware of  gmpy and SAGE. And exactly what behaviour do they rely

Re: [Python-Dev] Decimal - float comparisons in py3k.

On Sat, Mar 20, 2010 at 7:56 PM, Guido van Rossum gu...@python.org wrote: I propose to reduce all hashes to the hash of a normalized fraction, which we can define as a combination of the hashes for the numerator and the denominator. Then all we have to do is figure fairly efficient ways to

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Sat, Mar 20, 2010 at 11:20 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: * Decimal and float really belong side-by-side in the tower, rather than one above the other. Neither of them is inherently any more precise or exact than the other. Except that float is fixed-width (typically 53

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Sun, Mar 21, 2010 at 10:50 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Raymond Hettinger wrote: Since decimal also allows arbitrary sizes, all long ints can be exactly represented (this was even one of the design goals for the decimal module). There may be something we need to

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:   Decimal + float -- Decimal If everybody associated with the Decimal implementation wants this I won't stop you; as I repeatedly said my intuition

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Mon, Mar 22, 2010 at 7:00 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote: Just for the record, I'd also prefer Decimal + Fraction - Decimal. Guido was persuasive on why float + Fraction -- float, so this makes sense

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Mon, Mar 22, 2010 at 8:02 PM, Pierre B. pierre...@hotmail.com wrote: Sorry to intervene out of the blue, but I find the suggested rule for fractional to decimal conversion not as clean as I'd expect. If fractions are converted to decimals when doing arithmetics, would it be worthwhile to

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: While we're on the topic, I think you should consider allowing the Fraction() constructor to accept a decimal input. This corresponds to common schoolbook problems and simple client requests:   Express 3.5

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Mon, Mar 22, 2010 at 8:44 PM, Guido van Rossum gu...@python.org wrote: On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: While we're on the topic, I think you should consider allowing the Fraction() constructor to accept a decimal input. This

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Tue, Mar 23, 2010 at 12:33 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Mark Dickinson wrote: It might make sense for Decimal + complex mixed-type operations to be disallowed, for example. As long as you're allowing Decimal-float comparisons, Decimal-complex comparison for equality

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Tue, Mar 23, 2010 at 12:09 PM, Stefan Krah ste...@bytereef.org wrote: Facundo Batista facundobati...@gmail.com wrote: On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum gu...@python.org wrote: As a downside, there is the worry that inadvertent mixing of Decimal and float can compromise

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Tue, Mar 23, 2010 at 3:09 PM, Stefan Krah ste...@bytereef.org wrote: Mark Dickinson dicki...@gmail.com wrote: [Stefan]  strictness 2: current py3k behaviour + pure equality comparisons Can you explain what you mean by + pure equality comparisons here? If I'm understanding correctly

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen rha...@gmail.com wrote: a = Decimal('nan') a != a They don't follow the behaviour required for being hashable. What's this required behaviour? The only rule I'm aware of is that if a == b then hash(a) == hash(b). That's not violated here. Note

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Tue, Mar 23, 2010 at 6:07 PM, Adam Olsen rha...@gmail.com wrote: On Tue, Mar 23, 2010 at 12:04, Mark Dickinson dicki...@gmail.com wrote: Note that containment tests check identity before equality, so there's no problem with putting (float) nans in sets or dicts: x = float('nan') s = {x

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull step...@xemacs.org wrote: Steven D'Aprano writes:   As usual though, NANs are unintuitive:     d = {float('nan'): 1}   d[float('nan')] = 2   d   {nan: 1, nan: 2}       I suspect that's a feature, not a bug. Right: distinct nans

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Wed, Mar 24, 2010 at 11:47 AM, Nick Coghlan Interning NaN certainly seems like it should be sufficient to eliminate the set/dict membership weirdness. That is, make it so that the first two lines of the following return True, while the latter two lines continue to return False:

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: Mark, I wonder if you could describe an algorithm off the top of your head that relies on NaN == NaN being false. No, I certainly couldn't! And I often wonder if the original IEEE 754 committee, given

[Python-Dev] Why is nan != nan?

[Changing the subject line, since we're way off the original topic] On Wed, Mar 24, 2010 at 7:04 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson dicki...@gmail.com wrote: ..  If Python were to do something different then a naively

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

Slight change of topic. I've been implementing the extra comparisons required for the Decimal type and found an anomaly while testing. Currently in py3k, order comparisons (but not ==, !=) between a complex number and another complex, float or int raise TypeError: z = complex(0, 0) z int()

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Wed, Mar 24, 2010 at 8:56 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: FWIW, my viewpoint on this is softening over time and I no longer feel a need to push for a new context flag. It is probably simplest for users if implicit coercions didn't come with control knobs.  We

Re: [Python-Dev] Why is nan != nan?

On Wed, Mar 24, 2010 at 10:30 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Mar 24, 2010 at 6:21 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: .. If we want to be able to reason about our programs, then we need to rely on equality relations being

Re: [Python-Dev] Why is nan != nan?

On Wed, Mar 24, 2010 at 10:36 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson dicki...@gmail.com wrote: .. Neither is necessary, because Python doesn't actually use == as the equivalence relation for containment testing

Re: [Python-Dev] Why is nan != nan?

On Wed, Mar 24, 2010 at 10:52 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Mar 24, 2010 at 6:47 PM, Mark Dickinson dicki...@gmail.com wrote: .. There's no ideal solution here;  IMO, the compromise that currently exists is an acceptable one. I don't see a compromise

Re: [Python-Dev] Why is nan != nan?

On Wed, Mar 24, 2010 at 11:11 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson dicki...@gmail.com wrote: .. So if I understand correctly, you propose that float('nan') == float('nan') return True.  Would you also suggest extending

Re: [Python-Dev] Why is nan != nan?

On Thu, Mar 25, 2010 at 11:22 AM, Nick Coghlan ncogh...@gmail.com wrote: Mark Dickinson wrote: Here's an interesting recent blog post on this subject, from the creator of Eiffel: http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ Interesting. So the natural

Re: [Python-Dev] Why is nan != nan?

On Thu, Mar 25, 2010 at 11:22 AM, Nick Coghlan ncogh...@gmail.com wrote: So, I'm specifically putting that proposal on the table for both float and Decimal NaNs in Python:  Not a Number is not a single floating point value. Instead each  instance is a distinct value representing the precise

Re: [Python-Dev] Why is nan != nan?

On Thu, Mar 25, 2010 at 12:36 PM, Jesus Cea j...@jcea.es wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/25/2010 07:54 AM, Georg Brandl wrote: float('nan') in [float('nan')] False Sure, but just think of it as having two different nans there.  (You could imagine thinking of the

Re: [Python-Dev] Why is nan != nan?

On Thu, Mar 25, 2010 at 12:39 PM, Jesus Cea j...@jcea.es wrote: But IEEE 754 was created by pretty clever guys and sure they had a reason for define things in the way they are. Probably we are missing something. Well, if we are, then nobody seems to know what! See the Bertrand Meyer blog

Re: [Python-Dev] Why is nan != nan?

On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan ncogh...@gmail.com wrote: Jesus Cea wrote: But IEEE 754 was created by pretty clever guys and sure they had a reason for define things in the way they are. Probably we are missing something. Yes, this is where their implementable in a hardware

Re: [Python-Dev] Why is nan != nan?

On Thu, Mar 25, 2010 at 2:26 PM, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 25 Mar 2010 07:19:24 -0700, Curt Hagenlocher a écrit : Wait, what? I haven't been paying much attention, but this is backwards. There are multiple representations of NaN in the IEEE encoding; that's actually

Re: [Python-Dev] Why is nan != nan?

On Thu, Mar 25, 2010 at 2:42 PM, Mark Dickinson dicki...@gmail.com wrote: On Thu, Mar 25, 2010 at 2:26 PM, Antoine Pitrou solip...@pitrou.net wrote: This sounds a bit sophistic, if the (Python) user doesn't have access to the payload anyway. Well, you can get at the payload using the struct

Re: [Python-Dev] Why is nan != nan?

On Thu, Mar 25, 2010 at 3:01 PM, Curt Hagenlocher c...@hagenlocher.org wrote: On Thu, Mar 25, 2010 at 7:54 AM, Mark Dickinson dicki...@gmail.com wrote: Hmm. I take it back.  I was being confused by the fact that sqrt(nan) returns a nan with a new identity;  but it does apparently preserve

Re: [Python-Dev] Why is nan != nan?

On Thu, Mar 25, 2010 at 3:05 PM, Nick Coghlan ncogh...@gmail.com wrote: Mark Dickinson wrote: On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan ncogh...@gmail.com wrote: Jesus Cea wrote: But IEEE 754 was created by pretty clever guys and sure they had a reason for define things in the way

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Thu, Mar 25, 2010 at 1:15 AM, Jeffrey Yasskin jyass...@gmail.com wrote: On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson dicki...@gmail.com wrote: Slight change of topic.  I've been implementing the extra comparisons required for the Decimal type and found an anomaly while testing. Currently

Re: [Python-Dev] Why is nan != nan?

On Fri, Mar 26, 2010 at 11:16 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: Of the ideas I've seen in this thread, only two look reasonable: * Do nothing.  This is attractive because it doesn't break anything. * Have float.__eq__(x, y) return True whenever x and y are    the same

Re: [Python-Dev] Optional delta argument for assertAlmostEqual

On Sat, Mar 27, 2010 at 12:59 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: Hello all, A user has suggested an optional argument to unittest.TestCase.assertAlmostEqual for specifying a maximum difference between the expected and actual values, instead of using rounding. +1. Mark

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

On Mon, Mar 22, 2010 at 7:52 PM, Guido van Rossum gu...@python.org wrote: On Mon, Mar 22, 2010 at 11:36 AM, Raymond Hettinger raymond.hettin...@gmail.com wrote: One other thought. The Decimal constructor should now accept floats as a possible input type. Formerly, we separated that out to

Re: [Python-Dev] [buildbots] 'stop build' button causing subsequent builds to fail?

On Fri, Apr 2, 2010 at 3:54 PM, Stefan Krah ste...@bytereef.org wrote: I looks like the 'stop build' button can a) cause subsequent builds to fail and b) cause pending builds to be deleted from the queue. a) http://www.python.org/dev/buildbot/builders/ARM Linux EABI 3.x/builds/18   was

Re: [Python-Dev] ffi junk messages

On Wed, Apr 7, 2010 at 1:39 PM, Jeroen Ruigrok van der Werven asmo...@in-nomine.org wrote: Before I file a bug report, is anyone else seeing this (in my case on FreeBSD 8): Modules/_ctypes/libffi/src/x86/sysv.S:360: Error: junk at end of line, first unrecognized character is `@'

Re: [Python-Dev] Very Strange Argument Handling Behavior

On Fri, Apr 16, 2010 at 9:04 AM, Hagen Fürstenau ha...@zhuliguan.net wrote: This behavior seems pretty strange to me, indeed PyPy gives the TypeError for both attempts.  I just wanted to confirm that it was in fact intentional. Oleg already answered why f(**{1:3}) raises a TypeError. But your

Re: [Python-Dev] Very Strange Argument Handling Behavior

On Fri, Apr 16, 2010 at 3:33 PM, Guido van Rossum gu...@python.org wrote: On Fri, Apr 16, 2010 at 7:15 AM, Nick Coghlan ncogh...@gmail.com wrote: I would agree with leaving it implementation defined - I don't think either PyPy or CPython should be forced to change their current behaviour in

Re: [Python-Dev] Very Strange Argument Handling Behavior

On Fri, Apr 16, 2010 at 3:57 PM, Antoine Pitrou solip...@pitrou.net wrote: Mark Dickinson dickinsm at gmail.com writes: Okay;  I'll open an issue for deprecation in 3.2 and removal in 3.3. Can this sneak in under the 'incorrect language semantics' exemption for PEP 3003 (the moratorium PEP

Re: [Python-Dev] bbreport

On Sat, Apr 17, 2010 at 7:41 PM, Victor Stinner victor.stin...@haypocalc.com wrote: Ezio and Florent are developing a tool called bbreport to collect buildbot results and generate short reports to the command line. It's possible to filter results by Python branch, builder name, etc. I send

Re: [Python-Dev] PEP 328, relative imports and Python 2.7

On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw ba...@python.org wrote: While talking about Python 2.6 - 2.7 transitions, the subject of relative and absolute imports has come up.  PEP 328 states that absolute imports will be enabled by default in Python 2.7, however I cannot verify that this has

Re: [Python-Dev] PEP 328, relative imports and Python 2.7

On Wed, Apr 21, 2010 at 2:56 PM, Mark Dickinson dicki...@gmail.com wrote: On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw ba...@python.org wrote: While talking about Python 2.6 - 2.7 transitions, the subject of relative and absolute imports has come up.  PEP 328 states that absolute imports

Re: [Python-Dev] Did I miss the decision to untabify all of the C code?

On Thu, May 6, 2010 at 4:52 AM, Joao S. O. Bueno jsbu...@python.org.br wrote: On Wed, May 5, 2010 at 9:59 PM, Eric Smith e...@trueblade.com wrote: That's my point. Since it's basically unreviewable, is it smart to do it during a beta? Hello folks - I don't think these modifications are that

Re: [Python-Dev] Incorrect length of collections.Counter objects / Multiplicity function

On Tue, May 18, 2010 at 11:00 PM, Gustavo Narea m...@gustavonarea.net wrote: I've checked the new collections.Counter class and I think I've found a bug: from collections import Counter c1 = Counter([1, 2, 1, 3, 2]) c2 = Counter([1, 1, 2, 2, 3]) c3 = Counter([1, 1, 2, 3]) c1 == c2 and

Re: [Python-Dev] Incorrect length of collections.Counter objects / Multiplicity function

On Thu, May 20, 2010 at 10:18 PM, Mark Dickinson dicki...@gmail.com wrote: See also this recent thread on python-list, and in particular the messages from Raymond Hettinger in that thread: http://mail.python.org/pipermail/python-list/2010-March/thread.html Sorry, bad thread link. Try: http

Re: [Python-Dev] variable name resolution in exec is incorrect

On Wed, May 26, 2010 at 10:15 AM, Colin H hawk...@gmail.com wrote:   issue991196 was closed being described as intentional.  I've added a comment in that issue which argues that this is a serious bug (also aserted by a previous commenter - Armin Rigo), because it creates a unique,

Re: [Python-Dev] Language Summit notes

On Wed, Apr 16, 2014 at 11:26 PM, Antoine Pitrou solip...@pitrou.netwrote: What does this mean exactly? Under OS X and Linux, Python is typically installed by default. Under OS X, at least, I think there are valid reasons to not want to use the system-supplied Python. On my up-to-date OS X

Re: [Python-Dev] is the concept of 'reference ownership' no long applicable in Python 3.4?

On Thu, Apr 17, 2014 at 4:34 PM, Jianfeng Mao j...@rocketsoftware.comwrote: I noticed the following changes in the C API manuals from 3.3.5 (and earlier versions) to 3.4. I don’t know if these changes are deliberate and imply that we C extension developers no longer need to care about

Re: [Python-Dev] is the concept of 'reference ownership' no long applicable in Python 3.4?

On Thu, Apr 17, 2014 at 5:33 PM, Mark Dickinson dicki...@gmail.com wrote: This looks like a doc build issue: when I build the documentation locally for the default branch, I still see the expected Return value: New reference. lines. Opened http://bugs.python.org/issue21286 for this issue

Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?

[Moderately off-topic] On Sun, Aug 17, 2014 at 3:39 AM, Steven D'Aprano st...@pearwood.info wrote: I used to refer to Python 4000 as the hypothetical compatibility break version. Now I refer to Python 5000. I personally think it should be Python 500, or Py5M. When we come to create the

Re: [Python-Dev] Drastically improving list.sort() for lists of strings/ints

On Sun, Sep 11, 2016 at 7:43 PM, Elliot Gorokhovsky wrote: > So I suppose the thing to do is to benchmark stable radix sort against > timsort and see if it's still worth it. Agreed; it would definitely be interesting to see benchmarks for the two-array stable sort

Re: [Python-Dev] Drastically improving list.sort() for lists of strings/ints

> I am interested in making a non-trivial improvement to list.sort() [...] Would your proposed new sorting algorithm be stable? The language currently guarantees stability for `list.sort` and `sorted`. -- Mark ___ Python-Dev mailing list

Re: [Python-Dev] 64 bit units in PyLong

On Mon, Jul 3, 2017 at 5:52 AM, Siyuan Ren wrote: > The current PyLong implementation represents arbitrary precision integers in > units of 15 or 30 bits. I presume the purpose is to avoid overflow in > addition , subtraction and multiplication. But compilers these days

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Fri, Jun 22, 2018 at 7:28 PM, Chris Barker via Python-Dev < python-dev@python.org> wrote: > > But once it becomes a more common idiom, students will see it in the wild > pretty early in their path to learning python. So we'll need to start > introducing it earlier than later. > > I think this

Re: [Python-Dev] Symmetry arguments for API expansion

On Mon, Mar 12, 2018 at 4:49 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > What is the proposal? > * Add an is_integer() method to int(), Decimal(), Fraction(), and Real(). > Modify Rational() to provide a default implementation. > >From the issue discussion, it sounds to me as

Re: [Python-Dev] Symmetry arguments for API expansion

On Mon, Mar 12, 2018 at 9:18 PM, Tim Peters wrote: > [Guido] > > as_integer_ratio() seems mostly cute (it has Tim Peters all > > over it), > > Nope! I had nothing to do with it. I would have been -0.5 on adding > it had I been aware at the time. > Looks like it

Re: [Python-Dev] Deprecating float.is_integer()

I'd prefer to see `float.is_integer` stay. There _are_ occasions when one wants to check that a floating-point number is integral, and on those occasions, using `x.is_integer()` is the one obvious way to do it. I don't think the fact that it can be misused should be grounds for deprecation. As

Re: [Python-Dev] Deprecating float.is_integer()

On Wed, Mar 21, 2018 at 8:49 PM, David Mertz wrote: > For example, this can be true (even without reaching inf): > > >>> x.is_integer() > True > >>> (math.sqrt(x**2)).is_integer() > False > If you have a moment to share it, I'd be interested to know what value of `x` you used

[Python-Dev] Re: What is __int__ still useful for?

I'd propose that we relegate `__trunc__` to the same status as `__floor__` and `__ceil__`: that is, have `__trunc__` limited to being support for `math.trunc`, and nothing more. Right now the `int` constructor potentially looks at all three of `__int__`, `__index__` and `__trunc__`, so the

[Python-Dev] Re: What is __int__ still useful for?

Meta: apologies for failing to trim the context in the previous post. -- Mark ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Fri, Dec 31, 2021 at 12:40 PM Skip Montanaro wrote: > Perhaps I missed it, but maybe an action item would be to add a > buildbot which configures for 15-bit PyLong digits. > Yep, good point. I was wrong to say that "15-bit builds don't appear to be exercised by the buildbots": there's a

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

Thanks all! So to summarize: - 15-bit digits are still very much in use, and deprecating the option would likely be premature at this point - the main users are old 32-bit (x86), which it's difficult to care about too much, and new 32-bit (principally ARM microarchitectures), which we *do* care

[Python-Dev] Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

tl;dr: I'd like to deprecate and eventually remove the option to use 15-bit digits in the PyLong implementation. Before doing so, I'd like to find out whether there's anyone still using 15-bit PyLong digits, and if so, why they're doing so. History: the use of 30-bit digits in PyLong was

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sat, Jan 1, 2022 at 9:05 PM Antoine Pitrou wrote: > Note that ARM is merely an architecture with very diverse > implementations having quite differing performance characteristics. [...] > Understood. I'd be happy to see timings on a Raspberry Pi 3, say. I'm not too worried about things like

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sat, Jan 15, 2022 at 8:12 PM Tim Peters wrote: > Something is missing here, but can't guess what without seeing the > generated machine code.But I trust Mark will do that. > Welp, there goes my weekend. :-) $ python -m timeit -n 150 -s "x = 10**1000" "x//10" 150 loops, best of 5:

[Python-Dev] Re: PEP 682: Format Specifier for Signed Zero

PEP 682 (Format Specifier for Signed Zero) has been accepted! Please see https://discuss.python.org/t/accepting-pep-682-format-specifier-for-signed-zero/14088 Thanks to all involved, Mark ___ Python-Dev mailing list -- python-dev@python.org To

[Python-Dev] Should we require IEEE 754 floating-point for CPython?

On Mon, Feb 7, 2022 at 5:11 PM Victor Stinner wrote: > I made a change to require C99 "NAN" constant [...] There's a separate discussion topic lurking here. It's equally in need of discussion here (IMO), but it's orthogonal to the "should we require C99" discussion. I've changed the subject

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sun, Jan 2, 2022 at 10:35 AM Mark Dickinson wrote: > Division may still be problematic. > On that note: Python divisions are somewhat crippled even on x64. Assuming 30-bit digits, the basic building block that's needed for multi-precision division is a 64-bit-by-32-bit unsigned i

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sun, Jan 16, 2022 at 4:11 PM Terry Reedy wrote: > > > https://stackoverflow.com/questions/41183935/why-does-gcc-use-multiplication-by-a-strange-number-in-implementing-integer-divi > > and > > > https://stackoverflow.com/questions/30790184/perform-integer-division-using-multiplication > > have

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sun, Jan 16, 2022 at 12:08 PM Mark Dickinson wrote: > So gcc is anticipating divisions by 10 and introducing special-case > divide-by-reciprocal-multiply code for that case, and presumably the > profile generated for the PGO backs up this being a common enough case, so &g

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sun, Jan 16, 2022 at 9:28 PM Guido van Rossum wrote: > Does the optimization for //10 actually help in the real world? [...] > Yep, I don't know. If 10 is *not* the most common small divisor in real world code, it must at least rank in the top five. I might hazard a guess that division by 2

<    1   2   3   4