Forgot to reply all.
On Jul 17, 2013 7:20 PM, "Dan Kortschak" <dan.ko...@adelaide.edu.au> wrote:
>
> On Wed, 2013-07-17 at 09:41 -0400, Ethan Burns wrote:
> > > Yes, this is a difficult path; have a look at the parameterisation of R
> > > graphics for a view into Hell.
> >
> > You're right, we don't want to have too many parameters; I'd rather
> > have fewer features.
>
> This is where I think interfaces really come into the picture. I've used
> conditional interface implementation to quite good effect (if I say so
> myself) in my rings package to fine tune data representation.
>
> > Sure. But, I am going to be out of the country until July 27th, then
> > I'll be moving to a new apartment, so I may not be available to work
> > on it more until August 3rd-4th. Perhaps then I can start moving
> > Plotinum over to gonum. I'll ask for a Plotinum repository to be
> > created on gonum-dev, and you can start a wiki page there if you'd
> > like.
>
> Yeah, I'm happy to start populating that - probably also link to this
> thread.
Thanks.
> I think there should probably be a relatively long migration period
> while the design discussion happens.
I completely agree. It is rare to have a period to rethink an API after it has seen some use. We should take full advantage of it.
> > That would be a bigger change, because not only would Axis need to be
> > an interface but Plot would need changes to accept a more general form
> > of axis. For example, Plot assumes that the Y axis is only on the
> > left side and the x axis is only on the bottom of the plot.
>
> A single optional interface implementation would cover this to get the
> Axis' desired placement or fall back to the plotinum standard placement.
>
> > Personally, I don't like plots that completely box in their data area
> > like gnuplot does, so I never considered that someone would want to
> > add support for that. I am open to it, but I think it will be a lot
> > of work.
>
> Yes, this will undoubtedly be a fair amount of work. I think that given
> that you are happy with how plotinum works as it stands that it would
> fall on others to come up with proposals to get this up.
Sounds good to me.
> I also don't particularly like boxed graphs, but some journals like them
> and for more complex figures they can be helpful e.g. [1].
Yes, I can see your point.
> > That was done on purpose. The problem with holding a reference to the
> > data is that if the user changes the data, then plotters made with
> > that reference can be invalid--they expect the data to remain
> > unchanged from the time of creation until they are drawn to the plot.
>
> I think the python dictum of "We're all adults here" is relevant. IFAICS
> this is integrated in the Go idiom too; byte slices are often reused in
> potentially dangerous ways throughout the standard library. All it
> really takes is a statement in the docs that the data are expected to
> remain unaltered after the call to (*plot).Add until the call to
> (*plot).Draw or (*plot).Save.
I still prefer the safety. I also like type checking and bounds checking. We may all be adults, but we are also only human. Though, I may not quite understand your proposal (see below), so perhaps in this case the benefits are worth it.
> The advantage of using an interface is that you can make a lot of the
> plotter types' field parameterisation go away by querying the values
> their prefered representation.
I don't understand how avoiding the copy on XYers and Valuers allows us to avoid parameter fields in the plotter types. I wonder if I am miss understanding your proposal.
> > My preference was to make it impossible for subtle bugs like that to
> > creep into a user's plot by requiring the copy in all of the standard
> > plotters. This is the same reason why I decided to check and error on
> > NaN and infinity values in the data.
>
> I agree with this check - even if only because axis length and plot size
> are indeterminable if these exist and data points should not be
> arbitrarily dropped. R does the same thing.
>
> > These are almost always bugs, they can be very hard to track down, it
> > is easy for them to go unnoticed, and we don't want papers being
> > published with bad results because of plotting bugs.
> >
> > By the way, it should be very easy to copy and hack any of the
> > standard plotters to create non-copying versions.
>
> Yes. Of course.
>
> > So, if someone has so much data that they copy is taking too much
> > memory or is taking a very long time, then they are free to make their
> > own reference-only versions of whatever plotters they use.
>
> My issue with the using a concrete copied type is not so much that it's
> copied, but that it's not an interface (for the reasons above). If
> people are plotting so much that that memory is becoming an issue here
> they are probably in need of some data summarisation prior to the plot
> stage.
I agree about summarizing, but I don't understand why keeping it an interface helps. I may need an example.
By the way, I am going to be out of the country starting now, so I'll be mostly away from email until the 27th. Talk to you then, and thanks for helping think about this stuff with me.
Ethan