Proposed solution for embedding external function with outputtype = "character"

[jhmigueles]

At the moment GGIR does not handle the embedding of an external function that outputs a character vector.

For example, I am trying to embed a function that outputs a vector with different classes of behaviours at epoch-level. The reporttype of myfun will then be time in each class.

[vincentvanhees]

The user can already specify:

outputtype = "character"
reporttype = "type"

as discussed in the vignette.

The missing part it seems is the step to summarise these values at the end of function g.analyse.perday.

EDIT: also missing are type specific imputation and a few other steps, but I can now see you work on that.

To reduce storage space it may actually be best to store the values as factor, even though we call it a character.

[vincentvanhees]

HI @jhmigueles I am now looking at your initial work in master...issue1126_embeddingExtFunctionCharacter

Keep in mind that I tried to isolate all code specific to handling external function output from the normal GGIR code.

If you have not already done so, it may be good if you could look at the changes I have prepared in https://github.com/wadpac/GGIR/tree/issue653_step_updated_withmaster. This gives an idea of how I tried to isolate external function output processing (steps as instance of event type output in this case) from the rest of GGIR. As you can see I created entirely new functions dedicated to aggregating events. It would be good if you could use a similar approach for processing type data with maybe new functions aggregateType or detectTypeBout.

I was asked not to merge that branch yet, but I now realise that it is getting very difficult for you to work on the code while this work is not merged. So, I think best solution is to merge their work and to comment out the key functionalities they do not want to be used yet. I will be in touch about this.

[vincentvanhees]

Additionally, I think it is best to avoid focussing the code around the the R class "character" of the data being produced. Instead it would be good if you could focus on it being of the reporttype "type" as opposed to event (like steps) or scalar (like a metric). I think that makes the code more intuitive to read, because external data is then allowed from these three categories of output. Further, for anyone wanting to contribute to GGIR code it needs to be clear that all this code relates to external function output and can be skipped when working on GGIR's own functionality.