Feedback from people at UQ: we would like to have multiple columns to represent point estimates of different nature (transcriptomics/protemics) or multiple replicates for the same data and condition (or isozymes, etc.) for a particular reaction.
pub struct Data {
// ...
/// Decide the column of the boxpoint.
box_x: Option<Vec<String>>,
// ...
}
Then each entity with Aesthetics, GeomHist and Point<f32> should be spawned with a Column component containing Vec<Option<String>>. This would be accumulated per axis in the build_point_axes with a similar logic than that of conditions. plot_box_point will need to account for the new x coordinate.
As a nice to have, the tag of each column should be put on top of the column ($\pi/2$ if more than two letters), although immediate readability should not be prioritized in this case.
Why
Feedback from people at UQ: we would like to have multiple columns to represent point estimates of different nature (transcriptomics/protemics) or multiple replicates for the same data and condition (or isozymes, etc.) for a particular reaction.
What
Given the following figure:
(From Valgepea et al., 2018)
We would like the same but inverting rows and columns.
How
ggshu
geom.boxpoint()
would now also take ax
aes that would identify the column. The API would be something like:shu would now accept a box_x field:
Then each entity with
Aesthetics
,GeomHist
andPoint<f32>
should be spawned with aColumn
component containingVec<Option<String>>
. This would be accumulated per axis in thebuild_point_axes
with a similar logic than that of conditions.plot_box_point
will need to account for the new x coordinate.As a nice to have, the tag of each column should be put on top of the column ($\pi/2$ if more than two letters), although immediate readability should not be prioritized in this case.