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.
--
___
Py
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
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/3581c7abbe15bad6ae08fc38887e5948f8f39e08
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/360fedc2d2ce6ccb0dab554ef45fe83f7aea1862
Change by Mark Dickinson :
--
pull_requests: +28490
pull_request: https://github.com/python/cpython/pull/30275
___
Python tracker
<https://bugs.python.org/issue37
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
Change by Mark Dickinson :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue46173>
___
___
Python-bugs-list mailing list
Un
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 Python's flo
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 exact
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
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
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue46055>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Dickinson :
--
nosy: -mark.dickinson
___
Python tracker
<https://bugs.python.org/issue20369>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> This should probably be a separate issue,
Specifically, issue 45569.
--
___
Python tracker
<https://bugs.python.org/issu
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* just Kummer's
Change by Mark Dickinson :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue23522>
___
___
Pyth
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 ^ (
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
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
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 beco
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
Change by Mark Dickinson :
--
assignee: -> mark.dickinson
___
Python tracker
<https://bugs.python.org/issue45995>
___
___
Python-bugs-list mailing list
Un
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/issue23
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
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
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue23522>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> Lines 500-504 are the ones that trigger it.
Ah, right. Thanks.
> Apparently there are no tests in that file for straight exp()
Yes - that file was mostly written to give good coverage for places where we'd
written our own implementations rathe
Mark Dickinson added the comment:
> I've also got no idea how to write a test for this
Yep, that's fine. All I want is that at least one particular value that caused
the spurious OverflowError is in the test suite somewhere, but it sounds as
though that's already the case. I'd imag
Mark Dickinson added the comment:
For the record, #37999 is the issue that turned the deprecation warnings into
errors for Python 3.10. (But as Serhiy says, please open a new issue, or start
a discussion on one of the mailing lists
Mark Dickinson added the comment:
@arhadthedev: Thanks for highlighting the issue.
> we need to check if the problem really has place and the PR needs to be
> retracted until PyQt5 is ported to newer Python C API
I'm not particularly impressed by the arguments from cc
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue46020>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
I presume this is also worth an upstream report? Setting ERANGE on a result
that's close to -1.0 is rather questionable.
--
___
Python tracker
<https://bugs.python.org/issue46
Mark Dickinson added the comment:
It's a bit cheap and nasty, but I think we could simply replace the line:
if (fabs(x) < 1.0)
in is_error with
if (fabs(x) < 2.0)
perhaps with an explanatory comment. All we need to do is distinguish underflow
from overflow, and 2.0 is
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue46018>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
I'd support having this functionality available for `format` and for f-strings.
(As Steven says, changing %-formatting doesn't seem viable.) It really _is_
awkward to do this in any other way, and I'm reliably informed that normal
people don't expect to see
Change by Mark Dickinson :
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue45995>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue7946>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Dickinson :
--
nosy: -mark.dickinson
___
Python tracker
<https://bugs.python.org/issue45476>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
[Tim]
> on Windows, exp2(x) is way worse then pow(2, x)
Darn.
> I expect we should just live with it.
Agreed.
--
___
Python tracker
<https://bugs.python.org/i
Mark Dickinson added the comment:
All done. Many thanks, Gideon!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
New changeset 6266e4af873a27c9d352115f2f7a1ad0885fc031 by Gideon in branch
'main':
bpo-45917: Add math.exp2() method - return 2 raised to the power of x (GH-29829)
https://github.com/python/cpython/commit/6266e4af873a27c9d352115f2f7a1ad0885fc031
Mark Dickinson added the comment:
On the subject of accuracy, there doesn't seem to be much in it on my mac
laptop, and it looks as though pow(2.0, x) is giving correctly rounded results
as often as (if not more often than) exp2(x).
Here's the log of a terminal session, after recompiling
Mark Dickinson added the comment:
See also previous discussion towards the end of
https://bugs.python.org/issue3366.
FWIW, I don't think there's value in adding exp2 to the cmath module too: we'd
have to write our own implementation, and it's just not a function that appears
often
Mark Dickinson added the comment:
Sounds good to me, provided that all the common platforms that we care about
have a reasonable quality implementation. This should be a straightforward
wrapping of the C99 function, and with sufficient tests the buildbots should
tell us if there are any
Mark Dickinson added the comment:
I could be persuaded for any of options -1, 1 and 2. I don't much like option 0.
--
___
Python tracker
<https://bugs.python.org/issue45
Mark Dickinson added the comment:
Eric, Serhiy: do you have opinions on the right way forward?
Here are 6 options, on a spectrum of increasing level of acceptance of "N".
-2. Remove "N" support for cdecimal right now (i.e., for Python 3.11), on the
basis that there's no
Mark Dickinson added the comment:
Concrete example of int/int not being correctly rounded on systems using x87
instructions: on those systems, I'd expect to see 1/2731 return a result of
0.00036616623947272064 (0x1.7ff4005ffd002p-12), as a result of first rounding
to 64-bit precision
Mark Dickinson added the comment:
> All the rounding has already happened at the point where ldexp is called, and
> the result of the ldexp call is exact.
Sketch of proof:
[Here](https://github.com/python/cpython/blob/4ebde73b8e416eeb1fd5d2ca3283f7ddb534c5b1/Objects/longobject.c#L392
Mark Dickinson added the comment:
> Will it suffer the same issues with subnormals on Windows?
No, it should be fine. All the rounding has already happened at the point where
ldexp is called, and the result of the ldexp call is exact.
> Is CPython int/int true division guar
Mark Dickinson added the comment:
Since I've failed to find a coherent statement and proof of the general
principle I articulated anywhere online, I've included one below. (To be
absolutely clear, the principle is not new - it's very well known, but oddly
hard to find written down anywhere
Mark Dickinson added the comment:
[Raymond]
> [...] perhaps do an int/int division to match the other code path [...]
Sure, works for me.
--
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
> If there are enough use cases for it.
Well, that's the question. :-) *I* can't think of any good use cases, but maybe
others can. But if we can't come up with some use cases, then this feels like a
solution looking for a problem, and that makes it h
Mark Dickinson added the comment:
(Changing the issue type: as I understand it, this is a proposal for a new
feature, namely new methods bytes.sort and bytearray.sort, rather than a
performance improvement to an existing feature.)
--
type: performance -> enhancem
Mark Dickinson added the comment:
Can you give example use-cases for sorting a bytes or bytearray object? I see
value in the intermediate object - the frequency table, but the reconstructed
sorted bytes object just seems like an inefficient representation of the
frequency table, and I'm
Mark Dickinson added the comment:
Related:
https://stackoverflow.com/questions/32150888/should-ldexp-round-correctly
--
___
Python tracker
<https://bugs.python.org/issue45
Mark Dickinson added the comment:
There's also a potential double-rounding issue with ldexp, when the first
argument is an int: ldexp(n, e) will first round n to a float, and then (again
for results in the subnormal range) potentially also need to round the result.
>>> n = 2**53
Mark Dickinson added the comment:
This is expected behaviour. See the docs here:
https://docs.python.org/3.9/reference/executionmodel.html#resolution-of-names
> The scope of names defined in a class block is limited to the class block; it
> does not extend to the code blocks of m
Mark Dickinson added the comment:
Here's a reference for this use of round-to-odd:
https://www.lri.fr/~melquion/doc/05-imacs17_1-expose.pdf
I'm happy to provide any proofs that anyone feels are needed.
--
___
Python tracker
<ht
Mark Dickinson added the comment:
Just for fun: I gave a somewhat ranty 10-minute talk on this topic at a
(virtual) conference a few months ago:
https://www.youtube.com/watch?v=01oeosRVwgY
--
___
Python tracker
<https://bugs.python.
Mark Dickinson added the comment:
@cwg: Yep, we're aware of this. There are no good solutions here - only a mass
of constraints, compromises and trade-offs. I think we're already somewhere on
the Pareto boundary of the "best we can do" given the constraints. Moving to
ano
Mark Dickinson added the comment:
> am still studying the new one
Sorry - I should have added at least _some_ comments to it.
Here's the underlying principle, which I think of as "The magic of
round-to-odd":
Suppose x is a positive real number and e is an integer satisf
Mark Dickinson added the comment:
Hmm. isqrt_frac_rto is unnecessarily complicated. Here's a more streamlined
version of the code.
import math
def isqrt_frac_rto(n, m):
"""
Square root of n/m, rounded to the nearest integer using round-to-odd.
"""
Mark Dickinson added the comment:
> Should the last line of sqrt_frac() be wrapped with float()?
It's already a float - it's the result of an int / int division.
--
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
Here's the float-and-Fraction-based code that I'm using to compare the
integer-based code against:
def sqrt_frac2(n, m):
"""
Square root of n/m as a float, correctly rounded.
"""
f = fractions.Fraction(n, m)
Mark Dickinson added the comment:
> Does the technique you had in mind involve testing 1 ulp up or down to see
> whether its square is closer to the input?
Kinda sorta. Below is some code: it's essentially just pure integer operations,
with a last minute conversion to float (im
Mark Dickinson added the comment:
> we've run the ball almost the full length of the field and then failed to put
> the ball over the goal line
But if we only go from "faithfully rounded" to "almost always correctly
rounded", it seems to me that we're still a coupl
Mark Dickinson added the comment:
One thought: would the deci_sqrt approach help with value ranges where the
values are well within float limits, but the squares of the values are not?
E.g., on my machine, I currently get errors for both of the following:
>>> xs = [random.normalva
Mark Dickinson added the comment:
I'm not sure this is worth worrying about. We already have a very tight error
bound on the result: if `x` is a (positive) fraction and `y` is the closest
float to x, (and assuming IEEE 754 binary64, round-ties-to-even, no overflow or
underflow, etc
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue45876>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue32582>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
True: there's another detail here that's needed to explain the behaviour. The
first "for" clause in a list comprehension is special: it's evaluated in the
enclosing scope, rather than in the local function scope that the list
comprehension cr
Mark Dickinson added the comment:
See also #41216
--
___
Python tracker
<https://bugs.python.org/issue45862>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Thanks for the report. The behaviour is by design: see #5242 (especially
msg81898) for an explanation.
Closing this issue as a duplicate of #5242.
--
nosy: +mark.dickinson
resolution: -> duplicate
stage: -> resolved
status: open -&g
Change by Mark Dickinson :
--
title: SAP HANA Training in Chennai -> spam
___
Python tracker
<https://bugs.python.org/issue45784>
___
___
Python-bugs-list mai
Change by Mark Dickinson :
--
Removed message: https://bugs.python.org/msg406152
___
Python tracker
<https://bugs.python.org/issue45784>
___
___
Python-bug
Mark Dickinson added the comment:
On Mac, collections.abc is imported at startup time via site.py (which imports
rlcompleter, which imports inspect, which imports collections.abc). I'd guess
it's the same on Linux.
mdickinson@mirzakhani cpython % ./python.exe
Python 3.11.0a2+ (heads/main
Mark Dickinson added the comment:
Sorry Rahul: I'm not the right person to help you push this forward.
I'm sympathetic to the problem: I've encountered similar issues in "Real Code",
where we needed to associate log outputs generated by worker pool threads with
the ac
Mark Dickinson added the comment:
> previously one could write .submit(function_name, *args, **kwargs)
> but now one should write
> .submit(function_name, name_of_thread, *args, **kwargs)
> name_of_thread can be None
This approach can't work, I'm afraid: it would be a backwards-
Mark Dickinson added the comment:
Interesting. I think the behaviour of the Python implementation behaviour is
actually more correct here: neither `int` nor `float` supports 'N', and I'm not
seeing any indication in tests or documentation that 'N' should be supported.
So is this a bug
Mark Dickinson added the comment:
Christian Heimes pointed out in the PR discussion that we can't simply modify
libmpdec, since some vendors unbundle the mpdecimal library.
So some options are:
0. Do nothing.
1. Request that this feature to be added upstream, so that it eventually makes
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +27693
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29439
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
> It looks like quite similar changes have already been made:
Yes, I think this isn't something that needs to be resolved for this issue, but
it is something we need to think about. (Though perhaps the resolution is just
"Don't worry about it until
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +27692
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29438
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
Serhiy: this is not a duplicate of #43624. That issue is about underscores in
the *fractional* part of a (float / complex / Decimal) number, and the changes
to the formatting mini-language syntax that would be necessary to support that.
This issue is simply
Change by Mark Dickinson :
--
nosy: -mark.dickinson
___
Python tracker
<https://bugs.python.org/issue45708>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> whether Decimal should extend beyond the specification in this case
We already go way beyond the original specification for string formatting. The
spec doesn't go further than specifying to-scientific-string and
to-engineering-string, neither of wh
Mark Dickinson added the comment:
I think the two main reasons that applied to not implementing the parsing part
of PEP 515 for the Decimal type (speed, compliance with the IBM specification)
don't apply to the formatting side.
We do need to think about the implications of making local
Change by Mark Dickinson :
--
nosy: +eric.smith, mark.dickinson
___
Python tracker
<https://bugs.python.org/issue45708>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
I'm not sure I understand the problem that you're reporting - what issues are
you seeing in practice?
x64 should be fine here. In normal circumstances, the compiled version of
dtoa.c will be using SSE2 instructions and will already be doing floating-point
Mark Dickinson added the comment:
I don't think this is a bug: there's still a reference to the `A` instance in
`sys.exc_info()` (specifically, in the exception traceback) in this case, so
that instance is still alive.
If you add an `except: pass` clause to your `try / finally`, you should
New submission from Mark Dickinson :
Looking at issue #35037 (which is a compatibility issue having to do with
PYLONG_BITS_IN_DIGIT), I'm wondering whether it would make sense to drop
support for 15-bit PyLong digits altogether. This would simplify some of the
code, eliminate a configuration
Mark Dickinson added the comment:
This should probably be a separate issue, but I wonder whether the 15-bit digit
option has value any more. Should we just drop that option and always use
30-bit digits?
30-bit digits were introduced at a time when we couldn't rely on a 64-bit
integer type
Mark Dickinson added the comment:
See also discussion in #44970, which is closed as a duplicate of this issue.
--
___
Python tracker
<https://bugs.python.org/issue15
Mark Dickinson added the comment:
> Is not it a duplicate of issue15996?
Yes, I think it's close enough. Thanks.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> pow() for complex numbers is rough a
Mark Dickinson added the comment:
> Closing this as out of date.
SGTM. Thanks.
--
___
Python tracker
<https://bugs.python.org/issue25934>
___
___
Python-
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue45476>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
+1 for the removals. (We should fix #44970 too, but as you say that's a
separate issue. And I suspect that the Py_ADJUST_ERANGE1() use for float pow
should be replaced, too.)
--
___
Python tracker
<ht
Mark Dickinson added the comment:
Larry: the first line was introduced in #20189. Does it still make sense to
keep it at this point?
--
nosy: +larry
___
Python tracker
<https://bugs.python.org/issue45
New submission from Mark Dickinson :
The docstring of the "type" builtin is mildly confusing. Here's what the first
few lines of the output for `help(type)` look like for me (on Python 3.10.0rc2):
class type(object)
| type(object_or_name, bases, dict)
| type(object) -> the
Mark Dickinson added the comment:
Did you by any chance get an error message resembling the following?
> "Cannot cast ufunc 'add' output from dtype('float64') to dtype('int64') with
> casting rule 'same_kind'"
(If you can give us a complete piece of code that we c
101 - 200 of 6765 matches
Mail list logo
