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 tha
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 probabl
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
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
Change by Warren Weckesser :
--
keywords: +patch
pull_requests: +16189
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16601
___
Python tracker
<https://bugs.python.org/issu
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:
>>> harmon
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
