Added method error_contribution_from.

[natfarleydev]

The function error_contribution_from allows developers to discover the complete contribution from a set of tags specified by a predicate function.

This is part way to address #70. Since Python is awesome (or uncertainties' authors are, reader's choice), tuples can be used for tags instead of strings. This means that with the new function error_contribution_from one can:

from uncertainties import *
x = ufloat(1, 1, tag=("x", "statistical"))
y = ufloat(1, 1, tag=("y", "statistical"))
z = ufloat(1, 1, tag=("z", "systematic"))

w = x + y + z
w_systematic_error = w.error_contribution_from(lambda t: "systematic" in t)
w_statistical_error = w.error_contribution_from(lambda t: "statistical" in t)

Note

This pull request does not (yet!) include documentation changes. These will be added when the code is agreed upon.

[natfarleydev]

@lebigot Any thoughts?

[lebigot]

Sorry for the delay in responding.

This function is useful, but it can really be a simple one-liner, so I prefer not to include it, because I want to keep the module as small as possible while making even powerful things easy enough to implement (like here):

def error_contribution_from(self, filter_tag):
    """
    Return the error contribution from specific error components.

    Return the error contribution from error components for
    which filter_tag(tag) is true.
    """
    return sqrt(sum(error**2 for (var, error) in self.error_components().iteritems() 
                    if filter_tag(var.tag)))

[natfarleydev]

I can see where you're coming from (keeping libraries small is good) but I think a function like this makes uncertainties much more valuable. Relying on the user to figure this out and reimplement it every time instead of providing it in the interface is an unnecessary barrier to entry.

I'm not wedded to the idea of using a function like this; I think there must be a cleaner/clearer way to implement feature. Either way, I think it's worth thinking about how to expose this functionality straight from a ufloat. (Maybe through multiple errors per value?)

I use this feature every day for my analysis and it's extremely useful (saving a lot of time).

[natfarleydev]

Perhaps an extras library would be good for stuff like this? Then there can be these helpful functions without clogging up the main library.

[lebigot]

I like the idea of extending the UFloat class with this, thanks! I'm reopening this pull request as a kind of reminder.

[codecov-io]

Codecov Report

Merging #72 into master will decrease coverage by 0.28%.
The diff coverage is 16.66%.

@@            Coverage Diff             @@
##           master      #72      +/-   ##
==========================================
- Coverage   94.62%   94.33%   -0.29%     
==========================================
  Files          12       12              
  Lines        1954     1960       +6     
==========================================
  Hits         1849     1849              
- Misses        105      111       +6

Impacted Files	Coverage Δ
uncertainties/core.py	96.31% <16.66%> (-0.72%)	⬇️
uncertainties/umath_core.py	98.91% <0%> (-1.09%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8c7a833...842a45b. Read the comment docs.