Growth Curve Table Set (for manuscripts)

[wibeasley]

(Spun off from Issue #97)

Now that the plan for the correlation tables have stabilized (issue #129). @ampiccinin, @andkov, and @wibeasley concentrated today's meeting on the "growth curve table set".

@ampiccinin tentative first choice resembles the screenshot below.

• Each table is dedicated to a specific measure; each column is a specific to a study.
• Each cell is actually an average of multiple estimates. For instance, the fictitious 0.4688 in the top left cell is the average estimate of the bnt when it was paired with all ~4 physical processes.
• The tables will have a different number of columns, because not all studies have all measurements.
• It will actually be double the number of columns b/c the variables are regressed on each other (I didn't quite understand, but I do think it need to yet.)

• The next step is for @andkov to re-introduce these estimates into the parser. He's creating an issue for this.
• @andkov & @wibeasley will then produce this version, and another version where the columns represent the betas (instead of representing the studies). Hopefully it won't be too disorienting to users accustomed to the initial version. There are a few programming advantages to it. Also, it might be easier to compare estimates between studies (say, b1) when you're scanning up/down a column, instead of left/right across a row.

[andkov]

@wibeasley , the issue #132 has implemented the expansion of the parser to include covariate estimates. The updated catalog now includes all six covariates. Please try for a draft of the table sketched above.

[andkov]

Sketch of the table system:

Compressor = Condenser Condenser A = est (se) p Condenser B = est *

model = subgroup, model_type, process_a, process_b, term = component of the model (e.g. a_TAU_00, b_GAMMA_12, etc.) index = quantitative property of the estimate: est, se, wald, or p-value

[andkov]

The generic table in which row = process and col = various contexts in which this process was statistically related (for process bnt: grip-bnt, gait-bnt, fev-bnt, etc)

study	model_type	subgroup	process_type	process_name	mean estimate	context 1	...	context K
elsa	aehplus	female	b	bnt	3.50	3.00	...	4.00

Each column/context represents the measure, with with the row measure was statistically related during estimation (cpntext1 = gait, context2 = grip,context3 = fev, context4 = animals, bnt, etc + contextK = univar)

[andkov]

Questions to address

• there will be twice as many rows in orange and yellow, does that make a difference in our plans?
• the range of values across various statistical contexts is quite substantial (especially for the intercept of the second level), how do we deal with it?

[wibeasley]

During the call with @ampiccinin, @GracielaMuniz, and @andkov, we decided that the growth curve table will show up only in the study-specific papers --and not in the meta paper. If the meta readers want this information, they can go to the dynamic tables hosted on the workshop's repo.

The study-specific papers should resemble this one below. These sections will exist for the level2 intercept, and then repeated immediately below for the level 2 slope. The column/process order should resemble the grouping of the outcome space map.

@ampiccinin & @GracielaMuniz, please add respond this explanation isn't consistent with your plans, or if there's another detail I left out.

[ampiccinin]

@andkov - how easy would it be to create a version of the "seed" tables that included "process A" only as a single column next to the Process B (cognitive) output? We could select the process A version to include by just picking the one that comes first alphabetically (or some other arbitrary method, that is equally implementable in each study). We can't realistically include all of the different process A models in the appendix, it is difficult to see how any of the relatively small differences matter, it takes a bunch of time to reformat each of those tables for publication (in an appendix) for each study and each paper, and the information will be available for the curious and obsessive on GitHub. It was important to be able to look at them ourselves, but it is too much to provide to the typical reader.

Assuming it will be much faster for you to programming an alternate reformatted version of the table (kind of like the full and focussed versions of the correlations) than for multiple people to reformat each table for each study and each project by hand.

Thanks!!!

[wibeasley]

but it is too much to provide to the typical reader

Word.

@andkov, I'm getting my projects mixed up. For this one, have we considered placing a 'master copy' (that's too big for normal consumption w/o filtering) in a DT, that's on a GitHub.io page? It should be easier to reference from a static/paper article than a knitr report that's located on the conventional side of the repository.

[andkov]

@ampiccinin, Good point, simpler is better. Let me think about what you have said, how to implement it. Would you have 10-15 mins to chat tomorrow to help me understand?

[andkov]

@wibeasley, no we haven't spoken about this. I was considering turning it into a GitHub.io website, so this might be a good time.

So you think to host just the DT? You think it might be too big to be imbedded in a report to host through rawgit?

[ampiccinin]

I'll be heading to Vancouver for the day, but since you are 3 hours ahead, we could try before I go, or maybe while I wait for the ferry. Or now?

[andkov]

@ampiccinin, Can't now, sorry, too sleepy. I'm usually up by 5 am local, so pretty much any time your morning works for me. Give me some warning, if possible, and call my cell any time. If you can point me to the report, we don't really need a screenshare.

[ampiccinin]

Will do.

the table/report to which I refer is, for example: seed-elsa 2017-02-07.docx

So - for example - you would insert the "word_de" column for the rows next to process "a" down next to the process "b" variables (I would suggest in first column after "label"). The whole top sections of the table (all rows "ab" and "a" would then drop out. Then, down in the variances section, you would just have to print the relevant ones "a" for "a" and "b" for "b". Finally, the last bit could remain as-is.

I hope this makes sense when you look at the file! If you send questions in the morning, I can think about the answer before I call.

[andkov]

@ampiccinin , so you would like to drop some rows entirely and add a column that contains info for one process?

[andkov]

create a version of the "seed" tables that included "process A" only as a single column next to the Process B (cognitive) output?

for example, insert the "word_de" column for the rows next to process "a" down next to the process "b" variables (I would suggest in first column after "label"). The whole top sections of the table (all rows "ab" and "a" would then drop out. Then, down in the variances section, you would just have to print the relevant ones "a" for "a" and "b" for "b". Finally, the last bit could remain as-is.

[ampiccinin]

@andkov - I will call. Here is what I was trying to describe! :)

ABcombine example.docx