plotting types

[Bob Carpenter]

[moving to stan-dev]

> On Jun 12, 2015, at 8:11 AM, Allen B. Riddell <a...@ariddell.org> wrote:
>
> Competition is healthy, I think. The absence of competition would be
> awful.
>
> In the interest of fairness, I'll note that PyStan brazenly borrows its
> trace plotting routine from PyMC.

Do you have images of what they look like somewhere handy?

> It's not a priority but it would be great to have roughly consistent *plots*
> across all interfaces embodying the current thinking about what such
> plots should look like. (Are people happy with the way they look in R?)

I think we should talk about this at one of our meetings. Or maybe
in person. I'm now very taken with ggplot, but I know Andrew has issues
with everything from tick mark placement to size and length.

- Bob

[Ben Goodrich]

On Friday, June 12, 2015 at 1:05:22 PM UTC-4, Bob Carpenter wrote:

> It's not a priority but it would be great to have roughly consistent *plots*
> across all interfaces embodying the current thinking about what such
> plots should look like. (Are people happy with the way they look in R?)

I think we should talk about this at one of our meetings.  Or maybe
in person.   I'm now very taken with ggplot, but I know Andrew has issues
with everything from tick mark placement to size and length.  

My view is that ShinyStan is several orders of magnitude better than anything I could do statically in R, and what R can do statically is at least as good as what any other interface to Stan could do statically. So, we should concentrate on making it easy for someone, regardless of what Stan interface they used, to get their CSV output into ShinyStan via a web browser and not worry too much about plotting in the interfaces themselves.

If on the other hand, we did want to spend time beefing up the plotting capabilities of the interfaces, then it seems very difficult to standardize the plots. The only BSD plotting library that (I know of that) is any good is matplotlib, which now has a C++ interface

https://github.com/lava/matplotlib-cpp

I don't think it is worth doing, but it might be a good undergrad project.

Ben

[Bob Carpenter]

As much as I love ShinyStan, I think it serves a different
purpose than an in-language, in-workflow plotting tool. I need to
be able to drop plots into papers, e-mails, or knitr docs, not just
pop up a GUI.

Can ShinyStan be configured to plot without firing up an
interactive tool?

Even if it can, I don't think it's going to replace an
in-language tool that can be scripted and integrated into
a workflow directly.

Allen --- were you talking about a shared implementation across
interfaces, or just a shared standard for plots?

- Bob

> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Allen B. Riddell]

On 06/12, Bob Carpenter wrote:
> As much as I love ShinyStan, I think it serves a different
> purpose than an in-language, in-workflow plotting tool. I need to
> be able to drop plots into papers, e-mails, or knitr docs, not just
> pop up a GUI.
>
> Can ShinyStan be configured to plot without firing up an
> interactive tool?
>
> Even if it can, I don't think it's going to replace an
> in-language tool that can be scripted and integrated into
> a workflow directly.
>
> Allen --- were you talking about a shared implementation across
> interfaces, or just a shared standard for plots?

Shared plotting "guidelines" and general look-and-feel. Not a shared
implementation.

If the plots produced by RStan, PyStan, etc looked roughly the same I'd
count that a victory. I'll work on making some screenshots for you in a bit.