[issue38992] testFsum failure caused by constant folding of a float expression

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

[issue38992] testFsum failure caused by constant folding of a float expression

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 using

[issue35048] Can't reassign __class__ despite the assigned class having identical slots

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

[issue38881] unexpected behaviour of random.choices with zero weights

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

[issue38881] unexpected behaviour of random.choices with zero weights

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

[issue38837] struct.pack: Unable to pack more than 256 bytes at a time

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.pack("<51

[issue38813] math.modf() change integer returned part as integer instead of float

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.python.or

[issue38813] math.modf() change integer returned part as integer instead of float

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

[issue38813] math.modf() change integer returned part as integer instead of float

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

[issue38808] weird bug while using a for loop and array

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://nedbatchelder.com/text

[issue38767] Replace Mersenne Twister RNG with a PCG family algorithm

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/13635

[issue38767] Replace Mersenne Twister RNG with a PCG family algorithm

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.org/issue38

[issue38767] Replace Mersenne Twister RNG with a PCG family algorithm

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

[issue38706] What should the error message in the exception raised by assertTrue and assertFalse be?

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 clear whether you're suggesti

[issue38703] should we expect round(0.95, 1) to be 1.0, instead of 0.9?

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 "%.17f" isn't going to be t

[issue38703] should we expect round(0.95, 1) to be 1.0, instead of 0.9?

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

[issue38657] String format for hexadecimal notation breaks padding with alternative form

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

[issue38382] statistics.harmonic_mean fails to raise error with negative input that follows a 0

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 in rea

[issue38629] float is missing __ceil__() and __floor__(), required by numbers.Real

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 on

[issue38629] float is missing __ceil__() and __floor__(), required by numbers.Real

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 exist. A

[issue38606] Function to count total number of common divisors of two numbers

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 consider publishing

[issue38606] Function to count total number of common divisors of two numbers

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

[issue35714] Document that the null character '\0' terminates a struct format spec

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

[issue38474] digit check logic can be replaced by Py_ISDIGIT on prepare_s

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 tracker <

[issue38382] statistics.harmonic_mean fails to raise error with negative input that follows a 0

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

[issue36075] python 2to3 conversion tool is generating file with extra line for every input line

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

[issue36075] python 2to3 conversion tool is generating file with extra line for every input line

Mark Dickinson added the comment: Looks like a duplicate of #34108 -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue36075> ___ ___ Pytho

[issue38370] An array as attribute of an object is shared between instances

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

[issue38308] Add optional weighting to statistics.harmonic_mean()

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

[issue38237] Expose meaningful keyword arguments for pow()

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.python.org/issu

[issue38181] some trable with max when np.nan is in the first of a list

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

[issue38181] some trable with max when np.nan is in the first of a list

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

[issue26360] Deadlock in thread.join on Python 2.7/macOS

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 oddity

[issue38171] super() is passing wrong parameters while handling diamond inheritance

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

[issue38171] super() is passing wrong parameters while handling diamond inheritance

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 of thoughtful w

[issue26360] Deadlock in thread.join on Python 2.7/macOS

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

[issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9, 10.10

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 trac

[issue38062] Clarify that atexit.unregister matches by equality, not identity

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

[issue38062] Clarify that atexit.unregister matches by equality, not identity

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 doc

[issue38027] Can't use Numpy, SciPy, pandas in Python3.8.0b4 without conda

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

[issue38027] Can't use Numpy, SciPy, pandas in Python3.8.0b4 without conda

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

[issue38005] Coercing strings and non-integer numbers to interpreter ID

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

[issue37980] regression when passing numpy bools to sorted(..., reverse=r)

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 won't. The

[issue37980] regression when passing numpy bools to sorted(..., reverse=r)

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.python.o

[issue37980] regression when passing numpy bools to sorted(..., reverse=r)

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 subclass int

[issue37427] sorted, list.sort reject non-boolean objects with __bool__() as `reverse` parameter

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/issue37

[issue37980] regression when passing numpy bools to sorted(..., reverse=r)

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's

[issue37973] improve docstrings of sys.float_info

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.org/issue37

[issue37973] improve docstrings of sys.float_info

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

[issue37968] Add a turtle module function to draw a circle centered at the turtle

Change by Mark Dickinson : -- nosy: +glingl, willingc -mark.dickinson ___ Python tracker <https://bugs.python.org/issue37968> ___ ___ Python-bugs-list mailin

[issue37968] Add a turtle module function to draw a circle centered at the turtle

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

[issue37968] The turtle

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 message; it's

[issue37946] Add the Bessel functions of the first and second kind to the math module

Mark Dickinson added the comment: Tim, Raymond: thoughts? I'm inclined to close this as rejected. -- ___ Python tracker <https://bugs.python.org/issue37

[issue37946] Add the Bessel functions of the first and second kind to the math module

Change by Mark Dickinson : -- nosy: +tim.peters ___ Python tracker <https://bugs.python.org/issue37946> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37946] Add the Bessel functions of the first and second kind to the math module

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 wanted Bessel

[issue37946] Add the Bessel functions of the first and second kind to the math module

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 the platform libm

[issue37938] refactor PyLong_As*() functions

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

[issue37905] Remove NormalDist.overlap() or improve documentation?

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

[issue37893] pow() should disallow inverse when modulus is +-1

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 ring from

[issue37893] pow() should disallow inverse when modulus is +-1

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), for exam

[issue37893] pow() should disallow inverse when modulus is +-1

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 motivation for this cha

[issue37884] Optimize Fraction() and statistics.mean()

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 use in anot

[issue29535] datetime hash is deterministic in some cases

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 can h

[issue37863] Speed up hash(fractions.Fraction)

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

[issue37863] Speed up hash(fractions.Fraction)

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 for com

[issue37863] Speed up hash(fractions.Fraction)

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 my to-do li

[issue29535] datetime hash is deterministic in some cases

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's necessary

[issue37831] bool(~True) == True

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*. What use-cases benefi

[issue37831] bool(~True) == True

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 oper

[issue37831] bool(~True) == True

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 an issue - it's

[issue37831] bool(~True) == True

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 it leaves

[issue37831] bool(~True) == True

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 acciden

[issue37831] bool(~True) == True

Change by Mark Dickinson : -- stage: resolved -> ___ Python tracker <https://bugs.python.org/issue37831> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue37831] bool(~True) == True

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

[issue37831] bool(~True) == True

Mark Dickinson added the comment: Looks like this is essentially a duplicate of #12447 -- ___ Python tracker <https://bugs.python.org/issue37831> ___ ___ Pytho

[issue37831] bool(~True) == True

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 instances

[issue37807] Make hash() return a non-negative number

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

[issue37474] Should Py_Initialize() control the floating point mode?

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 indirectly by som

[issue37714] 2to3 tab Problems

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

[issue37474] Should Py_Initialize() control the floating point mode?

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

[issue37474] Should Py_Initialize() control the floating point mode?

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, in its curren

[issue37716] 2to3 Accuracy of calculation

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" comma

[issue37676] cmath.phase array support

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 cmath

[issue37548] Document range of atan, acos and asin

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

[issue37548] Document range of atan, acos and asin

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/dc3f99fa77f415077c20a9c2b3e953e5cd894076

[issue37575] Python Documentation on strings (tutorial section 3.1.2.)

Change by Mark Dickinson : -- resolution: -> not a bug status: open -> pending type: resource usage -> ___ Python tracker <https://bugs.python.or

[issue37575] Python Documentation on strings (tutorial section 3.1.2.)

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

[issue37575] Python Documentation on strings ( section 3.1.2.)

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

[issue37548] Document range of atan, acos and asin

Change by Mark Dickinson : -- keywords: +easy ___ Python tracker <https://bugs.python.org/issue37548> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37548] Document range of atan, acos and asin

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"

[issue37168] Decimal divisions sometimes 10x or 100x too large

Mark Dickinson added the comment: @Phil: Did you ever get to the bottom of this? -- ___ Python tracker <https://bugs.python.org/issue37168> ___ ___ Python-bug

[issue37474] Should Py_Initialize() control the floating point mode?

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=0=0=FreeBSD+12.0-RELEASE+and+Ports=default=html So it looks as though it may be s

[issue37474] Should Py_Initialize() control the floating point mode?

Change by Mark Dickinson : -- nosy: +tim.peters ___ Python tracker <https://bugs.python.org/issue37474> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37474] Should Py_Initialize() control the floating point mode?

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 you'd

[issue37439] Add random.binomialvariate()

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 best to do

[issue37450] Generalize Euclidean distance function in the math module to Minkowski distance

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 of basic build

[issue37439] Add random.binomialvariate()

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. Thanks for the PR

[issue37439] Add random.binomialvariate()

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 can use

[issue37454] Clarify docs for math.log1p()

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(), then 1 - x

[issue37454] Clarify docs for math.log1p()

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)`, and substan

<    5   6   7   8   9   10   11   12   13   14   >