chrisadolph / tile-simcf

R packages for visualizing statistical models, with tools for counterfactual simulation
faculty.washington.edu/cadolph/software
13 stars 10 forks source link

Specify plot number in trace for line plot, but not scatter plot? #1

Open ghost opened 12 years ago

ghost commented 12 years ago

Given two traces, it seems like you have to specify the plot number for line plots, but not for scatter plots, in order to get two separate graphs. For example, the following code produces two scatter plots for the two traces, but only one line plot for the two traces:

# Libraries
library(foreign)
library(tile)

# Make some data
x = rnorm(10,1)
y = rnorm(10,1)

# Set scatter traces
s.trace.1 <- scatter(x=x, y=y)
s.trace.2 <- scatter(x=x^2, y=y^2)

# Set line traces
l.trace.1 <- lineplot(x=x, y=y)
l.trace.2 <- lineplot(x=x^2, y=y^2)

# Make tile of scatters -- makes two graphs
s.tile <- tile(s.trace.1, s.trace.2)

# Make tile of lineplots -- makes only one graph
l.tile <- tile(l.trace.1, l.trace.2)

This can be solved by specifying different plots for each trace, but it seems odd that this happens. Maybe there is there an error in my code?

Thanks,

Mike

chrisadolph commented 12 years ago

This sounds like a bug, but also leads to a question for how to do with cases where users omit the plot argument from a trace call. Note that omitting the plot argument is allowed but usually bad coding practice for a tile user. Always specify the plot number to avoid heartache later!

Some trace types (major traces) do a lot: scatter, lineplot, ropeladder, nightplot, and riceplot all create a lot of stuff, and might be the core of a plot within a tile graphic. Thus, the reasonable default behavior is for each to go on the "next" available plot.

Some trace types (primitive traces) do a little: textTile, linesTile, pointsTile, polygonTile, etc. These primitives are usually just added to a plot that also has other traces, and probably one of the major trace types above. So you might argue these should go on the "current" plot, which is to say, the plot number of the last "major" trace plotted.

We should check to make sure the above rules are followed consistently, though I'm open to rethinking this principle if people think it's too confusing.

A side note: at present, the only thing the precedence of traces in a tile call should determine is to serve as a tie-breaker in determining which trance elements with the same layer number get plotted first.