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

Raymond Hettinger added the comment: New changeset 6b66dc387935df432cdbc01397ddef534a84ade9 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-38382: Document the early-out behavior for a zero (GH-17037) (GH-17078)

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

Change by Raymond Hettinger : -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker ___

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

Change by miss-islington : -- pull_requests: +16588 pull_request: https://github.com/python/cpython/pull/17078 ___ Python tracker ___

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

Raymond Hettinger added the comment: New changeset 7f460494d2309ace004a400bae8fc59134dc325c by Raymond Hettinger in branch 'master': bpo-38382: Document the early-out behavior for a zero (GH-17037) https://github.com/python/cpython/commit/7f460494d2309ace004a400bae8fc59134dc325c --

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

Warren Weckesser added the comment: On 10/9/19, Mark Dickinson wrote: > > 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

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

Change by Raymond Hettinger : -- pull_requests: +16550 pull_request: https://github.com/python/cpython/pull/17037 ___ Python tracker ___

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

Raymond Hettinger added the comment: > Can we go back to the original issue? Should we just > document the "early out" behaviour on hitting zero, > or should we follow the suggestion to check for bad > data and raise? I would follow Tim's recommendation to document it and be done with it.

[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 real life. -- ___

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

Steven D'Aprano added the comment: Have you read the rest of the thread? There is a compelling reason to support harmonic mean including zero (resistors in parallel) but not yet any compelling reason to support negative values. If you have a good use-case for harmonic mean of negative

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

gaoxinge added the comment: Your point makes sense. We should still also consider the `int`, `Decimal`, `Fraction`, `math.nan`, `math.inf`, `np.int` and so on. So - `geometric mean`: input should be positive (>= 0) - `harmonic mean`: input should be nonzero (!= 0) - `mean` or `fmean`: no

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

Steven D'Aprano added the comment: Thank you for your comments, but accepting non-floats like Decimal and Fraction (and int, of course!) is a hard requirement for the statistics module. fmean will naturally convert any data to float for speed, but the other means will attempt to keep the

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

gaoxinge added the comment: The document https://github.com/WarrenWeckesser/cpython/blob/master/Lib/statistics.py#L389 in `harmonic_mean` is out-dated. I think we can simply follow the wiki: - [arithemic mean](https://en.wikipedia.org/wiki/Arithmetic_mean) - [geometric

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

gaoxinge added the comment: I think that three kinds of mean should behave like: - `geometric mean`: input should be float, finite and positive - `harmonic mean`: input should be float, finite and nonzero - `mean` or `fmean`: input should be float, finite Otherwise these mean functions

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

Raymond Hettinger added the comment: Maybe we should hold-off on adding negative number support unless a compelling use case arises. It is telling that scipy.stats.hmean() and that MS Excel's harmean() haven't found justification to add negative number support. In all likelihood, a

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

Tal Einat added the comment: I'd certainly be surprised to have the order of zero and negative values in the input have such a dramatic effect on the result. It would make debugging these cases unnecessarily confusing and difficult. And I think it is indeed worth fixing, as these edge-cases

[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 and sumAbs

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

Change by Raymond Hettinger : -- assignee: rhettinger -> steven.daprano ___ Python tracker ___ ___ Python-bugs-list mailing list

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

Warren Weckesser added the comment: One more case where the "early out" produces a result that seems wrong: In [20]: harmonic_mean([math.nan, 0]) Out[20]: 0 Anyone who didn't know about the "early out" behavior would probably expect the result to

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

Warren Weckesser added the comment: I really don't like the current inconsistent behavior. I can't help but see it as a bug, and I am surprised that folks think it is OK that harmonic_mean([0, "foo"]) returns 0. This is the *statistics* module, and the first line of

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

Steven D'Aprano added the comment: Thanks Warren, the resistance example is excellent, would you like to write up a PR to add it to the docs? In the original design, I prohibited negative numbers because that seems to be what everyone says you should do, but as far as I can tell it is

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

Raymond Hettinger added the comment: > I don't have a problem with the current behavior (early out on zero, > even if later arguments are senseless). So: > > > * Just document that there is an early-out for zero. That make the most sense to me as well (even though the OP thinks otherwise).

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

Tim Peters added the comment: I don't have a problem with the current behavior (early out on zero, even if later arguments are senseless). So: > * Just document that there is an early-out for zero. -- ___ Python tracker

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

Raymond Hettinger added the comment: The resistor example is persuasive :-) -- ___ Python tracker ___ ___ Python-bugs-list mailing

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

Warren Weckesser added the comment: I find it hard to accept the first option. It seems to let a detail of the current implementation take precedence over API design. I don't see why we would want an API in which harmonic_mean([1, 0, -1]) returns 0 but harmonic_mean([-1, 0, 1]) raises an

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

Raymond Hettinger added the comment: Normally early-out behaviors are allowed to skip any checks for subsequent inputs (for example, the any() and all() builtins stop consuming inputs one a final value is found). However, that reasoning might not apply to a zero input for harmonic_mean().

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

Change by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger, steven.daprano versions: +Python 3.7, Python 3.8 ___ Python tracker ___

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

Change by Warren Weckesser : -- keywords: +patch pull_requests: +16189 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16601 ___ Python tracker

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

Warren Weckesser added the comment: The premature return on ZeroDivisionError also causes an inconsistency in how types are handled. For example, >>> harmonic_mean([1, 0, "foo"]) 0 We get an error as expected if "foo" occurs before 0: >>> harmonic_mean([1, "foo", 0]) Traceback (most

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

New submission from Warren Weckesser : The function statistics.harmonic_mean is supposed to raise a StatisticsError if any element in the input is negative. It fails to do so if the negative element is preceded by a zero. When there is a zero before the negative element, the function