[issue47257] add methods to get first and last elements of a range

Mark Dickinson added the comment: > but it's messy and potentially tricky to get the actual first and last values > of the range Doesn't simple indexing already provide what you need here? >>> range(1, 5, 2)[0] # first element of range 1 >>> range(1, 5, 2)[-1] #

[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception

Mark Dickinson added the comment: FWIW, I do consider this a bug, albeit a minor one. I may find time to fix it at some point (but it's fine to leave it closed until that time comes). -- ___ Python tracker <https://bugs.python.org/issue28

[issue45995] string formatting: normalize negative zero

Mark Dickinson added the comment: I forgot to update here: > PEP at https://github.com/python/peps/pull/2295 For the record, PEP 682 has been accepted. -- ___ Python tracker <https://bugs.python.org/issu

[issue46971] python takes long time when return big data

Mark Dickinson added the comment: > why it costs lots of time when del a large array? That's probably a question for the NumPy folks, or possibly for Stack Overflow or some other question-and-answer resource. It'll depend on how NumPy arrays are de-allocated. > Is there any way to p

[issue46971] python takes long time when return big data

Mark Dickinson added the comment: This is expected. Your timing measures the time for garbage collection of the large arrays in addition to the time for the result to be returned. In the line `result = myfunc()`, the name `result` gets rebound to the value of `myfunc()`. That means

[issue46920] Remove code made dead long ago with #if 0

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue46920> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46929] __rrshift__ for same class obj will raise TypeError

Mark Dickinson added the comment: This is the intended behaviour. See the docs here: https://docs.python.org/3/reference/datamodel.html#object.__ror__ > These functions are only called if the left operand does not support the > corresponding operation and the operands are of different

[issue46917] Require IEEE 754 floating point to build Python 3.11

Mark Dickinson added the comment: > * Mention the new build requirement in What's New in Python 3.11. > * Modify configure script to make it fail if the IEEE 754 support is missing. > * Remove code handling missing NAN and infinity: float("nan"), float("inf&quo

[issue6778] False positives given through bisect module (binary search)

Change by Mark Dickinson : -- components: +Extension Modules ___ Python tracker <https://bugs.python.org/issue6778> ___ ___ Python-bugs-list mailing list Unsub

[issue6778] False positives given through bisect module (binary search)

Change by Mark Dickinson : -- components: -Distutils, Documentation, Extension Modules, Installation, Parser, email nosy: -barry, docs@python, dstufft, eric.araujo, lys.nikolaou, pablogsal type: security -> behavior ___ Python tracker <

[issue46852] Remove the float.__setformat__() method

Mark Dickinson added the comment: > I reopen the issue for the second part of my plan Hmm. That sounds like it should be a separate issue, or at the least, this issue should be retitled. It's helpful to keep issue titles accurate. -- ___ Pyt

[issue46852] Remove the float.__setformat__() method

Mark Dickinson added the comment: Thanks, Victor. I think this can be closed now. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue46852] Remove the float.__setformat__() method

Mark Dickinson added the comment: I'd be happy to see `float.__setformat__` go, if it's not still needed for Python's test suite (which was its entire raison d'être). If no-one noticed the accidental misnaming, then it's pretty clear no-one's been using it. I'd like to bet

[issue46804] spam

