0

I realised that matrices are a lot faster for storing numeric data than any other format in R. Interestingly they can also be used to speed up my plotly code. Which is desirable because recalculating plotly-plots e.g. in a shiny app can be slow.

However readability in plotly suffers a lot. If I want a line plot together with some text and maybe some dots, the code looks like this:

### Creating sample data
mysim=cbind(x=rep(1:4,4),y=round(runif(16)*10,1),id=rep(1:4,each=4))

plot_ly() %>%
  add_trace(x=mysim[mysim[,'id']==1,'x'],y=mysim[mysim[,'id']==1,'y'],
            type='scatter',mode='lines',opacity=0.9,hoverinfo='skip',
            line=list(color='#AAAAAA',dash='dashed')) %>%
  add_trace(x=mysim[mysim[,'id']==2,'x'],y=mysim[mysim[,'id']==2,'y'],
            type='scatter',mode='text',
            hoverinfo='y',text=mysim[mysim[,'id']==2,'y']) %>%
  add_trace(x=mysim[mysim[,'id']==3,'x'],y=mysim[mysim[,'id']==3,'y'],
            type='scatter',mode='lines',
            line=list(color='#17becf',dash='solid'),hoverinfo='x') %>%
  add_trace(x=mysim[mysim[,'id']==4,'x'],y=mysim[mysim[,'id']==4,'y'],
            type='scatter',mode='marker')

That doesn't look very nice, right?

Is there any way to make this code more readable without making it slower? Since coding these kind of plotly graphs seems cumbersome to me (even when using data.frames), I am thinking about submitting that to Github as an open issue. Thus I want to be sure that I didn't miss something.

I tried improving readability it by

  • using the split argument inside the plot_ly-wrapper (just plots every trace four times)
  • using data=mysim[mysim[,'id']==1,] and x=~xor x=~'x' in the add_trace (returns an error)
5th
  • 2,097
  • 3
  • 22
  • 41
  • You don't use the matrix format of `mysim` in the plotly code. You're just extracting some vectors from `mysim`. You could do `x1 <- mysim[mysim[,'id']==1,'x']`, etc, and use `x1`, `y1`, etc, in the plotly code. – Stéphane Laurent Sep 07 '18 at 11:21
  • Good angle. I didn't think of that. Still seems like an inefficient step given that for all the `add_trace`-functions in this example you need the same `x` and `y` inputs. But I understand that I end up with a speed vs readability trade-off here. – 5th Sep 07 '18 at 11:37

0 Answers0