Mark Dickinson added the comment:
Note that the exact values of `1.7**i` don't matter here - some sloppiness in
the `pow` results should not cause a test failure. The key point is that under
fairly mild assumptions about IEEE 754 conformance, the subtractions
`1.7**(i+1) - 1.7**i
Mark Dickinson added the comment:
So if I'm understanding correctly, the cause of the issue is that the value
`1.7**(i+1)` computed in the last iteration (i=999) of the list comprehension
doesn't exactly match the `-1.7**1000` value, because the former is computed at
runtime
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue35048>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Either raising, or treating a zero-weight-sum as undefined behaviour and
documenting that the sum of the weights should be positive sounds fine to me.
-1 on the suggestion to (deliberately, by documented design) choose at random
in this case. Mathematically
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue38881>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
The error you're getting is because you're trying to pack a *value* that's
larger than 255, not because you're trying to pack more than 256 bytes. Packing
more than 256 bytes at a time works fine for me.
>>> packed = struct.
Mark Dickinson added the comment:
Thanks for the suggestion. I'm closing this as rejected, for the reasons Tim
gave.
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
Mark Dickinson added the comment:
[Serhiy]
> What about math.trunc() and round()? Should they return int or float?
math.trunc was deliberately introduced to be an explicitly-value-modifying
conversion to int (as opposed to "int" itself, which is used for both lossy and
lossles
Mark Dickinson added the comment:
[Tim]
> I don't think it would be doing anyone a real favor by returning [...]
Agreed.
> math.floor(), which does return an int, [...] and I believe it was a mistake
> to change it to return an int
Mark Dickinson added the comment:
This isn't a bug: it's the way that Python's assignment model works.
This is explained in various places (including the official Python
documentation), but you may find this excellent presentation by Ned Batchelder
useful: https://nedbatc
Mark Dickinson added the comment:
FWIW, here's the NumPy GitHub issue that led to PCG64 being chosen as the
default BitGenerator. Warning: the comment thread is long (with many
contributions from the PCG author).
https://github.com/numpy/numpy/issues/
Mark Dickinson added the comment:
See discussion in #30880. That issue was closed, though it's possible that it's
time to reconsider.
--
___
Python tracker
<https://bugs.python.o
Mark Dickinson added the comment:
Also worth noting that NumPy 1.17 has now adopted PCG for their default
BitGenerator.
--
___
Python tracker
<https://bugs.python.org/issue38
Mark Dickinson added the comment:
[Terry]
> A correct failure message, correct both as English and Python, should be
> something like 'bool(x) is not True'. I see 'x is not true' as an informal
> English equivalent of the full claim.
I'm not clea
Mark Dickinson added the comment:
[Steven]
py> '%.17f' % 0.95
'0.94996'
That's tricky to use correctly: it's not a priori clear how many digits after
the point are needed to give you a faithful representation (the "17" in "%.
Mark Dickinson added the comment:
What Serhiy said. round is behaving as intended and as designed here.
Note: you can also see the actual value of a float object easily by using
Decimal:
>>> from decimal import Decimal
>>> Decimal
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue38657>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> Maybe we should hold-off on adding negative number support unless a
> compelling use case arises.
+100. It makes little sense mathematically, and I'm sceptical that such use
cases exist i
Mark Dickinson added the comment:
> If float.__ceil__ will be executed it will add significant overhead for
> creating and executing the method object.
Yes, I'd definitely like to see timings; I think Victor already asked for those
Mark Dickinson added the comment:
> I have doubts about adding a C code which is never even executed.
My reading of the PR is that it *would* be executed: the math module first
looks for the __floor__ special method, then falls back to using the libm floor
if that doesn't exi
Mark Dickinson added the comment:
Sorry, but I'm rejecting this: I don't think this is likely to have value to a
range of users, and it's not a basic building block - as such, it doesn't
really fit with the current design and intended usage of the math module.
You might
Mark Dickinson added the comment:
Thank you for the suggestion. I don't think this fits that well with the view
of the math module as a set of basic building blocks: this is quite a
specialist function that wouldn't come up often in applications.
--
nosy: +mark
Mark Dickinson added the comment:
I agree with Serhiy. Any other unrecognised character would raise an error. The
null character should do the same.
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue35
Mark Dickinson added the comment:
> Rewriting all this code just because we have Py_ISDIGIT() is a code churn.
I'm inclined to agree: the current code works and is efficient; there's no
strong reason to change it.
--
___
Python tr
Mark Dickinson added the comment:
> In [20]: harmonic_mean([math.nan, 0])
>
> Out[20]: 0
That one seems excusable, for the same sort of reasons that IEEE 754 specifies
that hypot(nan, inf) is inf rather than nan. Similarly, sumSquare a
Mark Dickinson added the comment:
Closing as duplicate.
@sabakauser: if you update to a recent Python 3.7 (anything more recent than
3.7.1 should be enough), you should find that this is fixed.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
s
Mark Dickinson added the comment:
Looks like a duplicate of #34108
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue36075>
___
___
Pytho
Mark Dickinson added the comment:
This is a common gotcha. Take a look at:
https://docs.python.org/3/faq/programming.html#why-are-default-values-shared-between-objects
--
nosy: +mark.dickinson
resolution: -> not a bug
stage: -> resolved
status: open -&g
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue38308>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
The proposal sounds reasonable to me.
> should a similar change be made for `math.pow` for consistency's sake?
I'd leave math.pow alone here.
--
___
Python tracker
<https://bugs.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:
Right, `max` can only give meaningful results when presented with elements that
belong to a totally-ordered collection. Unfortunately, floats-including-nan is
not such a collection (though floats-excluding-nan *is*, provided we ignore
wrinkles with positive
Mark Dickinson added the comment:
FWIW, I've confirmed again that the exact same script on the same machine seems
fine under Python 3.x. Given the imminent demise of Python 2, perhaps this
issue is just destined to be an unsolved historical o
Change by Mark Dickinson :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
This isn't a bug: super is behaving as designed and as intended here, and
indeed with a diamond inheritance structure you'll see super calling "across"
from one class to its sibling. That's part of how it works.
There's lots o
Change by Mark Dickinson :
--
title: Deadlock in thread.join on Python 2.7/Mac OS X 10.9, 10.10 -> Deadlock
in thread.join on Python 2.7/macOS
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
> Maybe issue38106 related.
That looks plausible, but unfortunately I'm still able to reproduce the hang
with your PR (commit 9b135c02aa1edab4c99c915c43cd62d988f1f9c1, macOS 10.14.6).
--
___
Python
Change by Mark Dickinson :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Dickinson :
Suppose I have a class that looks like this:
class A:
def cleanup(self):
print("Doing essential cleanup")
and on an instance `a = A()`, I do: `atexit.register(a.cleanup)`.
Then it's not obvious from the docume
Mark Dickinson added the comment:
I forgot to include the NumPy issue link:
https://github.com/numpy/numpy/issues/14403 (and other similar issues).
The pip error output you posted looks like the same issue to me.
--
___
Python tracker
<ht
Mark Dickinson added the comment:
There are known Cython-related issues with the latest NumPy *release* and
Python 3.8, due to a signature change in PyCode_New. But those issues are
already fixed in NumPy master. `pip install numpy` fails for me in a Python
3.8b4 venv, but `pip install git
Mark Dickinson added the comment:
Urk! Having `10 == id == 10.1` should imply `10 == 10.1`, by transitivity.
Are interpreter.InterpreterID objects hashable? If so, we've got a violation of
the rule that `x == y` implies `hash(x) == hash(y)`.
--
nosy: +mark.dick
Mark Dickinson added the comment:
Victor
> The purpose of the DeprecationWarning is to give time to numpy developers to
> update the bool_() type, before it becomes an error.
No, that's not what's happening: currently, np.bool_ *does* support __index__.
In the future, it
Mark Dickinson added the comment:
Since this particular issue is about "sort", I'm adding Tim and Raymond to the
nosy list.
--
nosy: +rhettinger, tim.peters
___
Python tracker
<https://bugs.pyt
Mark Dickinson added the comment:
Yes, I think there's a lot of history here that obscures the picture.
We have mechanisms in Python to allow 3rd party objects to be interpreted as
floats (via __float__) or as integers (via __index__).
So np.int64 (for example) doesn't subcla
Mark Dickinson added the comment:
See also #37980. I'd support a change to have the `reversed` argument to `sort`
and `sorted` be automatically interpreted in boolean context.
--
___
Python tracker
<https://bugs.python.org/is
Mark Dickinson added the comment:
Closely related: #37427. I'm not sure why that issue was closed. My naive
expectation would be that in most cases where an API specifies a flag, an
arbitrary Python object can be used for that flag (and is then interpreted in
boolean context). That&
Mark Dickinson added the comment:
@nanjekyejoannah I'm not seeing how that issue is related to this one (except
that they're both about docstrings). Can you elaborate?
--
___
Python tracker
<https://bugs.python.o
Mark Dickinson added the comment:
Unhelpful indeed. +1 to updating those docstrings to match the details at
docs.python.org.
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue37
Change by Mark Dickinson :
--
nosy: +glingl, willingc -mark.dickinson
___
Python tracker
<https://bugs.python.org/issue37968>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Updated title, type and Python version (this would be a new feature, so would
be targeted at Python 3.9).
--
components: +Library (Lib)
title: The turtle -> Add a turtle module function to draw a circle centered at
the turtle
type: -> enhan
Mark Dickinson added the comment:
> 1 the next code SHOULD produce an error message. Think that it's followed
> by a few dozens of code lines:
> from turtle import *
> fd; rt(90)
There's no reasonable mechanism in current Python by which this could produce
an error mess
Mark Dickinson added the comment:
Tim, Raymond: thoughts? I'm inclined to close this as rejected.
--
___
Python tracker
<https://bugs.python.org/is
Change by Mark Dickinson :
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue37946>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
I'd also say that SciPy does this much better than the Python math library
could ever hope to (without that math library effectively becoming a copy of
scipy.special). It probably wouldn't be long before a user of the new Bessel
functions also wan
Mark Dickinson added the comment:
They're not part of the C standard and they're not provided by all C libraries;
we'd have to code our own and add thorough tests for the implementations (as we
have for lgamma, gamma, erf, and other functions that may or may not exist in
th
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue37938>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue37905>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> I guess I'm just not used to 0 being a multiplicative identity.
Yes, there's a whole generation of mathematicians who believe (wrongly) that "0
!= 1" is one of the ring axioms. But it turns out that excluding the zero rin
Mark Dickinson added the comment:
> Z/1Z is a perfectly-well-defined ring.
More to the point, it's a perfectly well-defined ring in which every element is
invertible. That's why the Euler phi function has phi(1) = 1 (rather than
phi(1) = 0)
Mark Dickinson added the comment:
> While I doubt this, he may even argue that it's working correctly already ;-)
Yes, I'd argue exactly that. There's nothing ill-defined about working modulo
+/-1. Z/1Z is a perfectly-well-defined ring. What's the moti
Mark Dickinson added the comment:
> This issue if for optimization only. It does not expand the math module API.
I think it does, though. The PR adds something to the math module that's
tested, that needs to be maintained for other modules to work, and that's
imported for u
Mark Dickinson added the comment:
> Why so?
Python's hash needs to obey the invariant that `hash(x) == hash(y)` for any two
hashable objects with `x == y`. That makes life particularly hard for numeric
types, because there are a number of *different* numeric types where equality
Mark Dickinson added the comment:
> Indeed, I bet it would pay in `long_pow()` to add another test, under the `if
> (Py_SIZE(b) < 0)` branch, to skip the exponentiation part entirely when b is
> -1.
Agreed.
--
___
Python tra
Mark Dickinson added the comment:
> That's a major difference between exponents of bit lengths 61
> ((P-2).bit_length()) and 1 ((1).bit_length()).
Right, but that's stacked up against the cost of the extended Euclidean
algorithm for computing the inverse. The extended gcd f
Mark Dickinson added the comment:
> Should be significantly faster. If not, the new "-1" implementation should
> be changed ;-)
I wouldn't have bet on this, before seeing Raymond's benchmark results. Writing
a fast path for invmod for C-size integers is still on m
Mark Dickinson added the comment:
> shouldn't numerics, datetime objects, and tuples be non-deterministically
> hashed as well? [...]
Making the numeric hash non-predictable while maintaining its current
properties would be difficult.
But fortunately, I don't think it
Mark Dickinson added the comment:
> Because bool is embedded in int, it's okay to return a bool value *that
> compares equal to the int from the corresponding int operation*.
Agreed that it's okay, but I'd like to understand why it's considered
*desirable*. W
Mark Dickinson added the comment:
[Raymond]
> Given that & | and ^ are closed under bools [...]
So maybe the right fix is to change that fact? I'm not sure what the value of
having True & True return True rather than 1 is, beyond misleading people into
thinking that bitwise
Mark Dickinson added the comment:
> isn't `int()` the obvious way "to convert an integer-like thing to an actual
> int"?
Well sorta, except that it's too lenient, letting in strings, floats, Decimal
instances and the like. The strings isn't so much of a
Mark Dickinson added the comment:
There's also the minor annoyance that there isn't currently an obvious safe way
to convert an integer-like thing to an actual int, to make sure that bools do
the right thing in a numeric context. operator.index *ought* to be that obvious
way, but
Mark Dickinson added the comment:
> Making True == -1 looks interesting, but it has drawbacks.
Yes, please ignore that part of my post. :-) It shouldn't be considered
seriously until a time machine turns up (and probably not even then).
My main worry with the proposed change is ac
Change by Mark Dickinson :
--
stage: resolved ->
___
Python tracker
<https://bugs.python.org/issue37831>
___
___
Python-bugs-list mailing list
Unsubscrib
Mark Dickinson added the comment:
See also the discussion started by Antoine here:
https://mail.python.org/pipermail//python-ideas/2016-April/039488.html
--
___
Python tracker
<https://bugs.python.org/issue37
Mark Dickinson added the comment:
Looks like this is essentially a duplicate of #12447
--
___
Python tracker
<https://bugs.python.org/issue37831>
___
___
Pytho
Mark Dickinson added the comment:
For instances of `int`, `~` does bitwise negation (with the usual
two's-complement with an infinite number of bits model that Python uses for all
bitwise operations on arbitrary-precision integers).
And rightly or wrongly, `True` and `False` are inst
Mark Dickinson added the comment:
This is a change of documented behaviour that will affect 3rd party libraries
that provide numeric types, like NumPy and gmpy; it should not be done lightly.
I think such a change deserves at least a deprecation warning, and should also
be discussed more
Mark Dickinson added the comment:
> Mark: Do you think that it's worth it to convert attached fp_except.c into
> tests run by test_float, to check floating point exceptions in Python?
Sure, it wouldn't harm. I'd expect that all these cases are already being
tested indir
Mark Dickinson added the comment:
Duplicate of #15332.
--
nosy: +mark.dickinson
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> 2to3 should fix bad indentation (or warn about it)
___
Python tra
Mark Dickinson added the comment:
> And since it was only introduced
Sorry, that was unclear. "it" refers to "fedisableexcept" in the above.
--
___
Python tracker
<https://
Mark Dickinson added the comment:
> Should I understand that fedisableexcept(FE_OVERFLOW) is useless since
> FreeBSD 6?
That's my understanding, yes. And since it was only introduced in FreeBSD 6,
it's been useless forever. IOW, I think it's true that this line of code,
Mark Dickinson added the comment:
This is essentially a duplicate of #12831. There's nothing 2to3 can reasonably
do here, since it isn't in a position to guess whether true division or floor
division was intended. As noted in the duplicate, the "-3" and the "-Q&q
Mark Dickinson added the comment:
I think you want numpy.angle
(https://docs.scipy.org/doc/numpy/reference/generated/numpy.angle.html).
NumPy is a third-party library, so it doesn't make sense to have the math or
cmath functions be aware of NumPy arrays; none of the other math or
Mark Dickinson added the comment:
Done for 3.9; closing. Thank you for the contribution!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
New changeset dc3f99fa77f415077c20a9c2b3e953e5cd894076 by Mark Dickinson
(Giovanni Cappellotto) in branch 'master':
bpo-37548: Document range of atan, acos and asin (GH-14717)
https://github.com/python/cpython/commit/dc3f99fa77f415077c20a9c2b3e953
Change by Mark Dickinson :
--
resolution: -> not a bug
status: open -> pending
type: resource usage ->
___
Python tracker
<https://bugs.python.or
Change by Mark Dickinson :
--
title: Python Documentation on strings ( section 3.1.2.) -> Python
Documentation on strings (tutorial section 3.1.2.)
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
The documentation is correct here; none of the examples you show demonstrates
implicit concatenation of string-valued expressions.
The tutorial documentation is referring to two strings placed
directly next to each other with no other syntax (other than
Change by Mark Dickinson :
--
keywords: +easy
___
Python tracker
<https://bugs.python.org/issue37548>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Dickinson :
A small nice-to-have: it would be good to document the range of the inverse
trigonometric functions `math.atan`, `math.asin` and `math.acos`, in both the
docstrings and the built documentation.
There are standard "principal values" for eac
Mark Dickinson added the comment:
@Phil: Did you ever get to the bottom of this?
--
___
Python tracker
<https://bugs.python.org/issue37168>
___
___
Python-bug
Mark Dickinson added the comment:
The current FreeBSD documentation for fedisableexcept says:
> All exceptions are masked by default.
Source:
https://www.freebsd.org/cgi/man.cgi?query=fedisableexcept&apropos=0&sektion=0&manpath=FreeBSD+12.0-RELEASE+and+Ports&arch=default
Change by Mark Dickinson :
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue37474>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> What is the behavior on FreeBSD when fedisableexcept(FE_OVERFLOW) is not
> called?
That's an excellent question, that I'd love to have an answer to for currently
supported FreeBSD versions.
I think the old behaviour is that anything that
Mark Dickinson added the comment:
> [...] and then making algorithmic improvements later.
Though thinking about it, there is *one* catch: for the random module, it's
nice if reproducibility isn't broken more often than necessary in released
versions, so it would be b
Mark Dickinson added the comment:
Agreed. We've moved away from the "Python's math module is just a set of
wrappers around the C math library" stage, but it's still important to keep the
math module a coherent set
Mark Dickinson added the comment:
@avi That's Raymond's call, but IMO there's absolutely nothing wrong with
getting a reference implementation (with tests, documentation, and all the
usual trimmings) in first and then making algorithmic improvements later.
Th
Mark Dickinson added the comment:
If you want to be able to switch to something more efficient for large `n`,
Knuth describes a simple O(log(n)) algorithm in TAOCP volume 4 (and attributes
it to J. H. Ahrens). It's essentially a bisection search on the value, using
the fact that we ca
Mark Dickinson added the comment:
Ah, now I've looked at the script. There's an issue with using
`random.random()` to create "small" values for testing, since its result is
always an integer multiple of 2**-53. That means in particular that if x =
random.random(),
Mark Dickinson added the comment:
> however, for x < 0.0 it is always worse
That's quite surprising. Which platform? And can you give some example inputs
and outputs? With a good math library, I'd expect `log1p(x)` to almost always
be at least as accurate as `log(1 + x)`, a
901 - 1000 of 6463 matches
Mail list logo