Replies: 1 comment
-
I'm not adverse to DataFrames, if for no other reason than those are easier for target audience of this package. That will be another breaking release though (we're still well pre-1.0, so that's fine, but something to keep in mind). It was an ... interesting exercise to rewrite all the package internals to avoid dataframes. 😉 It might be interesting add (and expose) functions that do pieces of the assembly, e.g. separating out the "create between-G dataframe" into an exported function. Then we could allow creating designs with arbitrary crossings or nestings (as compared to our current requirement for two blocking variables). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I know - I am the one who is always advocating using
Tables.jl
rather thanDataFrames
but I think a good case can be made in this package for preferringDataFrames
. There are various kinds ofjoin
s (in the relational database sense) defined inDataFrames
, and a lot of work went into making the joins faster in v1.0.0It occurs to me that a good way of starting a design with crossed
subj
anditem
blocking factors and possible between subject and between item experimental factors is to create asubject
table and anitem
table and to take thecrossjoin
of those two tables.We can, of course, clean this up. I like @palday 's idea passing a dictionary or even just a tuple of pairs for the between-subject or between-item specifications (e.g.
:age => ["young", "old"]
) and let the function creating the data frame figure out what repetition pattern is to be used.Beta Was this translation helpful? Give feedback.
All reactions