WIP: Abstract type for summary statistics (Mean)

[nadiaenh]

Resolves #275, #184, #274
Partial implementation of @smishr's confidence interval function
Implemented Mean structure as an abstract SummaryStat

Remaining to do on this PR :

• Implement "t" and "margin" confidence intervals
• Add more attributes to Mean structure (standard error of estimate, ...)
• Add support for ReplicateDesign
• Write test/SummaryStats.jl
• Make sure documentation is in order
• Delete mean.jl once all functionality is implemented in Mean struct ?

Can implement Total, Quantile, and Ratio later

[smishr]

The main goal is to have an easy type dispatching over all the SummaryStats Functions. We need to check how Function types heirarchy works in Julia. There should be AbstractFunction and mean, total etc can be sub types of (<:) SummaryStats::AbstractFunction

[smishr]

Yes this abstract type looks good

[smishr]

Am wondering if SummaryStats should be an AbstractFunction instead?

[nadiaenh]

Didn't know about this, will look into it !

[smishr]

EDIT: After reviewing I think you can just copy the entire of _ci from 190 and rename it here.

• I think estimate and std_dev should be type AbstractVector (like in _ci in WIP: Add general CI and integration with mean #190 ). This way you can pass whole column of estimates at the same time.
• I would keep confint in a different file confint.jl.

[smishr]

• This should be an addition to the existing mean.jl file. You can add with multiple dispatch you can define mean(x::Symbol, design::ReplicateDesign, ci_type=normal ...) see WIP: Add general CI and integration with mean #190 line 169-170 of what the defintion of function can be
• build for ReplicateDesign first, since SurveyDesign doesnt have std error yet

[nadiaenh]

• to your first point : see my reply to your comment on line 60
• to your 2nd point : yes that makes sense

[smishr]

• This should be done as part of edits inside mean.jl
• Im not sure whether the struct would just need two things x and design
• I have gut feeling that Mean should be a Function, not a struct. Lets ask @ayushpatnaikgit this.

[nadiaenh]

I went with the idea that it's easier to have all summary statistics as a struct in a single file (SummaryStats.jl) since it's easier to manage, if we want to add another statistic later on you would just add it to this one file.

The reason for having Mean as a struct (as well as a Function) is the same : if we want to add other statistics, and we want all statistics to have a set of basic elements (e.g. an estimate), you would write this into SummaryStats which is the "parent abstract type" and it would be automatically passed down to all the other statistics (since Mean <: SummaryStats). At least this is my understanding.

Also mean.jl (and quantile, ratio, total) has a lot of dispatched functions, so I thought it'd be more efficient and maintainable to have only 1 file which implements all summary stats, instead of 1 file per stat (mean.jl, quantile.jl etc) which has multiple dispatched functions inside.

I agree with having confint.jl separately though.

Thoughts ?

[ayushpatnaikgit]

Have you considered how this would work with domain estimation? Where we have mean(:variable, :domain, design)?

[ayushpatnaikgit]

Overall, I think it's a good idea to be able to do ans.estimate, ans.CI and ans.SE. Need to think through the implementation.

It will need a few show methods to make it beautiful.

[ayushpatnaikgit]

I suggest having

struct Estimate
   value::Number
   SE::Number
end

Instead of SummaryStat and Mean

mean, quantile and total can be factory functions for the structure.

For domain estimation, we'll need a separate struct
perhaps

struct DomainEstimates
   values::Vector{Number}
   SE::Vector{Number}
end

After this, we can have a function confint(x::Estimate).

[smishr]

struct Estimate
    value::Number
    SE::Number
end

How does this broadcast to estimates which are vectors?

[asinghvi17]

Any reason not to use https://github.com/JuliaPhysics/Measurements.jl here? It's fundamentally the same data structure but probably supported more widely across the ecosystem. In this case a vector estimate would be a vector of Measurements.

[codecov-commenter]

Codecov Report

Merging #277 (bc220b2) into next_release (e9362f9) will decrease coverage by 4.48%.
The diff coverage is 0.00%.

@@               Coverage Diff                @@
##           next_release     #277      +/-   ##
================================================
- Coverage        100.00%   95.52%   -4.48%     
================================================
  Files                12       14       +2     
  Lines               200      268      +68     
================================================
+ Hits                200      256      +56     
- Misses                0       12      +12     

Impacted Files	Coverage Δ
src/SummaryStats.jl	0.00% <0.00%> (ø)

... and 3 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[smishr]

Any reason not to use https://github.com/JuliaPhysics/Measurements.jl here? It's fundamentally the same data structure but probably supported more widely across the ecosystem. In this case a vector estimate would be a vector of Measurements.

Ayush and I looked at the Measurements.jl package, we see where you are coming from. Except for the pretty printing of uncertainty, their class would not be useful for other aspects of Survey.jl. But some ideas can be adapted from them