Refactor and update TTR

[ethanbsmith]

not sure if TTR is in scope for this or not, but one of the things i'd like to see is some of technical calculations:

1. intentionally name all output columns. most functions do this, but some just carry forward the name of the column they operated on
2. standardize on univariate. some function operate on multi-column input, other don't. i just think it would be easier if this were handled in a standard way, with maybe an exception for things like diff.xts
3. always return a structured output. i.e an empty xts with the proper column names and types, or an xts with all NA if the input is too short, like run* functions optionally return all NA if nrow(x) < n TTR#68

[joshuaulrich]

I'd like to do something similar with TTR, but it would stay in a different package like it is now.

1. Agreed.
2. Can you give an example of what you mean? Some functions require OHLC data. I'm not sure how you'd make those univariate.
3. Agreed.

[joshuaulrich]

Updated the title of the issue because 'tidy' makes me shiver.

[ethanbsmith]

2. One example is the ALMA implementation which was multivariate due to a side product of the original implementation using rollapply. I think it would be better for this to be univariate output and have the caller do a loop or apply over columns, like how SMA, EMA, etc work. ROC is another one.

I guess the rule would be something like: TTR function should not loop over multi-column input. The looping should be done explicitly by the caller.

[ethanbsmith]

think this is an example of this issue, or at least related joshuaulrich/xts#366 (comment)