Nick Coghlan <ncogh...@gmail.com> added the comment:
Thinking back to my signal processing days, I have to agree that our weightings
(filter definitions) were usually separate from our data (live signals).
Similarly, systems engineering trade studies all maintained feature weights
separately from the assessments of the individual options.
The comment from my original RFE about avoiding expanding value ->
weight/frequency mappings "to a full iterable all the time" doesn't actually
make much sense in 3.x, since m.keys() and m.values() are now typically able to
avoid data copying.
So +1 from me for the separates "weights" parameter, with the
m.keys()/m.values() idiom used to handle mappings like Counter.
As another point in favour of that approach, it's trivial to build zero-copy
weighted variants on top of it for mappings with cheap key and value views:
def weighted_mean(mapping):
return statistics.mean(mapping.keys(), mapping.values())
By contrast, if the lowest level primitive provided is a mapping based API,
then when you do have separate values-and-weights iterables, you're going to
have a much harder time avoiding building a completely new container.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
