Mark Dickinson added the comment:
> int/int is less accurate than float/float for t=1580301619906185300
No, int/int is more accurate here. If a and b are ints, a / b is always
correctly rounded on an IEEE 754 system, while float(a) / float(b) will not
necessarily give a correctly roun
Mark Dickinson added the comment:
See renewed discussion in #39479, which may lead to math.lcm being added in 3.9.
--
___
Python tracker
<https://bugs.python.org/issue19
Change by Mark Dickinson :
--
superseder: -> datetime.strftime("%Y") not consistent for years < 1000
___
Python tracker
<https://bugs.py
Mark Dickinson added the comment:
> if you disagree with the resolution of that issue
Sorry, my mistake. That issue is still open.
--
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
Closing as a duplicate of #13305. Feel free to add to the discussion there if
you disagree with the resolution of that issue.
--
nosy: +mark.dickinson
resolution: -> duplicate
stage: -> resolved
status: open -&g
Mark Dickinson added the comment:
Related SO question:
https://stackoverflow.com/questions/60005876/how-does-python-compare-int-to-float-objects
--
___
Python tracker
<https://bugs.python.org/issue39
New submission from Mark Dickinson :
The documentation[1] for comparisons between mixed types says:
> [...] when a binary arithmetic operator has operands of different
> numeric types, the operand with the "narrower" type is widened to
> that of the other, where integ
Mark Dickinson added the comment:
@shihai1991 Good catch! Now fixed.
--
___
Python tracker
<https://bugs.python.org/issue39434>
___
___
Python-bugs-list mailin
Change by Mark Dickinson :
--
pull_requests: +17687
pull_request: https://github.com/python/cpython/pull/18311
___
Python tracker
<https://bugs.python.org/issue39
Mark Dickinson added the comment:
Apologies, I think I moved the discussion off-track. The first order of
business should be to fix the regression. We can discuss behaviour changes
after that.
I've opened GH-18309 as a quick fix for the regression
Change by Mark Dickinson :
--
pull_requests: +17685
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/18309
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
The relevant piece of Python code from fractions.py looks like this:
if type(numerator) is int is type(denominator):
# *very* normal case
g = math.gcd(numerator, denominator)
if denominator < 0:
g = -g
e
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue39350>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Victor: I suspect there's some compiler magic going on, too; a good compiler
should be able to figure out that half of the div/mod calculation is not being
used, and strip it out. That wouldn't have been possible before with the tuple
packing and unpacking
Mark Dickinson added the comment:
Thank you!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
New changeset 8d49f7ceb4f961770ae61fe6a4033c4e61cc3288 by Dong-hee Na in branch
'master':
bpo-39434: Improve float __floordiv__ performance and error message (GH-18147)
https://github.com/python/cpython/commit/8d49f7ceb4f961770ae61fe6a4033c4e61cc3288
Mark Dickinson added the comment:
I'd guess a // gcd(a, b) * b would be faster, on the basis that division is
slower than multiplication. But I doubt it's worth worrying about for this
implementation, given that the gcd call is likely to be the bottleneck as a and
b get large
Mark Dickinson added the comment:
Great. For clarity, here's a Python function giving the behaviour I'd expect
from a 2-arg lcm:
from math import gcd
def lcm(a, b):
if a == 0:
return 0
return abs(a // gcd(a, b) * b
Mark Dickinson added the comment:
+0 from me as well; agreed with everything that Tim said (except that I've
never had a need for the Carmichael function; my RSA implementations do the
inefficient thing based on (p-1)(q-1)).
This is somewhat reminiscent of comb and perm: lcm is often taught
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +17540
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18154
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
So the risk here is that by adding the floordiv fast path, the division code is
duplicated, and that increases the risk of accidentally losing the invariant
that `a // b` is interchangeable with `divmod(a, b)[0]` (e.g., because someone
decides to &quo
Mark Dickinson added the comment:
Is this worth optimising? Floating-point floor division is a comparatively rare
operation.
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue39
Mark Dickinson added the comment:
> If you think I need to come up with a specific example where this can be
> misused
I think so, yes. :-)
We shouldn't change this (and risk other breakage) without evidence that
there's an actual problem.
--
nosy: +mark.dic
Change by Mark Dickinson :
--
assignee: docs@python -> mark.dickinson
___
Python tracker
<https://bugs.python.org/issue39426>
___
___
Python-bugs-list mai
Mark Dickinson added the comment:
> Do you want to submit a PR?
Not immediately. I'll add it to my to-do list, but definitely won't complain if
someone else gets there first.
--
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Dickinson :
>From the pickle.Pickler docstring:
> The optional *protocol* argument tells the pickler to use the given
> protocol; supported protocols are 0, 1, 2, 3 and 4. The default
> protocol is 3; a backward-incompatible protocol designed for Python 3.
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue39415>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Similar previous issues on macOS: #18513, #15477.
--
___
Python tracker
<https://bugs.python.org/issue39409>
___
___
Python-bug
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue39409>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> I don't have an issue reference to hand
See #18513.
--
___
Python tracker
<https://bugs.python.org/issue39396>
___
___
Py
Mark Dickinson added the comment:
So on cmath.exp, we've seen something like this before, on macOS. What was
happening was that the C source contained matching `sin` and `cos` calls, and a
compiler optimization replaced that pair of calls with a single call to C's
cexp. And then cexp didn't
Mark Dickinson added the comment:
BTW, stupid question: why is `test_nextafter` in `test.test_math.IsCloseTests`
and `test.test_cmath.IsCloseTests`? The first seems inappropriate; the second
even more so.
--
___
Python tracker
<ht
Mark Dickinson added the comment:
> Mark: what's your call on that one?
I don't know. It's a hard problem in general: where do we draw the line between
simply wrapping the platform libm, bugs and all, on one hand and trying to
abstract away platform differences and make guarantees ab
Mark Dickinson added the comment:
[Brett]
> Can I just say that "ulp" is totally non-obvious what that even means unless
> you have a specific math background?
It's a good point. I guess we have a choice between using the domain-specific
standard-ish name (which shoul
Mark Dickinson added the comment:
Okay, looks like Windows is happy in the PR's continuous integration. If the
buildbots are also happy, then I'm content to have this pushed through.
--
___
Python tracker
<https://bugs.python.org/issue29
Mark Dickinson added the comment:
> If tests continue to fail on some platforms, I plan to manually handle NaN
> and INF in the C code, before calling libc fma().
For Windows, you need to do much more than this: it's not just about handling
NaNs and infinities, it's about reimplem
Mark Dickinson added the comment:
[Steven]
> Any chance you could look at fma too? #29282
fma is hard, for reasons explained in the issue you linked to. If you have
suggestions for resolving the difficulties, please do add them to that is
Mark Dickinson added the comment:
Pablo: thanks for the quick fix!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
> I suggest "next_after" instead of "nextafter".
"nextafter" gives us consistency with C, with NumPy and with other compound
names in the math module ("isnan", "isclose", "copysign"). My o
Mark Dickinson added the comment:
Is the fix as simple as adding the word "floor" before "division" in the
"equivalent to division by [...]" phrase?
> A right shift by n bits is equivalent to floor division by pow(2, n) without
> overflow check.
T
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue39301>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> Do you mean nextafter(x, y=inf, /): toward positive infinity by default?
Yes; I believe that was what Steven was suggesting in the last part of
msg359779. I don't have strong feelings either way.
--
___
Pyt
Mark Dickinson added the comment:
[Steven]
> I know Wikipedia isn't a primary source, but it says IEEE 754 recommends
> nextafter(x, y).
Um. Then it sounds as though Wikipedia is out of date. Which page was this on?
IEEE 754-1985 did recommend nextafter, but only in Annex A,
Mark Dickinson added the comment:
"nextafter" is fine with me. I just wanted to make sure that we'd considered
the options, and weren't choosing nextafter simply because it's the easiest
thing to implement.
[Victor]
> It mentions for example "If x== y, y (of the type x)
Mark Dickinson added the comment:
I'm not opposed to some form of this by any means, but I fear there's some
bikeshedding to go through, both on the name and the functionality (one
function with two arguments, or two functions each taking a single argument?).
C 99 prescribes "next
Mark Dickinson added the comment:
For completeness and to save people going to the NumPy tracker, here's an
example of the problem:
Python 3.8.1 (default, Jan 5 2020, 21:32:35)
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credi
Mark Dickinson added the comment:
Agreed that __bool__ should return an actual bool.
``return bool(a._numerator)`` does seem like the obvious way to do this.
--
___
Python tracker
<https://bugs.python.org/issue39
Mark Dickinson added the comment:
[Robert]
> It is not a "positional argument" but an "optional argument".
I don't think I understand. Here the phrase "positional argument" in the docs
is, I assume, referring to the parameter "ham: str" in the
New submission from Mark Dickinson :
The glossary entry for parameter[1] says:
> Python has no syntax for defining positional-only parameters.
Since PEP 570 landed in Python 3.8, that's no longer true.
[1] https://docs.python.org/3/glossary.html#term-parameter
--
assignee: d
Mark Dickinson added the comment:
(See also #21444)
--
___
Python tracker
<https://bugs.python.org/issue39227>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Duplicate of #12159?
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue39227>
___
___
Python-bug
Mark Dickinson added the comment:
[Karthikeyan]
> can possibly break again if (x-c) * (x-c) was also changed to return float64
> in future
I think it's safe to assume that multiplying two NumPy float32's will continue
to give a float32 back in the future; NumPy has no reason to giv
Mark Dickinson added the comment:
Right, the HOWTO language could possibly be improved. The intended and
practical message is that you *only* need to provide __lt__ everywhere for sort
to work.
--
nosy: +rhettinger, tim.peters
___
Python tracker
Mark Dickinson added the comment:
To be precise, when doing `a < b`, either `a.__lt__` or `b.__gt__` can be used,
since `__gt__` is considered the reversed / reflected version of `__lt__`
(analogous to `__add__` and `__radd__`).
>>> class A:
... def __lt__(self, other):
Mark Dickinson added the comment:
I'm going to close this here. The issue can be re-opened if there's consensus
on python-ideas or elsewhere that it's useful.
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
_
Mark Dickinson added the comment:
Thanks for the suggestion. If you want to get this added to core Python,
there's a bit more you'll need to do here: first, you'd need to persuade the
core developers that this functionality is needed. Some real-world motivating
examples would help a lot
Change by Mark Dickinson :
--
Removed message: https://bugs.python.org/msg359060
___
Python tracker
<https://bugs.python.org/issue39167>
___
___
Python-bug
Mark Dickinson added the comment:
This looks like a duplicate of #37564.
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue39
Mark Dickinson added the comment:
> You can close again if you feel this isn't a bug.
Yep, it's still not a bug. As Steven said, Python is correctly (modulo
undiscovered bugs) implementing the C3 algorithm, and the C3 algorithm does
indeed fail in this case.
--
n
Mark Dickinson added the comment:
Closing as a duplicate of #36048 (which isn't quite right, since this issue
came first, but it's probably close enough).
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Deprecate implicit tru
Mark Dickinson added the comment:
Serhiy: any thoughts about what version should be targeted for eventual removal
of the functionality deprecated in this PR? 3.10?
--
___
Python tracker
<https://bugs.python.org/issue36
Mark Dickinson added the comment:
@Batuhan: I think so, yes; at least, the "deprecated" part is done. The
"eventually removed" is not, and I don't know whether we have a target version
for that removal.
--
___
Py
Mark Dickinson added the comment:
@adelsonllima: Take a look at the documentation that I linked to for the round
function, and in particular this note:
"The behavior of round() for floats can be surprising: for example,
round(2.675, 2) gives 2.67 instead of the expected
Change by Mark Dickinson :
--
status: open -> closed
type: crash -> behavior
___
Python tracker
<https://bugs.python.org/issue39124>
___
___
Python-bugs-
Mark Dickinson added the comment:
Michael: if you want to take this further, your best bet would probably be to
start a discussion on the python-ideas mailing list
(https://mail.python.org/mailman3/lists/python-ideas.python.org/).
--
nosy: +mark.dickinson
Mark Dickinson added the comment:
More details on the change here:
https://docs.python.org/3/whatsnew/3.0.html#builtins
and in the library documentation:
https://docs.python.org/3/library/functions.html#round
--
___
Python tracker
<ht
Mark Dickinson added the comment:
In Python 3, the rounding mode is round-ties-to-even. (In Python 2, it's
round-ties-to-away.)
--
nosy: +mark.dickinson
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Pytho
Mark Dickinson added the comment:
This isn't a bug. After this line in your code:
o = x
both o and x refer to the same list object. So any modification you make to
that list through the name "x" (for example, x[i][n]+=y[i][n]) will be seen
through the name "o" as
Mark Dickinson added the comment:
> Maybe port this discussion over python-ideas and after the resolution open it
> again?
Sounds good to me. Adding a new builtin function is a big deal that would
likely need a PEP. I'm not keen on adding something like this to the math
module,
Mark Dickinson added the comment:
[ctarn]
> it works as expected with Python 3.6 (the owner of each of them is d), and
> Python 3.8 and Python 3.7 work differently
The change in behaviour is the result of a bug fix that was applied in 3.7 and
upwards: see GH-13169 and #27639.
As Eri
Mark Dickinson added the comment:
What would the proposal look like for `statistics.stdev`? There you need at
least two data points to compute a result, and a user might want to do
different things for an empty dataset versus a single data point.
--
nosy: +mark.dickinson
Mark Dickinson added the comment:
Thanks, Eric. I'm now convinced that we shouldn't weaken the Decimal behaviour,
and I agree that it's risky to change the float and int behaviour. So it's
sounding as though we're looking at a "won't fix" resolution here.
There are still the doc
Mark Dickinson added the comment:
There's no reasonable way I can see to fix this. The reassignment of those
string attributes is clearly intentional (it's even documented) and there's
probably code somewhere that relies on it. I think the best we can do is close
as "won't fix&qu
Mark Dickinson added the comment:
[Eric]
> Is that the "0" here: [...]
Yes, sorry; that could have been clearer.
> In particular, what if you specify a different alignment type with the
> pre-width 0?
Right, that's the critical question here. For floats and ints, an
e
Mark Dickinson added the comment:
For completeness, here's the path leading to the reassignment (after hacking in
a raise to the appropriate place in _localemodule.c). It's a side-effect of
calling `locale.getpreferredencoding`.
>>> help(int)
Traceback (most recent call last
Mark Dickinson added the comment:
> Regarding cases 3-7 I'd like to suggest a slightly different resolution:
Hmm, yes. I was concentrating on the Decimal results, but I agree that these
int/float results are disturbing:
>>> format(12345, "<020")
'1234500
Mark Dickinson added the comment:
> But given that there's only 2 weeks of support left for 2.7, I don't see this
> getting changed.
Agreed: I can't reproduce on Python 3, and it looks as though the offending
code is gone from the codebase in Python 3, so this is pretty muc
Mark Dickinson added the comment:
Here's where `string.letters` is reassigned:
https://github.com/python/cpython/blob/5f2c1345a79f205c680ed6e0a6ed44199546d79e/Modules/_localemodule.c#L136-L147
That code looks like it's exercised whenever setlocale is (or possibly just
when LC_CTYPE
Mark Dickinson added the comment:
I *can* reproduce, on macOS 10.14.6, Python 2.7.17 (from macports).
Python 2.7.17 (default, Oct 20 2019, 14:46:50)
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or
Mark Dickinson added the comment:
Thanks for the report. I think most of this is a documentation issue: we either
need to make clear that the formatting documentation applies only to the float
type and that Decimal follows its own rules (usually for good reason, namely
that it's required
Change by Mark Dickinson :
--
Removed message: https://bugs.python.org/msg358567
___
Python tracker
<https://bugs.python.org/issue39077>
___
___
Python-bug
Mark Dickinson added the comment:
Thanks for the report. I think most of this is a documentation issue: we either
need to make clear that the formatting documentation applies only to the float
type and that Decimal follows its own rules (usually for good reason, namely
that it's required
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue39077>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Dickinson :
--
nosy: -mark.dickinson
___
Python tracker
<https://bugs.python.org/issue39059>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
@AVicennA: 4.39 *is* the correctly-rounded result for `round(4.395, 2)`. Modulo
(as-yet unreported) bugs, `round` does correct-rounding (in the IEEE 754 sense)
in all cases. I was pointing out that your `my_round` does not solve the
problem you think
Change by Mark Dickinson :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Mark Dickinson :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
@AVicennA: as the docs you linked to explain, this is not a bug: `round` is
giving the correct result in all cases (or at least, as correct as is possible
given the use of binary floating-point).
Let's take just the first case, `round(2.675, 2)`. `2.675
Mark Dickinson added the comment:
Tim, Raymond: I propose that we close this issue as "won't fix". The suggestion
to add `math.total_ordering` could be broken out into a separate issue.
--
___
Python tracker
<https://bugs.python.o
Mark Dickinson added the comment:
> IMHO sorting functions should emit a warning if they contains an unorderable
> objects
How do you define "unorderable", and how do you propose to detect "unorderable
objects" efficiently in practice within the sorting algorith
Mark Dickinson added the comment:
For the record, this is an easy application of itertools.combinations:
>>> def segment(s, m):
... for c in itertools.combinations(range(1, len(s)), m-1):
... yield tuple(s[i:j] for i, j in zip((0,)+c, c+(len(s),)))
...
>>> list(
Mark Dickinson added the comment:
See issue 27100, which led to a deliberate change in behaviour to look up
__enter__ before __exit__. It looks like the documentation (not the PEP text,
which shouldn't be considered normative; just the reference manual) needs to be
adjusted to match the new
Mark Dickinson added the comment:
I think this was already fixed in 3.5, but the fix would have gone in later
than the 3.5.2 release: see issue #27706. 3.5.3 and later should have the fix.
--
nosy: +mark.dickinson
___
Python tracker
<ht
Mark Dickinson added the comment:
Fixed in master and 3.8. Not sure this is worth backporting to 3.7.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
New changeset 3c5feaffde1944052830c896ae39c54e76a2e063 by Mark Dickinson (Miss
Islington (bot)) in branch '3.8':
bpo-38992: avoid fsum test failure from constant-folding (GH-17513) (GH-17530)
https://github.com/python/cpython/commit
Mark Dickinson added the comment:
New changeset bba873e633f0f1e88ea12fb935cbd58faa77f976 by Mark Dickinson in
branch 'master':
bpo-38992: avoid fsum test failure from constant-folding (GH-17513)
https://github.com/python/cpython/commit/bba873e633f0f1e88ea12fb935cbd58faa77f976
Mark Dickinson added the comment:
@AVicennA Can you clarify exactly which part of the output you find surprising,
and why, and what result you expected instead? It's a little hard to tell which
details in your message we're supposed to be looking at.
--
nosy: +mark.dickinson
Mark Dickinson added the comment:
@xdegaye Please could you test whether the PR GH-17513 fixes the issue for you?
--
___
Python tracker
<https://bugs.python.org/issue38
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +16990
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17513
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
This has nothing to do with range. The source of indeterminacy is this line in
your code:
for amp_id in amp_programs.keys():
In Python 3.5, the ordering of `amp_programs.keys()` could differ from run to
run. (With Python 3.6 and later, that won't
801 - 900 of 6360 matches
Mail list logo
