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

[Bengoechea Bartolomé Enrique (SIES 73)]

> I'm a definite proponent of descriptive naming, 

I'm also, but only for languages that are not interactive!!

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

Sorry, my fault. I was talking of "polluting the namespace" at a conceptual level, in the sense of overloading the capacity of the user to remember so many different function names....

> 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.

This is the case with many R classes. "zoo" for example can be either a vector or a matrix, and its index can be of any class provided a few methods are provided for it. So it shouldn't be a problem. A few checks and a good number of coertion methods should do the trick. In fact, It seems to me that your functions checkDataVector() and checkDataMatrix() are kind of fulfilling the role of standard coertion methods, isn't it? Why not use the standard facilities provided by the language?

It's true most functions in your package wouldn't match standard generics as they provide financial-specific computations, but then functions like chart.Bar() could implement the generic barplot() if a "returns" class that extends "zoo" is defined (just an example!)

It would be nice to have other people's feedback, but my own libraries became much easier to use and maintain when I made an effort to build classes and reuse standard generics. Also, when in doubt about some convention, to me it makes sense to match those in the base packages, even if I agree naming an argument "x" is not very appealing  :-))

> 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 ended up doing this for my own code and, yes, it simplified things a lot. 

In any case, very interesting issues.

Best,

Enrique