[GSoC-PortA] chart.* as generics

[Brian G. Peterson]

This plan is generally OK.  You do need to be aware of some 
idiosyncrasies that only show up in 'R CMD check'.

Note the difference in the arguments for
?plot
?plot.optimize.portfolio.DEoptim
?plot.optimize.portfolio.ROI

the arguments defines in the generic plot, x and ... *must* be present 
in the correct order in the method.

So as much as I hate 'x' as an argument, the language requires that the 
first arg be the same 'x' as plot()

methods can add more arguments, and you'll note that ours do, but the 
args available in the generic must be available in all the methods.

While we're talking about plotting methods, I wanted to talk a bit about 
the code in chart.Scatter.ROI and a couple other places to generate and 
calculate objective measures for optimization solvers that don't report 
their path.

I like this functionality, but I think we should make it optional, and 
default to FALSE.

I'd like, on all of the scatter charts, to add an option to chart the 
assets in the portfolio, as is done in most commercial optimizers, and 
most optimization charts that you see in R.

I'd also like to allow to optionally plot of an efficient frontier if we 
have a function that can calculate such a frontier.

We already have optional arguments for neighboring portfolios in the 
DEoptim and random charts.

We've also done snail trail charts of the path of the DEoptim 
convergence that might be nice to make an official chart option for 
solvers that report their convergence path.

As for the generics and the documentation, you're on the right track.  I 
would put all the documentation and the @param stuff in the main 
function that calls UseMethod, and use @alias and @rdname everywhere 
else.  If you want to avoid the use of @name, define your wrapper 
function, e.g.

chart.Weights

*first* in the file, and move all the documentation there.  Parse order 
matters, so this will create a chart.Weights.Rd file and will let all 
the other chart.Weights.* methods use

#' @rdname chart.Weights
#' @export

as their only two roxygen comments.

I suspect that once we have everything working, we won't need or want 
the @export tags on all the method functions.



On 08/20/2013 12:17 AM, Ross Bennett wrote:
> Brian,
>
> I have just a couple quick questions regarding chart.Weights and
> chart.RiskReward as generic functions and cleaning up the documentation
> as you did with the versioned functions.
>
> My plan is to use an alias for the chart.Weights.* functions for the
> different classes and then have a generic chart.Weights function with a
> call to UseMethod("chart.Weights"). The first argument is RP for
> chart.Weights.RP, DE for chart.Weights.DE <http://chart.Weights.DE>, and
> so on. Should the arguments of the chart.Weights.* functions be the same?
>
> Should we have the @param and other tags only for one function? Would
> that go on the generic chart.Weights function?
>
> My approach would be the same for the chart.Scatter.* functions.
>
> Thanks,
> Ross
>
>
> On Sun, Aug 18, 2013 at 1:21 PM, Brian G. Peterson <brian at braverock.com
> <mailto:brian at braverock.com>> wrote:
>
>     Sounds good.  - Brian
>
>
>     On 08/18/2013 03:06 PM, Ross Bennett wrote:
>
>         Brian,
>
>         Thanks for clarifying, I was worried that might be the case. I
>         could add
>         a new function named chart.RiskReward and make that our generic
>         function
>         and use an alias for the existing chart.Scatter.* functions. It
>         could
>         look something like this:
>
>         chart.RiskReward.optimize.__portfolio.ROI <- chart.Scatter.ROI
>         chart.RiskReward.optimize.__portfolio.random <- chart.Scatter.RP
>
>         Would that be ok and worthwhile to do?
>
>         Ross
>
>
>
>         On Sun, Aug 18, 2013 at 12:05 PM, Brian G. Peterson
>         <brian at braverock.com <mailto:brian at braverock.com>
>         <mailto:brian at braverock.com <mailto:brian at braverock.com>>> wrote:
>
>              On 08/18/2013 01:35 PM, Ross Bennett wrote:
>
>
>                  The PerformanceAnalytics packages already has a
>         chart.Scatter
>                  function.
>                  Will we have any naming or masking issues if I make
>         chart.Scatter a
>                  function for the different optimize.portfolio.objects?
>
>
>              It's easy to make chart.Weights a generic, but it will be much
>              harder with chart.Scatter.*
>
>              Because PerformanceAnalytics is on CRAN and much more
>         widely used,
>
>              we'd need to match the argument list, and create a
>              chart.Scatter.default in PerfA.  I don't see any way to
>         match the
>              argument list though.
>
>              --
>              Brian
>
>     _________________________________________________
>     GSoC-PortA mailing list
>     GSoC-PortA at lists.r-forge.r-__project.org
>     <mailto:GSoC-PortA at lists.r-forge.r-project.org>
>     http://lists.r-forge.r-__project.org/cgi-bin/mailman/__listinfo/gsoc-porta
>     <http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta>
>
>
>
>
> _______________________________________________
> GSoC-PortA mailing list
> GSoC-PortA at lists.r-forge.r-project.org
> http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta
>


-- 
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock