search

joshuaulrich / rfimport

getSymbols() reboot
16 stars 2 forks source link

Refactor and update TTR #6

Open ethanbsmith opened 3 years ago

ethanbsmith commented 3 years ago

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 https://github.com/joshuaulrich/TTR/issues/68
joshuaulrich commented 3 years ago

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 commented 3 years ago

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

ethanbsmith commented 3 years ago
  1. 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 commented 2 years ago

think this is an example of this issue, or at least related https://github.com/joshuaulrich/xts/issues/366#issuecomment-1107871210