[issue23522] Misleading note in Statistics module documentation

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

[issue23522] Misleading note in Statistics module documentation

Mark Dickinson added the comment: > "The mean is strongly affected by outliers and is not necessarily a typical > example of the data points. For a more robust, although less efficient, > measure of central tendency, see median()" That wording sounds fine to me. I

[issue23522] Misleading note in Statistics module documentation

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

[issue23522] Misleading note in Statistics module documentation

Mark Dickinson added the comment: Steven: I've made a PR at https://github.com/python/cpython/pull/30174. Does this match what you had in mind? -- ___ Python tracker <https://bugs.python.org/is

[issue45995] string formatting: normalize negative zero

Change by Mark Dickinson : -- assignee: -> mark.dickinson ___ Python tracker <https://bugs.python.org/issue45995> ___ ___ Python-bugs-list mailing list Un

[issue45995] string formatting: normalize negative zero

Mark Dickinson added the comment: Thanks, John. I should have time to review within the next week or so. -- ___ Python tracker <https://bugs.python.org/issue45

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: > we can get faster code by using a small (3Kb) table of factorial logarithms The problem here is that C gives no guarantees about accuracy of either log2 or exp2, so we'd be playing a guessing game about how far we can go before the calculation

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: One approach that avoids the use of floating-point arithmetic is to precompute the odd part of the factorial of n modulo 2**64, for all small n. If we also precompute the inverses, then three lookups and two 64x64->64 unsigned integer multiplications g

[issue46144] math.log() returns improper output

Mark Dickinson added the comment: Yes, confirmed that this is not a bug, but just one of the many consequences of approximating real numbers by floating-point numbers. You may be interested in math.log2 and/or int.bit_length. math.log2(x) *may* give you more accurate results than math.log

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: That computation of the shift can be simplified to require only one popcount operation. With F and Finv as before: def comb_small(n, k): assert 0 <= k <= n <= Nmax return (F[n] * Finv[k] * Finv[n-k] % 2**64) << (k ^ n ^ (

[issue23522] Misleading note in Statistics module documentation

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

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: [Tim] > The justification for the shift count isn't self-evident, and > appears to me to be an instance of the generalization of Kummer's > theorem to multinomial coefficients. Not sure there's any generalisation here: I think it *is

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

Mark Dickinson added the comment: > This should probably be a separate issue, Specifically, issue 45569. -- ___ Python tracker <https://bugs.python.org/issu

[issue20369] concurrent.futures.wait() blocks forever when given duplicate Futures

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

[issue46055] Speed up binary shifting operators

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

[issue46055] Speed up binary shifting operators

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

[issue37295] Possible optimizations for math.comb()

Mark Dickinson added the comment: Raymond: how do you want to proceed on this? Should I code up my suggestion in a PR, or are you already working on it? -- ___ Python tracker <https://bugs.python.org/issue37

[issue46173] float(x) with large x not raise OverflowError

Mark Dickinson added the comment: Yes, exactly: Python's intentionally following the normal IEEE 754 rules for rounding a value to the binary64 format using the round-ties-to-even rounding rule, as formalised in section 7.4 of IEEE 754-2019 (and quoted by @cykerway). These are the

[issue46173] float(x) with large x not raise OverflowError

Mark Dickinson added the comment: If we wanted to make a change, I think the part of the docs that I'd target would be this sentence: > a floating point number with the same value (within Python’s floating point > precision) is returned It's that "same value (within Py

[issue46173] float(x) with large x not raise OverflowError

Change by Mark Dickinson : -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue46173> ___ ___ Python-bugs-list mailing list Un

[issue46173] Clarify conditions under which float(x) with large x raises OverflowError

Mark Dickinson added the comment: Changing to a documentation issue. -- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python resolution: not a bug -> title: float(x) with large x not raise OverflowError -> Clarify conditions under whic

[issue37295] Possible optimizations for math.comb()

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

[issue46055] Speed up binary shifting operators

Mark Dickinson added the comment: New changeset 360fedc2d2ce6ccb0dab554ef45fe83f7aea1862 by Mark Dickinson in branch 'main': bpo-46055: Streamline inner loop for right shifts (#30243) https://github.com/python/cpython/commit/360fedc2d2ce6ccb0dab554ef45fe8

[issue46055] Speed up binary shifting operators

Mark Dickinson added the comment: New changeset 3581c7abbe15bad6ae08fc38887e5948f8f39e08 by Xinhang Xu in branch 'main': bpo-46055: Speed up binary shifting operators (GH-30044) https://github.com/python/cpython/commit/3581c7abbe15bad6ae08fc38887e59

[issue46055] Speed up binary shifting operators

Mark Dickinson added the comment: Two separate significant improvements have been pushed: thanks, Xinhang Xu! The original PR also contained a reworking of the general case for right-shifting a negative integer. The current code (in main) for that case does involve some extra allocations

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

Mark Dickinson added the comment: FWIW, when this need has turned up for me (which it has, a couple of times), I've used this: def risqrt(n): return (isqrt(n<<2) + 1) >> 1 But I'll admit that that's a bit non-obvious. -- ___

[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

[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/02b5417f1107415abaf81

[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

[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

[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 f(comb):

[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

[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 rec

[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

[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. -- ___ P

[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

[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

[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

[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 ide

[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_VO

[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

[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 <http

[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

[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 rounde

[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/0b58bac3e7877d722bdbd3c38913db

[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 th

[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:

[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

[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

[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

[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

[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, paragra

[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

[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

[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

[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

[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

[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

[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

[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://bu

[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

[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 us

[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();

[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

[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

[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/025cbe7a9b5d3058ce2eb8015d3650

[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/d02c5e9b55a8651b7d396ac3f2bded

[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

[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

[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. --

[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:

[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/5cd9a162cd02a3d0f1b0

[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

[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:

[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.

[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.p

[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 while t

[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

[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/83a0ef2162aa379071e243f1b696aa

[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/c7f20f1cc8c20654e5d53955260436

[issue46406] optimize int division

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

[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:

[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

[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

[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 bra

[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

[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,

[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 co

[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

[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.

[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-proto

[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 root *

[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

[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 flo

[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 ne

[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

[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

[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

[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

[issue46694] isdigit/isnumeric vs int()

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

  1   2   3   4   5   6   7   8   9   10   >