There is the FRED indicator (in DataExtensions) which returns a large number of time series of Federal Reserve Economic Data from the Research Department at the Federal Reserve Bank of St. Louis.
Many of these Series have absolute values/levels (for example prices). The FRED web page allows to convert these series to one of:
lin = Levels (No transformation)
chg = Change
ch1 = Change from Year Ago
pch = Percent Change
pc1 = Percent Change from Year Ago
pca = Compounded Annual Rate of Change
cch = Continuously Compounded Rate of Change
cca = Continuously Compounded Annual Rate of Change
log = Natural Log
Such a "Unit Conversion" makes the series much better suited for use in a trading strategy (or Indicator profiler and friends).
The FRED Indicator should use the FRED API request "fred/series/observations" and allow "units" as one of the indicator's parameters.
Many of these Series have absolute values/levels (for example prices). The FRED web page allows to convert these series to one of:
lin = Levels (No transformation)
chg = Change
ch1 = Change from Year Ago
pch = Percent Change
pc1 = Percent Change from Year Ago
pca = Compounded Annual Rate of Change
cch = Continuously Compounded Rate of Change
cca = Continuously Compounded Annual Rate of Change
log = Natural Log
Such a "Unit Conversion" makes the series much better suited for use in a trading strategy (or Indicator profiler and friends).
The FRED Indicator should use the FRED API request "fred/series/observations" and allow "units" as one of the indicator's parameters.
Rename
I find such excess of options in the indicator parameters dialog confusing the majority of its users except the power users like you. :/
Well, we all are looking for helpful indicators, indicators which can tell profitable trades from losing trades.
Chances are, that "external" indicators (like the FRED time series) do a better job than indicators derived from prices.
And in case of the FRED indicator this one more parameter makes the difference between useful and meaningless...
Chances are, that "external" indicators (like the FRED time series) do a better job than indicators derived from prices.
And in case of the FRED indicator this one more parameter makes the difference between useful and meaningless...
QUOTE:
... a "Unit Conversion" makes the series much better suited for use in a trading strategy (or Indicator profiler ...
I agree of course. One wants to "normalize" the data to factor out any extraneous behavior that would taint the metric comparison. The question remains, "Should this normalization (or unit conversion) occur on the server (Fred) or client (WL) side?
I would say if the normalization requires multiple external data sources to perform, doing it on the server side would be preferred. The goal here is to minimize data movement between client and server. Of course, if the transform is done on the server side, the client (WL) could cache the transformed metric on disk making WL faster since the client won't be transforming the raw data during each run. Hmm. Is this the intended goal?
@superticker makes a good point. It's really a matter of applying a transforming indicator to FRED. With IndOnInd, getting Change and Percent Change can be accomplished with simply Momentum and ROC of the FRED indicator while TimeSeries.Log/LogReturn should do the natural log part.
QUOTE:
With IndOnInd, getting Change and Percent Change can be accomplished with simply Momentum and ROC of the FRED indicator
This works for daily FRED series only. Most of the (probably) valuable FRED series are weekly, biweekly or monthly. The weekly series have different grids (start of week, end of week, etc).
The FRED Indicator turns all these series to an synchronized indicator series (daily in most cases). Applying ROC or Momentum on such a synchronized series makes not much sense.
That is why I posted this #FeatureRequest. The data should be transformed by FRED (for example to Weekly Changes) then synchronized by the FRED Indicator to a daily series. Such a series is then useful, for example as an entry filter in a trading strategy.
So Reply# 5 is saying FRED data is weekly/monthly based, but our strategy is daily based. Therefore, perform the normalization (or transformation) on the server side, then return (and cache) it on the client (WL) on a daily scale for daily processing. This makes computational sense to me because you're caching and processing everything on the same time scale--daily. It's the simplest (and fastest) solution. Thanks for the clarification.
@DrKoch: makes sense now.
On a related note: we will not use the FRED API because it would require every user to sign up and input their own API key.
QUOTE:
The FRED Indicator should use the FRED API request "fred/series/observations" and allow "units" as one of the indicator's parameters.
On a related note: we will not use the FRED API because it would require every user to sign up and input their own API key.
Made units selectable in DataExtensions B3.
Data transformation inside the FRED indicator is not in the cards.
Data transformation inside the FRED indicator is not in the cards.
Your Response
Post
Edit Post
Login is required