[R-SIG-Finance] PerformanceAnalytics package: modern econometrics (...)

[Brian G. Peterson]

On Tuesday 06 March 2007 09:03, Bengoechea Bartolomé Enrique wrote:
> Thanks a lot for sharing this package, which I find very very
> interesting, and fills an important gap in R financial packages.
>
> After reviewing the docs I have some remarks which I know are mainly a
> matter of personal preference rather than real issues, and I know YMMV,
> but please let me share them with you.

Enrique,

Thanks for the feedback.

> First, on function names. When I started programming in R I created
> verbose names like the ones in this package. I came from a background
> in languages like Java where communicating purpose is important when
> naming functions and variables, and typing long names is not an issue
> because IDEs make your life easy. Nevertheless, R is also an
> *interactive* environment, and I realized I was typing the same long
> names again and again on the GUI, which was repetitive, prone to error,
> and bad for my RSI. So with time I renamed functions like
> "CalculateReturns" and "MaxDrawdown" to "returns" or "mdd", and I'm
> much happier now...

I'm not set on this one way or the other.  I'm a definite proponent of 
descriptive naming, and I tend to maximize my use of an editor or IDE 
that includes intelligent completion of function and variable names.  
I've struggled in R to remember many of the very obscure short function 
names that I don't use constantly.  One option here, of course, is to 
create additional alias functions in the package like BCoS() to make sure 
you don't need to type BetaCoSkewness().  I don't have a good answer 
here, so more input from the community is appreciated. 

> I also learnt to turn my functions into methods. As a functional
> language, functions are first-class elements in R. It's generally
> recommeded to avoid polluting the namespace with tons of new functions,
> which makes them hard to remember. The preferred design is to create
> new classes that use standard methods as much as possible, as they are
> already known and easily remembered by other R users. An example of
> this for financial users is the difference between classes "timeSeries"
> and "zoo". I extensively tested both of them (and several others), and
> decided to use "zoo" for what is stated on its documentation:

when I load the package using

library(PerformanceAnalytics)

The ls() output is the same before and after loading the package.  Unlike 
using source() where function names from the sourced file become part of 
the top-level namespace. 

It seems that only if I were to use export() in the package load function 
would any of the code entities from the PerformanceAnalytics package get 
put into the global namespace.

Clearly I must be missing a distinction in how package namespaces work.  
Perhaps you could clarify?  

> "key design goals are (...) consistency with ts and base R by providing
> methods to standard generics. Therefore, standard functions can be used
> to work with "zoo" objects and memorization of new commands is
> reduced."

Clearly, this makes lots of sense for classes like zoo and timeSeries, 
which are effectively extensions of standard R data types and methods.

For these econometric functions, I just couldn't see a good way to wrap 
them up into a class that makes any logical sense.  Sometimes you're 
working with vectors of returns, other times with regular or irregular 
timeseries/zoo objects, sometimes with one instrument, sometimes with 
many.

The code currently uses mostly vectors and data.frames internally.  We're 
strongly considering changing to use zoo internally for everything, as it 
would probably also make some of the rolling and aggregation code we 
wrote redundant.

I'm open to specific suggestions, but couldn't come up with a good 
paradigm that made this functionality feel like obvious objects or 
classes.
 
> I really like "timeSeries", but having to remember and type
> "diffSeries" each time instead of just "diff", which I can apply to
> many different classes of objects, is a pain in the ass for me. And I
> see similar design decisions on this PerformanceAnalytics package.
>
> With respect to parameters naming, I also find disturbing to have the
> main parameter of each function called "R", the name of the language
> itself!!! I started applying different conventions to my functions, but
> ended up using those in the base R package, where the main argument is
> usually called "x", "data", or similar.

I would be open to renaming the variables to lowercase 'r', 'ra', 'rb' if 
the community feels strongly about it, although I'm not sure what would 
be gained. I think in general that the descriptive clarity is far better 
than a non-differentiated 'x', and consistency of naming across the 
package is more important than using 'x' for the handful of functions 
that take only one parameter.
 
Regards,

  - Brian

-- 
773-459-4973 mobile
http://braverock.com/brian/resume-quant.pdf