May-23-2022, 02:15 AM
Thanks for the feedback, and sorry for the delay in responding.
The numeric value of the result should be correct (to the limitations of the data types involved) or else it would count as a bug. It is only the output type of the result which may be surprising, if you mix input types. So if you have a mix of float, Fraction, Decimal, subclasses of each, etc, you may not be able to easily guess the output type. But the output value should be the same regardless.
The
Technically that is not documented behaviour, but I need to get an estimate of how many people are relying on the current behaviour and will notice the change.
(May-16-2022, 07:45 AM)Gribouillis Wrote: The «result is not guaranteed» part worries me. It means that the occasional user has a certain probability to get a wrong result because they introduced some inhomogeneity in the data.
The numeric value of the result should be correct (to the limitations of the data types involved) or else it would count as a bug. It is only the output type of the result which may be surprising, if you mix input types. So if you have a mix of float, Fraction, Decimal, subclasses of each, etc, you may not be able to easily guess the output type. But the output value should be the same regardless.
The
statistics module doesn't actually document the rule it uses to work out the "best" output type, but it is complicated and requires a lot of work. (Possibly more work than actually computing the numeric value!) I hope that, by simplifying that rule, I can speed up the statistics functions. But that may mean that computations which today return one type may return a different type in the future.Technically that is not documented behaviour, but I need to get an estimate of how many people are relying on the current behaviour and will notice the change.