<div dir="ltr">See comments inline below<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 16, 2013 at 9:36 AM, Brian G. Peterson <span dir="ltr"><<a href="mailto:brian@braverock.com" target="_blank">brian@braverock.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Comments in-line.<br>
<br>
On 08/16/2013 10:52 AM, Ross Bennett wrote:<br>
<...><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What I'd like your thoughts on is developing an example of<br>
converting a v1 constraints specification of any reasonable<br>
complexity to a v2 portfolio specification. I know you have some<br>
helper functions for doing that, but the documentation is still<br>
rather sparse.<br>
<br>
Are you looking for an example of how the user would go about doing this<br>
manually or how this is done behind the scenes with the helper<br>
functions? Or both?<br>
</blockquote>
<br></div>
I think it's reasonable to say in the documentation (the roxygen comments) that attempts will be made to detect and automatically convert v1 style objects. The mechanics of the automatic conversion aren't important to the user.</blockquote>
<div style>I added to the optimize.portfolio documentation to explain the check for a v1 constraint object.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My thoughts run along these lines:<br>
- generate a basic PortfolioAnalytics-package.Rd file either<br>
manually or via roxygen comments that will describe the structure of<br>
the portfolio specification, constraints, and objectives, with links<br>
to the relevant functions. maybe condense soeme generic text from<br>
the optimization overview vignette<br>
<br>
I have been progressively adding to the portfolio_vignette file in the<br>
sandbox folder. I am thinking this could serve as the primary vignette<br>
because I have examples for creating the portfolio object, constraints,<br>
and objectives. I still have work to do to improve the objectives<br>
section. I can add a section that discusses the v1 to v2 migration.<br>
</blockquote>
<br></div>
I like your idea of using the new portfolio_vignette as the primary. The CVaR vignette is still valuable, but it should be secondary to the one you've been working on.<br>
<br>
I've moved that out of sandbox to a vignettes/ dir in the package. Should be the most recent commit r2798</blockquote><div style>Thanks </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also think it would be helpful to have something similar to the<br>
PerformanceAnalytics.pdf reference manual. Is the reference manual<br>
automaticaly generated by .Rd files with roxygen. It would be good to<br>
have both the reference manual and a vignette with complete examples.<br>
</blockquote>
<br>
<br></div>
I've attached the reference manual built from this morning's code.<br>
<br>
As you can see, it jumps right in to function documentation. Addition of a PortfolioAnalytics-package.Rd file would be placed at the beginning of the manual, which would help anyone reading it get started.<br>
<br>
I think we'll also want to consider collapsing some of the v1/v2 functions into the documentation for the main functions e.g. contraint, objective, etc. This can be done with the @rdname tag as a single line comment before the v1/v2 functions, and then we can put the text and all the @param and other tags in front of the main wrapper function.</blockquote>
<div style><br></div><div style>I'm not entirely clear on this step. Take for example the add.objective functions. We have add.objective_v1.Rd, add.objective_v2.Rd, and add.objective.Rd files.</div><div style><br></div>
<div style>add.objective_v2 has an @rdname and @alias tag<br></div><div style><br></div><div style>add.objective is just the alias for add.objective_v2 and only has an @export tag.</div><div style><br></div><div style>Are you saying the @param and other tags should go in front of the alias function?</div>
<div style><br></div><div style>Should we keep _v1 documentation and export those functions for backwards compatibility.</div><div style><br></div><div style>Can I just delete the _v2.Rd files in the man directory so we only have the _v1.Rd files and the unversioned Rd files?</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- put more detail in the documentation for those functions. most of<br>
them are one-liners beyond the required @param info<br>
<br>
I'll beef up the documentation for those functions.<br>
</blockquote>
<br></div>
Thanks.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- perhaps take a look at the 2012 seminar script, and rework one or<br>
more of those portfolios for discussion on this list, with notes<br>
that we can add back into the documentation somewhere.<br>
<br>
Sounds good, I can rework several of the examples.<br>
</blockquote>
<br></div>
Excellent.<br>
<br>
Regards,<br>
<br>
<br>
- Brian<br>
<br>_______________________________________________<br>
GSoC-PortA mailing list<br>
<a href="mailto:GSoC-PortA@lists.r-forge.r-project.org">GSoC-PortA@lists.r-forge.r-project.org</a><br>
<a href="http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta" target="_blank">http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta</a><br>
<br></blockquote></div><br></div></div>