Change by Mark Dickinson : -- title: Yaytext.net - Tạo văn bản chữ kiểu, kí tự đặc biệt độc đáo -> spam ___ Python tracker <https://bugs.python.org/issu

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Change by Mark Dickinson : -- nosy: -mark.dickinson ___ Python tracker <https://bugs.python.org/issue24053> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: > I gave the code example in order to make that clear. Yep, that didn't help: reverse engineering the intended behaviour from a complicated piece of code isn't easy. An up-front description of the intended behaviour would be bet

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: Re python-ideas: there's a mailing list: https://mail.python.org/archives/list/python-id...@python.org/ But the https://discuss.python.org/c/ideas/ category also works for this. -- ___ Python tracker <ht

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: Okay, let's close here; as Raymond says, that doesn't prevent further discussion on python-ideas. > The notions are currently too immature to warrant more core developer time. Agreed. It seems that what Lee wants is some kind of blend between the simpl

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: > I'd modify the optimization to be that we continue to seek the smallest > denominator, but in the case that multiple numerators would give ratios > within the computed interval then we choose the numerator among these that > gives the r

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: One more example: what interval is implied by an input string of "1600"? Is it (1550, 1650)? Or (1595, 1605)? Or even (1599.5, 1600.5). Sorry, I just don't see this working - there are two many arbitrary choices involved in guessing what interva

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: Sigh: > the next representable value up from 0.01 is 0.011 should say: > the next representable value up from 0.10 is 0.11 I think I'll duck out and give my brain a rest before commenting further. -- ___

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: > in which case the interval we need is [0.095, 0.15] Whoops, sorry; brain fail. If we're rounding to two sig figs, the next representable value up from 0.01 is 0.011, while the next one down is 0.099, so the interval we'd be interested in would be [0.0

[issue46780] Allow Fractions to return 1/6 for "0.17", "0.167", "0.1667", etc.

Mark Dickinson added the comment: > the constructed Fraction first computes the range of the values that the > input string could have been rounded from There's too much magic and guesswork here for my liking; I don't really see this as feasible. Moreover, depending on which roundin

[issue46739] dataclasses __eq__ isn't logical

Mark Dickinson added the comment: Can you explain why you think the result of `a == b` should be `False` rather than `True`? By default, equality for dataclasses is structural equality, and `True` is the result that I'd expect here. >From the >[docs](https://docs.python.org/3/l

[issue46737] Default to the standard normal distribution

Mark Dickinson added the comment: +1 -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue46737> ___ ___ Python-bugs-list mailing list Unsub

[issue46724] Odd Bytecode Generation in 3.10

Change by Mark Dickinson : -- nosy: +Mark.Shannon ___ Python tracker <https://bugs.python.org/issue46724> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46694] isdigit/isnumeric vs int()

Change by Mark Dickinson : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue46694] isdigit/isnumeric vs int()

Mark Dickinson added the comment: This is by design: int looks for characters with the Unicode Decimal (De) numeric type, corresponding to str.isdecimal(), rather than for the Digit (Di) or Numeric (Nu) numeric types. >>> "²".isdecimal() False -- no

[issue46639] Ceil division with math.ceildiv

Mark Dickinson added the comment: > Couldn't math.ceildiv(x, y) be implemented as -(-x//y) in a type-agnostic > fashion? Ah, good point. Yes, that could work. We'd have to decide what to do about Decimal if we took this approach, since the -(-x//y) trick doesn't work there. (Do

[issue46663] test_math test_cmath test_complex fails on Fedora Rawhide buildbots

Mark Dickinson added the comment: @vstinner What was the change that caused the buildbots to start failing? Did the GCC version get updated on those machines between the last runs and this one, or was the change due to recent PRs in Python? -- nosy: +mark.dickinson

[issue46656] Compile fails if Py_NO_NAN is defined

Mark Dickinson added the comment: > See the explanations in the source. Hmm. Those explanations made more sense before PR GH-28882. :-( -- ___ Python tracker <https://bugs.python.org/issu

[issue46656] Compile fails if Py_NO_NAN is defined

Mark Dickinson added the comment: > Is the macro PY_NO_SHORT_FLOAT_REPR also related to platforms which don't > support IEEE 754? Yes, though it's a bit more than that: we also need the platform either not to have issues with double rounding for normal numbers, or we need to b

[issue46656] Compile fails if Py_NO_NAN is defined

Mark Dickinson added the comment: Okay, the comments I made on #46640 still apply (even though they didn't properly apply on that issue). I think this needs a python-dev discussion before it can be moved forward - requiring the existence of NaNs is very close to requiring IEEE 754 floating

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: Ah, https://math.mit.edu/research/highschool/primes/materials/2019/Gopalakrishna.pdf is interesting - they conjecture a bound on the number of iterations required, and note that under that conjecture the mod can be replaced by a subtraction

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: Thanks, Tim; very interesting. I hadn't seen this factoring algorithm before. > That wants the _ceiling_ of the square root. Looks like what it actually wants is the ceiling analog of isqrtrem: that is, it needs both the ceiling of the square r

[issue46656] Compile fails if Py_NO_NAN is defined

Mark Dickinson added the comment: Here's the first point of failure on my machine. Fixing this shows up more failures. gcc -c -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes

[issue46656] Compile fails if Py_NO_NAN is defined

New submission from Mark Dickinson : The macro Py_NAN may or may not be defined: in particular, a platform that doesn't have NaNs is supposed to be able to define Py_NO_NAN in pyport.h to indicate that. But not all of our uses of `Py_NAN` are guarded by suitable #ifdef conditionals

[issue46639] Ceil division with math.ceildiv

Mark Dickinson added the comment: [Tim] > Because it's a bit obscure, and in real life y is always known to be > positive, so the nearly obvious (x + y - 1) // y works fine. Whereas I find (x + y - 1) // y less obvious at first sight than -(-x // y). :-) I don't care about nega

[issue46640] Python can now use the C99 NAN constant

Mark Dickinson added the comment: > If a platform doesn't implement NaN, it should define the Py_NO_NAN macro Ah. In that case your PR description (and the PR news entry) is misleading: > Building Python now requires a C99 header file providing the > NAN constant. Please could y

[issue46639] Ceil division with math.ceildiv

Mark Dickinson added the comment: I'm not convinced that this deserves to be a math module function. I agree that `-(-x // y)`, while simple to write, isn't necessarily obvious. But it does have some advantages, like not needing an import, and being naturally duck-typed, so

[issue46640] Python can now use the C99 NAN constant

Mark Dickinson added the comment: The big blocker here is that a platform that fully supports C99 might not define the "NAN" macro. I don't think we can require that NAN be defined in order for Python to build (which is what the PR currently does, if I'm understanding it correctly

[issue44734] turtle: tests for Vec2D.__abs__ are too strict

Mark Dickinson added the comment: Sorry again, all; I failed to read everything that was going on here. The test *wasn't* failing with the hypot-based version of Vec2D.__abs__ that's in the main branch; only with the "**0.5"-based version that was still in the older branches. Ple

[issue44734] turtle: tests for Vec2D.__abs__ are too strict

Mark Dickinson added the comment: Apologies; looks like I'm out of date on this. It's already using hypot, which makes it more than a little worrying that it doesn't get the right answer for `Vec2D(6, 8)`. -- ___ Python tracker <ht

[issue44734] turtle: tests for Vec2D.__abs__ are too strict

Mark Dickinson added the comment: Low priority, but it may also be worth updating the implementation of `Vec2D.__abs__`. It currently looks like this: def __abs__(self): return (self[0]**2 + self[1]**2)**0.5 But would be more robust if it used hypot: def __abs__(self

[issue46488] listsort.txt wrongly assumes you cannot calculate leading zeros in O(1) time.

Change by Mark Dickinson : -- nosy: +tim.peters ___ Python tracker <https://bugs.python.org/issue46488> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46406] optimize int division

Change by Mark Dickinson : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46406> ___ ___ Pyth

[issue46406] optimize int division

Mark Dickinson added the comment: New changeset c7f20f1cc8c20654e5d539552604362feb9b0512 by Gregory P. Smith in branch 'main': bpo-46406: Faster single digit int division. (#30626) https://github.com/python/cpython/commit/c7f20f1cc8c20654e5d539552604362feb9b0512

[issue29882] Add an efficient popcount method for integers

Mark Dickinson added the comment: New changeset 83a0ef2162aa379071e243f1b696aa6814edcd2a by Mark Dickinson in branch 'main': bpo-29882: Fix portability bug introduced in GH-30774 (#30794) https://github.com/python/cpython/commit/83a0ef2162aa379071e243f1b696aa6814edcd2a

[issue29882] Add an efficient popcount method for integers

Change by Mark Dickinson : -- pull_requests: +28979 pull_request: https://github.com/python/cpython/pull/30794 ___ Python tracker <https://bugs.python.org/issue29

[issue45995] string formatting: normalize negative zero

Mark Dickinson added the comment: [John] > Mark, would you give it a review this month? Apologies; my holiday-break free time was nobbled from unexpected quarters. I can't promise to find time this month, but I can promise to try. I did at least skim through the PR, and wh

[issue46444] Wrong value of pi for larger values using math.cos() function

Mark Dickinson added the comment: Hi Darshan. This isn't a bug in Python. You're running into the limitations of floating-point arithmetic. There's a lot of good material on those limitations available on the web, starting with Python's own tutorial: https://docs.python.org/3/tutorial

[issue46423] CLI: Addition assignment for tuples

Mark Dickinson added the comment: Thanks for the report. This is a long-standing and known behaviour. It's been discussed a good few times before, and (quite apart from potential problems with backwards compatibility) no-one has yet come up with convincing alternative behaviours. See

[issue46393] Generate frozenset constants when explicitly appropriate

Change by Mark Dickinson : -- nosy: -mark.dickinson ___ Python tracker <https://bugs.python.org/issue46393> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46361] Small ints aren't always cached properly

Change by Mark Dickinson : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue46361] Small ints aren't always cached properly

Mark Dickinson added the comment: New changeset 5cd9a162cd02a3d0f1b0a182d80feeb17439e84f by Brandt Bucher in branch 'main': bpo-46361: Fix "small" `int` caching (GH-30583) https://github.com/python/cpython/commit/5cd9a162cd02a3d0f1b0a182d80fee

[issue46372] int/float specializations should mutate the LHS in-place when possible

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue46372> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46393] Generate frozenset constants when explicitly appropriate

Mark Dickinson added the comment: > That's not always the case though. Sorry, yes - I see. We're not creating a frozenset from a frozenset - we're creating a frozenset from a regular set from a frozenset. :-( Sorry for the noise. -- ___ Pyt

[issue46393] Generate frozenset constants when explicitly appropriate

Mark Dickinson added the comment: [Terry] > To avoid the intermediate set, [...] It's not quite as bad as that: there _is_ no intermediate set (or if you prefer, the intermediate set is the same object as the final set), since the frozenset call returns its argument unchanged if i

[issue46258] Minor algorithmic improvements for math.isqrt

Change by Mark Dickinson : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46258> ___ ___ Pyth

[issue46258] Minor algorithmic improvements for math.isqrt

Mark Dickinson added the comment: New changeset d02c5e9b55a8651b7d396ac3f2bdedf1fc1780b5 by Mark Dickinson in branch 'main': bpo-46258: Streamline isqrt fast path (#30333) https://github.com/python/cpython/commit/d02c5e9b55a8651b7d396ac3f2bdedf1fc1780b5

[issue45569] Drop support for 15-bit PyLong digits?

Mark Dickinson added the comment: New changeset 025cbe7a9b5d3058ce2eb8015d3650e396004545 by Mark Dickinson in branch 'main': bpo-45569: Change PYLONG_BITS_IN_DIGIT default to 30 (GH-30497) https://github.com/python/cpython/commit/025cbe7a9b5d3058ce2eb8015d3650e396004545

[issue45569] Drop support for 15-bit PyLong digits?

Mark Dickinson added the comment: Thanks, Stefan. I think I'm going to go ahead with the first step of making 30-bit digits the default, then, but leaving the 15-bit digit option present. > That said, if we decide to keep 15-bit digits in the end, I wonder if > "SIZEOF_VOID_P&qu

[issue46361] Small ints aren't always cached properly

Mark Dickinson added the comment: And there are some similar things going on in rangeobject.c. https://github.com/python/cpython/blob/1de60155d5d01be2924e72fb68dd13d4fd00acd7/Objects/rangeobject.c#L598 if (r->step == _PyLong_GetOne()) { return idx; } Ag

[issue46361] Small ints aren't always cached properly

Mark Dickinson added the comment: Hmm. This sort of thing is a little dodgy, though (despite the comment that it's "okay"): https://github.com/python/cpython/blob/1de60155d5d01be2924e72fb68dd13d4fd00acd7/Modules/mathmodule.c#L939 PyObject *zero = _PyLong_GetZero(); // bo

[issue46361] Small ints aren't always cached properly

Mark Dickinson added the comment: I don't *think* we currently rely on small integers being cached anywhere in the implementation (and neither do we guarantee anywhere in the docs that small integers will be cached), so as far as I can tell these omissions shouldn't lead to user-visible

[issue45569] Drop support for 15-bit PyLong digits?

Mark Dickinson added the comment: Adding Stefan Behnel to the nosy, since Cython is one of the few projects that might be directly affected by this change. Stefan: can you see any potential problems with changing the default to 30 here? -- nosy: +scoder

[issue46272] Fix bitwise and logical terminology in python.gram

Mark Dickinson added the comment: > So, the meaning of these names like this is, "lt followed by an optional > bitwise_or expression"? That's certainly how I was reading it. -- ___ Python tracker <https://bugs.py

[issue46272] Fix bitwise and logical terminology in python.gram

Change by Mark Dickinson : -- keywords: +patch pull_requests: +28706 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30499 ___ Python tracker <https://bugs.python.org/issu

[issue46311] Clean up PyLong_FromLong and PyLong_FromLongLong

Change by Mark Dickinson : -- keywords: +patch pull_requests: +28705 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30496 ___ Python tracker <https://bugs.python.org/issu

[issue46311] Clean up PyLong_FromLong and PyLong_FromLongLong

New submission from Mark Dickinson : PR GH-27832 inadvertently (I believe) introduced a couple of changes to PyLong_FromLong that didn't make a lot of sense: an (unsigned long) cast was replaced with (twodigits), and a digit count variable (counting number of PyLong digits in a C long) had

[issue46294] Integer overflow & Int values loaded into Bool detected via Libfuzzer & UndefinedBehaviorSanitizer

Mark Dickinson added the comment: Thanks for checking, Steven. Your report also helped me to notice a minor portability bug (at Objects/longobject.c:288, where the wrong type is used in a cast); a fix is in GH-30496. -- ___ Python tracker <ht

[issue45569] Drop support for 15-bit PyLong digits?

Mark Dickinson added the comment: First step in GH-30497, which changes the default to 30-bit digits unconditionally, instead of having the default be platform dependent. -- ___ Python tracker <https://bugs.python.org/issue45

[issue45569] Drop support for 15-bit PyLong digits?

Change by Mark Dickinson : -- pull_requests: +28703 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30497 ___ Python tracker <https://bugs.python.org/issu

[issue46203] Add timeout for Windows build steps

Change by Mark Dickinson : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46203> ___ ___ Pyth

[issue46294] Integer overflow & Int values loaded into Bool detected via Libfuzzer & UndefinedBehaviorSanitizer

Mark Dickinson added the comment: @swirsz: Thanks for the report. Most of these look like false positives: we're intentionally making use of C's unsigned arithmetic behaviour. Note that these are technically *not* overflows. As the C standard itself says, in C99 §6.2.5, paragraph 9

[issue46272] Fix bitwise and logical terminology in python.gram

Mark Dickinson added the comment: > In the section "Comparison operators", all mentions of "bitwise" should be > "binary". Should they? The corresponding line from https://docs.python.org/3/reference/expressions.html#comparisons is comparison

[issue46277] '''...''' error

Mark Dickinson added the comment: https://github.com/ipython/ipython/issues/12843 looks very closely related, and may be the exact same bug. -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue46

[issue46258] Minor algorithmic improvements for math.isqrt

Change by Mark Dickinson : -- keywords: +patch pull_requests: +28612 stage: commit review -> patch review pull_request: https://github.com/python/cpython/pull/30333 ___ Python tracker <https://bugs.python.org/issu

[issue46258] Minor algorithmic improvements for math.isqrt

New submission from Mark Dickinson : There are a couple of minor algorithmic improvements possible for the math.isqrt fast path (which is used for nonnegative integers smaller than 2**64). On my machine those improvements produce a little over a 10% speedup. The current algorithm for values

[issue46020] Optimize long_pow for the common case

Change by Mark Dickinson : -- nosy: +tim.peters ___ Python tracker <https://bugs.python.org/issue46020> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46199] Calculation influenced by print

Mark Dickinson added the comment: When you do: FINUB = np.empty(len(close)) FINLB = np.empty(len(close)) you're creating two *uninitialised* arrays of values. (See the NumPy documentation at https://numpy.org/doc/stable/reference/generated/numpy.empty.html.) When you then do

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: New changeset 0b58bac3e7877d722bdbd3c38913dba2cb212f13 by Mark Dickinson in branch 'main': bpo-37295: More direct computation of power-of-two factor in math.comb (GH-30313) https://github.com/python/cpython/commit/0b58bac3e7877d722bdbd3c38913dba2cb212f13

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: > Mark didn't mention his use case for rounded isqrt Mainly for emulation of floating-point sqrt. But the number of times I've needed rounded integer square root is small compared with the number of times I've needed rounded integer divis

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: A new function isqrt_rem seems like a reasonably natural addition. (Though I'd call it "isqrtrem", partly by analogy with "divmod", and partly because the math module isn't very good

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: > I'd be happy to change the implementation to use the trailing zero counts as > suggested. Done in GH-30313 (though this will conflict with Serhiy's PR). -- ___ Python tracker <https://bugs.p

[issue37295] Possible optimizations for math.comb()

Change by Mark Dickinson : -- pull_requests: +28529 pull_request: https://github.com/python/cpython/pull/30313 ___ Python tracker <https://bugs.python.org/issue37

[issue45569] Drop support for 15-bit PyLong digits?

Mark Dickinson added the comment: > I've created PR GH-30306 to find out. Results: we have two Gentoo/x86 buildbots, and a 32-bit Windows build in GitHub Actions: those machines use 15-bit digits, as a result of the logic in pyport.h that chooses 15-bit digits if SIZEOF_VOID_P

[issue45569] Drop support for 15-bit PyLong digits?

Mark Dickinson added the comment: Terry: > create a fake test file test/test_xintperf [...] Sounds reasonable, though I'm not sure I know what exact timings I'd want to try. Maybe some of the stock integer-heavy Python benchmarks (pidigits, etc.). I realised that I have no idea whether

[issue45569] Drop support for 15-bit PyLong digits?

Change by Mark Dickinson : -- keywords: +patch pull_requests: +28519 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30306 ___ Python tracker <https://bugs.python.org/issu

[issue37295] Possible optimizations for math.comb()

Change by Mark Dickinson : Added file: https://bugs.python.org/file50531/driver.py ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailin

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: Thanks Tim for spotting the stupid mistake. The reworked timings are a bit more ... plausible. tl;dr: On my machine, Raymond's suggestion gives a 2.2% speedup in the case where POPCNT is not available, and a 0.45% slowdown in the case that it _is_

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: > I'm assuming you meant to write comb(67, k) instead Aargh! That is of course what I meant, but not in fact what I timed. :-( I'll redo the timings. Please disregard the previous message. -- ___ Python trac

[issue45569] Drop support for 15-bit PyLong digits?

Mark Dickinson added the comment: I posted a request for information on usage of 15-bit digits to python-dev: https://mail.python.org/archives/list/python-...@python.org/thread/ZICIMX5VFCX4IOFH5NUPVHCUJCQ4Q7QM/ -- ___ Python tracker <ht

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: > I'd be happy to see recipes added to the docs for rounded and ceiling flavors > of isqrt, but am dubious about the value of building them in. I'd similarly prefer to see recipes in the docs. We already have such a recipe for c

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: > did you invent this? The idea is no more than: "compute an extra bit, then use that extra bit to determine which way to round". More generally, for any real number x, the nearest integer to x (rounding ties towards +infinity) is `⌊(⌊2x⌋ + 1

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: > So which of xor-popcount and add-up-up-trailing-zero-counts is faster may > well depend on platform. I ran some timings for comb(k, 67) on my macOS / Intel MacBook Pro, using timeit to time calls to a function that looked like this: def

[issue46203] Add timeout for Windows build steps

Change by Mark Dickinson : -- keywords: +patch pull_requests: +28513 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30301 ___ Python tracker <https://bugs.python.org/issu

[issue46203] Add timeout for Windows build steps

New submission from Mark Dickinson : Recently there was an upstream issue with GitHub Actions that caused the Windows build steps in build.yml to hang. No output for the step was displayed in the build logs until the entire job was eventually cancelled, after the default step timeout of 6

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: New changeset 02b5417f1107415abaf81acab7522f9aa84269ea by Mark Dickinson in branch 'main': bpo-37295: Speed up math.comb(n, k) for 0 <= k <= n <= 67 (GH-30275) https://github.com/python/cpython/commit/02b5417f1107415abaf81acab7522f9

[issue46055] Speed up binary shifting operators

Change by Mark Dickinson : -- pull_requests: +28493 pull_request: https://github.com/python/cpython/pull/30277 ___ Python tracker <https://bugs.python.org/issue46

  1   2   3   4   5   6   7   8   9   10   >