Mark Dickinson added the comment:
@Vedran:
> I have tons of these ideas, but usually am afraid of voicing them ...
Always good to have ideas brought up, so long as there's no expectation that
every idea gets implemented. :-) But I think rounding a string is probably
another one
Mark Dickinson added the comment:
> I don't think that this will be a very difficult feature to implement.
Agreed that it shouldn't be hard to implement, if we do the obvious thing
(rounding the exact value that the float represents, rather than trying to do
some sort of D
Change by Mark Dickinson :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41610>
___
___
Python-bugs-list mailing list
Unsubscrib
Mark Dickinson added the comment:
Fine by me in principle; I haven't had a chance to look at the code yet.
While we're doing this, any chance we could special-case the two-argument hypot
to use the libm hypot directly? On many platforms the libm hypot will be
correctly rounded, o
Mark Dickinson added the comment:
Whoops. There's a missing `count += 1` in there, of course.
--
___
Python tracker
<https://bugs.python.org/issue41458>
___
___
Mark Dickinson added the comment:
Here's code to illustrate the idea. It doesn't yet handle zeros, infinities or
nans; that support would need to be added.
import math
def fprod(numbers):
# Product of numbers, avoiding intermediate underflow and overflow.
# Does not ha
Mark Dickinson added the comment:
If we want to do this (and I'm still not convinced that we do), I think there's
a simpler way: use `frexp` to decompose each float into a fraction and an
exponent, multiply the fractions (which barring zeros will all be in [0.5,
1.0)), and keep tr
Change by Mark Dickinson :
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue41487>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
[META] @Eric: No apology needed. I find the issue tracker search hard to use
well, and in general we don't do a great job of tracking duplicates properly.
I'm trying to be better about that.
--
___
Pyth
Mark Dickinson added the comment:
I'd be opposed to changing Python's `int` implementation in this way: it adds
complication to the codebase and potentially also slows down "normal" cases. If
a user knows in advance (a) that they're using a divisor that's highl
Mark Dickinson added the comment:
Updating resolution to "duplicate", in an effort to keep discussion in a single
place.
--
resolution: not a bug -> duplicate
superseder: -> Complex number representation round-trip doesn't work wit
Mark Dickinson added the comment:
Also related: #40269
--
___
Python tracker
<https://bugs.python.org/issue17336>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
The issue of changing the complex repr came up again in #41485, which has been
closed as a duplicate of this issue.
See also https://bugs.python.org/issue23229#msg233963, where Guido says:
> BTW I don't want repr() of a complex number to use the
Mark Dickinson added the comment:
Closing here; to the extent that it's possible, let's keep the discussion in
one place (comments can still be posted on closed issues). I'll add a comment
on #17336.
--
resolution: -> duplicate
stage: -> resolved
status: open
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue41485>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
This message from Tim, starting "I'd like to divorce `prod()` from
floating-point complications", seems relevant here:
https://bugs.python.org/issue35606#msg333090
--
___
Python tracker
<https
Mark Dickinson added the comment:
Another python-ideas thread, from 2016:
https://mail.python.org/archives/list/python-id...@python.org/thread/EHZAXE4P2VOT3CE4H6SNDPDASW7H2CGS/
--
___
Python tracker
<https://bugs.python.org/issue36
Change by Mark Dickinson :
--
resolution: rejected -> duplicate
superseder: -> Add clamp() function to builtins
___
Python tracker
<https://bugs.python.org/i
Mark Dickinson added the comment:
#41408 was closed as a duplicate of this issue
See also the recent discussion on python-ideas at
https://mail.python.org/archives/list/python-id...@python.org/thread/KWAOQFSV3YJYQV2Y5JXGXFCXHJ3WFLRS/#KWAOQFSV3YJYQV2Y5JXGXFCXHJ3WFLRS
That discussion has
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue41342>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Setting to pending; I don't see any bug here, and I suspect the original report
was based on a misunderstanding of what sys.setrecursionlimit is for.
--
resolution: -> not a bug
status: open -> pending
___
Mark Dickinson added the comment:
Is there a description of the algorithms or ideas used anywhere? The blog post
you link to has no details, and I don't see any useful descriptions in the
GitHub README or the source; trawling through the source to figure out what the
key ideas are i
Mark Dickinson added the comment:
The recursion depth and recursion limit are stored internally as C ints, so
yes, 2**31 - 1 = 2147483647 is the maximum value that you can pass to
`sys.setrecursionlimit` that won't fail immediately.
But it's unclear why you'd ever want to se
Mark Dickinson added the comment:
Thanks for the report. This isn't a Python bug, but a common issue when working
with floating-point numbers.
I recommend taking a look at this section of the tutorial for more information:
https://docs.python.org/3.8/tutorial/floatingpoint
Mark Dickinson added the comment:
> [...] see the change of sign in the real part below [...]
Grr. Stupid fingers. That should say "imaginary part", not "real part"
--
___
Python tracker
<https://
Mark Dickinson added the comment:
Yes, that looks like the right part of the sqrt code.
For the acos docstring, "continuous from below" implies that for any complex
number z that lies exactly _on_ the branch cut, acos(z) is close to acos(w) for
a nearby value w just _below_ the
Change by Mark Dickinson :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 3.10, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
> the sign of x is used [...]
Correction: That should say "the sign of the imaginary part of x is used [...]"
--
___
Python tracker
<https://bugs.pytho
New submission from Mark Dickinson :
The documentation for the cmath module is misleading on the behaviour near
branch cuts. For example, the documentation for cmath.acos says:
Return the arc cosine of x. There are two branch cuts: One
extends right from 1 along the real axis to
Mark Dickinson added the comment:
@JD-Veiga: would you be willing to work on a PR?
--
___
Python tracker
<https://bugs.python.org/issue41205>
___
___
Python-bug
Mark Dickinson added the comment:
I agree that the result is surprising and should be noted in the docs; we
shouldn't expect all the decimal users to be familiar with the specification.
Some of the other differences with float arithmetic *are* noted (e.g., the
behaviour of `//
Mark Dickinson added the comment:
Just for fun, I posted a Stack Overflow question:
https://stackoverflow.com/q/62721186/270986
Let's close this here.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Mark Dickinson added the comment:
One note: in the original post, not only are the values being tested coming
from NumPy's arange, but round(x[i],1) is testing *NumPy's* rounding
functionality, not Python's. x[i] has type np.float64, and while np.float64
does inherit from Pyt
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue41100>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
The text "TEST CHANGE TO BE UNDONE" is currently visible here:
https://docs.python.org/3/whatsnew/3.0.html
It was introduced in commit 343bc06d8047e4a2e675394528dbb5155be1b3b5.
Should this test change have been undone?
--
nosy: +mark
Mark Dickinson added the comment:
> a bit off-topic for this issue
Apologies: on reflection, it's way off-topic. Please ignore this and the last
message; I'll find a more appropriate place to take this up.
--
___
Python tr
Mark Dickinson added the comment:
@Ronald: a bit off-topic for this issue, but do you know if there are or will
be any publicly available developer resources for people moving to Apple
Silicon? For obvious reasons, I'm interested in what the floating-point and
libm situation is goi
Mark Dickinson added the comment:
This isn't a bug in Python; it's a consequence of the
what-you-see-is-not-what-you-get nature of binary floating-point.
The behaviour is explained in the tutorial, here:
https://docs.python.org/3/tutorial/floatingpoint.html
--
nosy: +mark
Mark Dickinson added the comment:
I think #39277 is related.
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue40999>
___
___
Python-bug
Mark Dickinson added the comment:
A couple of other data points:
- Swift has nonzeroBitCount:
https://developer.apple.com/documentation/swift/int/2886050-nonzerobitcount
- Rust has count_ones: https://doc.rust-lang.org/std/primitive.u64.html
- Go's math/bits package has OnesCount
Mark Dickinson added the comment:
> Why are calling a population count method "bit_count()"?
Naming things is hard, but I don't think this is an unreasonable name, and it's
not without precedent. Java similarly has Integer.bitCount and
BigInteger.bitCou
Mark Dickinson added the comment:
New changeset 8bd216dfede9cb2d5bedb67f20a30c99844dbfb8 by Niklas Fiekas in
branch 'master':
bpo-29882: Add an efficient popcount method for integers (#771)
https://github.com/python/cpython/commit/8bd216dfede9cb2d5bedb67f20a30c
Change by Mark Dickinson :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.7
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
Fixed in master and 3.9; not backporting to 3.8 or 3.7, as discussed.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
New changeset ad088ca5c6adc4a107411cad62b83f5c6e06b5ed by Miss Islington (bot)
in branch '3.9':
bpo-40780: Fix failure of _Py_dg_dtoa to remove trailing zeros (GH-20435)
(GH-20514)
https://github.com/python/cpyt
Mark Dickinson added the comment:
New changeset 895c9c1d438367722f74f437fda96767d770662b by Mark Dickinson in
branch 'master':
bpo-40780: Fix failure of _Py_dg_dtoa to remove trailing zeros (GH-20435)
https://github.com/python/cpython/commit/895c9c1d438367722f74f437fda967
Mark Dickinson added the comment:
> FYI, printing this 60 Million digit number took about 12 hours on my i7.
That sounds about right: on my machine, it takes around 10 seconds to convert a
1 million-digit number to a string. Multiplying by 60**2 gives 10 hours.
I do have to wonder w
Mark Dickinson added the comment:
I started a python-ideas thread:
https://mail.python.org/archives/list/python-id...@python.org/thread/3YGNHGWZOU5AIBS3A52CAHPJJLY7J2CS/
--
___
Python tracker
<https://bugs.python.org/issue40
Mark Dickinson added the comment:
> Converting Decimal, Fraction, float128 to float before using it in expression
> can lead to loss of precision.
My experience is that this loss of precision is hardly ever a practical problem
in the real world of scientific development; in pr
Mark Dickinson added the comment:
> So such conversion looks to me less useful than operator.index().
That may be true, but it's still useful, and currently very hard to write
without core Python support. The problem is that duck-typing for something
float-like is easy and widesprea
Mark Dickinson added the comment:
On naming, maybe float.from_number or float.from_numeric?
--
___
Python tracker
<https://bugs.python.org/issue40801>
___
___
Mark Dickinson added the comment:
> `operator` seems a slightly odd place for this.
Yes, it's not ideal. It's by analogy with operator.index, which provides the
equivalent duck-typing for integers, and calls __index__. Similarly,
operator.as_float is primarily there to c
Mark Dickinson added the comment:
> The other way to solve my problem would be to provide an operator module
> function (operator.as_float?) that does a duck-typed conversion of an
> arbitrary Python object to a float.
This does feel like the *right* solution to me. See #4080
Mark Dickinson added the comment:
Proof of concept in GH-20481
--
___
Python tracker
<https://bugs.python.org/issue40801>
___
___
Python-bugs-list mailin
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +19730
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20481
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Dickinson :
Motivation
--
Various pieces of Python need to do a duck-typed conversion of an arbitrary
float-like object to a float (or a C double) for computation. The math module
is the most obvious example - most math-module functions that accept a float
Change by Mark Dickinson :
--
title: Expose PyFloat_ToDouble at Python level: operator.to_float? -> Expose
PyFloat_ToDouble at Python level: operator.as_float?
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
[Serhiy]
> * Undeprecate accepting __index__ and __int__ returning instances of int
> sublasses. There is no difference from the side of using int and index(), but
> it can simplify user implementations of __index__ and __int__.
I'm not s
Change by Mark Dickinson :
--
versions: -Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue40780>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
New changeset 20941de0ddc39ce9f07e29b4cc770e8a9ef14d41 by Mark Dickinson in
branch 'master':
bpo-37999: Fix outdated __int__ and nb_int references in comments (GH-20449)
https://github.com/python/cpython/commit/20941de0ddc39ce9f07e29b4cc770e
Mark Dickinson added the comment:
The behaviour change for range sounds reasonable to me.
Just to make sure I understand the impact of the change:
- For Python < 3.10, we sometimes convert the range inputs to Python ints, and
sometimes don't. For example, a start value of `np
Mark Dickinson added the comment:
Right; the naive algorithm for converting the internal binary representation to
the decimal representation is quadratic time. In *theory* we could implement a
subquadratic time algorithm, but the complexity of such an implementation
outweighs the benefits
Change by Mark Dickinson :
--
pull_requests: +19703
pull_request: https://github.com/python/cpython/pull/20449
___
Python tracker
<https://bugs.python.org/issue37
Mark Dickinson added the comment:
There are some comments in the Objects/longobject.c code that still refer to
__int__, and could use an update.
For example:
https://github.com/python/cpython/blob/7da46b676aed7111de34b57c8b942a7f3bb80327/Objects/longobject.c#L366
--
nosy
Mark Dickinson added the comment:
I'm wondering how far back the fix should be backported. Clearly it should go
into the 3.9 branch as well as master, but it feels like the sort of fix where
the behaviour change resulting from the fix is as likely to break code as the
bug i
Mark Dickinson added the comment:
The PR is ready for review.
--
___
Python tracker
<https://bugs.python.org/issue40780>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Created a PR with a tentative fix. It still needs regression tests; working on
those.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +19692
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20435
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
This appears to go all the way down to _Py_dg_dtoa, which in mode 3 is supposed
to suppress trailing zeros.
I'll dig in and see if I can find a fix. (Assigning to me so that I don't
forget it, but I also don't want to block anyone else -
Mark Dickinson added the comment:
Very interesting. Agreed that this looks like a bug. It affects old-style
formatting, too:
>>> "%.3g" % 1503
'1.5e+03'
>>> "%.3g" % 1504
'1.5e+03'
>>> "%.3g" % 1505
Mark Dickinson added the comment:
PR is updated and mergeable.
--
___
Python tracker
<https://bugs.python.org/issue29882>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Thanks Zackery for the fix! Nick: is this good enough to close, or would you
like to see something more here?
--
___
Python tracker
<https://bugs.python.org/issue39
Mark Dickinson added the comment:
New changeset c2a177adf3575d4eb81030fba851f78d7a8e3f51 by Miss Islington (bot)
in branch '3.8':
bpo-39301: State that floor division is used for right shift operations
(GH-20347) (GH-20415)
https://github.com/python/cpyt
Mark Dickinson added the comment:
New changeset b068d892c1ba7b996e43aceb974bfadac3c577ed by Miss Islington (bot)
in branch '3.7':
bpo-39301: State that floor division is used for right shift operations
(GH-20347) (GH-20416)
https://github.com/python/cpyt
Mark Dickinson added the comment:
New changeset cc0f50d62c75a1d171f5de9b56caef64e79eb013 by Miss Islington (bot)
in branch '3.9':
bpo-39301: State that floor division is used for right shift operations
(GH-20347) (GH-20414)
https://github.com/python/cpyt
Mark Dickinson added the comment:
New changeset af7553ac95a96713be847dd45bc5a8aeb0a75955 by Zackery Spytz in
branch 'master':
bpo-39301: State that floor division is used for right shift operations
(GH-20347)
https://github.com/python/cpython/commit/af7553ac95a96713be847dd45bc5a8
Mark Dickinson added the comment:
> For example, should numpy.int64 get this method as well?
That's for the NumPy folks to decide (and I've added Nathaniel Smith to the
nosy in case he wants to comment), but I don't see any particularly strong
reason that NumPy would
Mark Dickinson added the comment:
I'm re-reviewing this discussion three years on. I'd be happy for this to go
into 3.10. Are there other strong opinions? It would be good to either update
and merge the PR, or close as rejected.
--
Change by Mark Dickinson :
--
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue39301>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
[Rémi Lapeyre]
> In the end, if some core devs think that putting together the various
> discussions for an imath module in a coherent PEP [...]
I can't answer for other core devs. My *guess* is that there's a reasonable
chance that a well
Mark Dickinson added the comment:
PR applied. Thank you!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
> I confess that I've no idea what the "without overflow check" bit means
After some digging, it is indeed to do with the int/long unification:
- In Python 2.1, arithmetic operations on ints would raise OverflowError on
overflow.
- Exce
Mark Dickinson added the comment:
New changeset fdc5a94279736a7715dd35c5354a3c27098d0897 by Zackery Spytz in
branch 'master':
bpo-37973: Improve the docstrings of sys.float_info (GH-19218)
https://github.com/python/cpython/commit/fdc5a94279736a7715dd35c5354a3c
Mark Dickinson added the comment:
It seems we don't have a champion (someone willing to write a PEP) for this
issue. I'm going to close.
And if or when we do have such a champion, it probably makes more sense to
re-open #37132, which is specifically about adding `imath`, or
Change by Mark Dickinson :
--
versions: +Python 3.10 -Python 3.9
___
Python tracker
<https://bugs.python.org/issue40028>
___
___
Python-bugs-list mailin
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue40257>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Agreed; closing.
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
> We could add an option to cause NaNs to raise an error, but I don't think it
> would get used.
If that option were extended to also cause infinities to raise an error, then
I'd use it. We have code that's producing JSON without knowin
Mark Dickinson added the comment:
... but I'm an idiot, since that option is already there (allow_nan=False), and
I've just checked that we are in fact using it.
--
___
Python tracker
<https://bugs.python.o
Change by Mark Dickinson :
--
nosy: -mark.dickinson
___
Python tracker
<https://bugs.python.org/issue40455>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Related (imath module discussions): #37132, #40028.
--
___
Python tracker
<https://bugs.python.org/issue39657>
___
___
Pytho
Change by Mark Dickinson :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
`pair` isn't a reserved word here; it's just the formal parameter name. Think
of the lambda here as being equivalent to a function
def second(pair):
return pair[1]
You can replace the word "pair" here with any other valid Pyt
Mark Dickinson added the comment:
I don't think "null" in JSON is supposed to represent "Not a Number"; it's
closer in meaning to Python's `None`. I definitely wouldn't want to see nans
translated to "null" by default.
This also only seems t
Mark Dickinson added the comment:
@Rémi Lapeyre (since you requested re-opening of the issue :-)
Are you interested in putting together a PEP for this?
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Mark Dickinson :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue37986>
___
___
Mark Dickinson added the comment:
New changeset 86a93fddf72a2711aca99afa0c5374c8d6b4a321 by Sergey Fedoseev in
branch 'master':
bpo-37986: Improve perfomance of PyLong_FromDouble() (GH-15611)
https://github.com/python/cpython/commit/86a93fddf72a2711aca99afa0c5374
Mark Dickinson added the comment:
See also #40028
--
___
Python tracker
<https://bugs.python.org/issue37132>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
+1 for the functionality.
How about "counts" instead of "weights"?
I found the name "weights" misleading - my first thought was that this would be
doing a weighted sampling without replacement (like NumPy's `random.ch
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue40541>
___
___
Python-bugs-list mailing list
Unsubscribe:
601 - 700 of 6463 matches
Mail list logo