zscore ci level

[graceannobrien]

Logic for .ci and .zscore arguments is confusing: User can only input 90 or 95% CI, else user has to provide z-score AND CI. A user could input mismatching .ci and .zscore (i.e. ci 80 and z-score 1.96) and function would allow that

define_param_table(.estimates = paramEstimatePath, .key = paramKeyPath, .ci = 95) 
define_param_table(.estimates = paramEstimatePath, .key = paramKeyPath, .ci = 90) 
define_param_table(.estimates = paramEstimatePath, .key = paramKeyPath, .ci = 80, .zscore = 1.282)

Proposal:

• allow user to input .ci OR .zscore and function will calculate the other one. Seems likely most users will use .ci.
• if user provides both, function will check that they match

Concerns:

• Can we always assume users will want to use two-tailed z-score?

[seth127]

As noted in this comment on #64, we plan to deprecate the .zscore argument and calculate it manually instead, for all values of .ci. Note that this will also necessitate changing param_notes()$ciEq() to not use hard-coded values. (While we're there, delete this confusing logic.)

The current plan is to replace this with a more generic note, likely using the $z_{\alpha/2}$ LaTeX (from here). @KatherineKayMRG or @kylebaron could one of you write the replacement note that you'd like and put it in a comment here? Thanks in advance.

[kylebaron]

Some ideas (if this is what the question is); I've hard-coded ci = 95 into the output here, but we will glue() or paste() that in based on what is passed for ci. @KatherineKayMRG thoughts?

[KatherineKayMRG]

Oooph good question. I think I'd lean towards option 4 and have as little as possible subscripted - it gets small in the report. But I'm open to other peoples preferences too.

@timwaterhouse you've commented on these notes in other issues - any strong preferences here

[timwaterhouse]

@KatherineKayMRG We're just talking about the table footnote now, right? I prefer option 4 as well. I think that's the cleanest while still providing all the information.

[KatherineKayMRG]

Yes sorry, there was a discussion last week about re-factoring how CIs are calculated to avoid hard coding the CI. The package will now calculate the Z-score (defaulting to 95% CI still) so the footer also needs updating to reflect how it will be calculated.

It will cause some minor difference in CI estimates because the current hard coded z-scores for 95% and 90% CIs were rounded to 3 sd - calculating them will have increased precision and hence cause slight differences in CI estimates. We just want to be clear what is being returned by the package version