Consistency w.r.t. external weights

[dmbates]

It looks as if my original code was not consistent with respect to external, or prior, weights, saved as r.wts in a GlmResp object r. The main reason for allowing weights in a GLM is for a Binomial response in the form of the number of successes and the number of trials. In those cases the response is evaluated as the proportion of successes with the prior weights being the number of trials.

In the wrkwt! method for GlmResp there is a check on whether r.wts is empty but it never will be. The fit method for an AbstractGLM initializes the weights to ones(y) if they are not specified as an optional argument.

I have a slight preference for changing the default prior weights to being a zero-length vector and retaining the checks on whether it is empty or not but that may be making the code overly-complicated to save a very small amount of time and storage. Should we always have prior weights, even if they are unit weights?

[andreasnoack]

The VectorOfOnes type has been mentioned a couple of times. It might make the code simpler than checking for an empty vector, but I'm not sure.

[nalimilan]

Indeed, might be a good application. For reference: JuliaStats/StatsBase.jl#135

[dmbates]

I expect all of this is very minor but, in addition to having a vector of unit weights take up space there is the issue of unnecessary multiplications by 1. If you have hundreds of thousands of observations and you can do one check of isempty{r.wts) then skip all of the accesses and multiplications by the unit weights you are better off then going through the access of the unit value and multiplication by it.

[nalimilan]

@dmbates The idea behind the Ones type (see reference above) is that it would be optimized out when compiling a specialized method for that argument type. This would allow writing only the most generic code (with weighting) and still get an efficient special-case.