Some indicators are defined by infinite recursive formulas, hence their results differ depending on the bar we begin the computation at.

Consider this example: EMA indicator with a 5 days rolling window, fed with two slightly different inputs:

{25.000,24.875,24.781,24.594,24.5,24.625,25.219,27.25} -> {25.000,24.958,24.899,24.797,24.698,24.674,24.856,25.654}
{       24.875,24.781,24.594,24.5,24.625,25.219,27.25} -> {       24.875,24.844,24.760,24.674,24.657,24.845,25.646}

Please note how numbers change. To use the library in practice, we need a way to reproduce the same values of the indicator on the same bars, even if we add or remove some price history to/from the start of the input price data.

We propose a solution: to introduce an additional option, "seed", that would allow us to mock the result of the infinite recursive computation on the [absent] preceding data, or, in other words, to pass the initial value to the indicator, if needed.

isnan(seed) would express then our intention for the indicator to calculate the value by itselt, just the way it does now.

Other indicators subject to this issue include (but not limited to):

• adx
• atr
• bbands
• cmo
• decay
• trics
• di
• dm
• dpo
• dx
• edecay
• ema
• kama
• hma

What do you think about it?

/cc @HelloCreepy

See https://github.com/TulipCharts/tulipnode/pull/34

These formulas divide by ATR, which could be zero. Currently a divide-by-zero results in returning NaN. We should consider if this is appropriate or not.

Sources:

• Alexander Elder. Come Into My Trading Room, 2002, pp. 180-181. ISBN: 9780471225348
• J. Welles Wilder. New Concepts in Technical Trading Systems, 1978, pp. 21-23. ISBN: 9780894590276

1. True Range:

2. Average True Range:

3. Chandelier Exit, ce_high:

4. Chandelier Exit on short positions, ce_low:

Hi,

I'm trying to use the ti_macd() function. The initial parameters are: 12, 26, 9 I call the ti_macd_start() function as follows:

const double options[] = {
     (double)(fast_period)
    ,(double)(slow_period)
    ,(double)(signal_period)
};
std::size_t produced = ti_macd_start(options);

Now the produced var is equal 25. I have the std::vector<double> with size 26. Next, I allocate the std::vector<double>s for outputs and call the ti_macd() as follows:

std::vector<double> inarr = {...}; // 26 doubles with closed vals
const double *inputs[] = {&inarr[0]};

std::vector<double> macd_fast(produced);
std::vector<double> macd_slow(produced);
std::vector<double> macd_hist(produced);
double *outputs[] = {
     &macd_fast[0]
    ,&macd_slow[0]
    ,&macd_hist[0]
};
int ec = ti_macd(slow_period, inputs, options, outputs);
assert(!ec);

After that in the macd_fast and macd_slow vectors only first element is not null. However the macd_hist vector contains only zeros.

Ideas?

Regarding most of the rolling window indicators for example SMA,

Why isn't the previously calculated SMA Indicator used as an optimization similar to dynamic programming?

For e.g in SMA didn't we only need to exclude the oldest period value in average and include the latest period value to calculate one additional point in SMA ?

I see that most of the indicators are like this. Performance gain by this should be huge. Am i missing something ?

Currently, we build with a gnumake script. It causes a race condition at code generation stage. I don't think it worth it to waste time trying to come up with a fix; rather, I propose using a cmake script that causes a lot less problems.

Code generation happens at the configuration stage, i.e. when doing cmake ...

benchmark.c is currently unsupported.

A lot of ideas were borrowed from #27.

Indicator streams https://github.com/TulipCharts/tulipindicators/issues/57 Reference indicators https://github.com/TulipCharts/tulipindicators/issues/59

indicators.tcl now takes an extra parametr for each indicator. This option can be "ref" or "stream" or both. It'll generate code accordingly.

I used ATR as the first example. ATR is easy to make a reference for (call ti_tr, call ti_wilders) and it's easy (but not trivial) to make a streaming indicator for.

I updated smoke to check ref and stream if available.

I updated the Makefile to c99. It's a lot easier.

Is there a chance of getting the indicator "zigzag" supprted including deepth? The zigzag is quite important to filter out noice and for determent eliot waves, as well as to better find petterns like double bottom etc.

I read in issue #36 you saying "However, if an indicator includes data from the future, then you have a data leak. This is why I've never implemented the popular Zig-zag indicator", but I cannot understand why you say that zigzag is based on data from the future, as the completion of the last zigzagline should be just an option and not an fact. In adition if you have a look at the indicator on tradingview you will find another option "deepth" which in addion tells should prevent somehow to draw the zigzag line too early propertly wrong.

Hopefully you wil find the time to implement this

Regards

I've implemented the Arnaud Legoux Moving Average and added some test cases. I've tried to optimize it but I'm not an expert in C so please review the code.

I personally use the node bindings for tulip indicators and would like to use this specific indicator there. Created this pull request in case it's something you would like to add to the library, otherwise I will probably maintain a private fork of this repo + node bindings for my own use.

Notes:

• I could not get the TCL scripts to run so I did my best to add the indicator manually, but it's also added to the scripts so that it should (hopefully) be properly added if run by somone else
• Perhaps add a new error code for malloc errors.
• Perhaps I should use the buffer utility struct instead of allocating manually

Thanks for the cool library!

Hello,

Can you add StockRSI indicator : http://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:stochrsi

Or maybe i can use stoch and rsi to get it ?

thank you for this awesome library

First off thanks for this great library.

This is something I noticed when looking for the Quality Factor (%Q) indicator (Ref, page 5) and looking at the docs on Williams %R.

%Q is %R without the -100 multiplier. Maybe something to add to the docs. I would have submitted a PR but didn't know how for this.

When build with m1 MackBookPro ,I got a error!!!!

ar rcu libindicators.a indicators.h candles.h indicators.c candles.c indicators/abs.o indicators/acos.o indicators/ad.o indicators/add.o indicators/adosc.o indicators/adx.o indicators/adxr.o indicators/ao.o indicators/apo.o indicators/aroon.o indicators/aroonosc.o indicators/asin.o indicators/atan.o indicators/atr.o indicators/avgprice.o indicators/bbands.o indicators/bop.o indicators/cci.o indicators/ceil.o indicators/cmo.o indicators/cos.o indicators/cosh.o indicators/crossany.o indicators/crossover.o indicators/cvi.o indicators/decay.o indicators/dema.o indicators/di.o indicators/div.o indicators/dm.o indicators/dpo.o indicators/dx.o indicators/edecay.o indicators/ema.o indicators/emv.o indicators/exp.o indicators/fisher.o indicators/floor.o indicators/fosc.o indicators/hma.o indicators/kama.o indicators/kvo.o indicators/lag.o indicators/linreg.o indicators/linregintercept.o indicators/linregslope.o indicators/ln.o indicators/log10.o indicators/macd.o indicators/marketfi.o indicators/mass.o indicators/max.o indicators/md.o indicators/medprice.o indicators/mfi.o indicators/min.o indicators/mom.o indicators/msw.o indicators/mul.o indicators/natr.o indicators/nvi.o indicators/obv.o indicators/ppo.o indicators/psar.o indicators/pvi.o indicators/qstick.o indicators/roc.o indicators/rocr.o indicators/round.o indicators/rsi.o indicators/sin.o indicators/sinh.o indicators/sma.o indicators/sqrt.o indicators/stddev.o indicators/stderr.o indicators/stoch.o indicators/stochrsi.o indicators/sub.o indicators/sum.o indicators/tan.o indicators/tanh.o indicators/tema.o indicators/todeg.o indicators/torad.o indicators/tr.o indicators/trima.o indicators/trix.o indicators/trunc.o indicators/tsf.o indicators/typprice.o indicators/ultosc.o indicators/var.o indicators/vhf.o indicators/vidya.o indicators/volatility.o indicators/vosc.o indicators/vwma.o indicators/wad.o indicators/wcprice.o indicators/wilders.o indicators/willr.o indicators/wma.o indicators/zlema.o utils/buffer.o indicators.o candles.o
ranlib libindicators.a
gcc -c -Wall -Wextra -Wshadow -Wconversion -std=c99 -pedantic -O2 -g sample.c -o sample.o
gcc -Wall -Wextra -Wshadow -Wconversion -std=c99 -pedantic -O2 -g -o sample sample.o libindicators.a -lm
ld: warning: ignoring file libindicators.a, building for macOS-arm64 but attempting to link with file built for macOS-arm64
Undefined symbols for architecture arm64:
  "_ti_find_indicator", referenced from:
      _main in sample.o
  "_ti_indicators", referenced from:
      _main in sample.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sample] Error 1

Can you please consider adding default option values to indicator descriptors? I'm making a charting application where the user can add any indicators to the charts and now it's up to the user to set the initial options as the library cannot provide any sensible defaults. Many indicators have standard or customary options (for example 20 periods, 2 standard deviations for Bollinger bands) and even if they don't the library could provide safe defaults.

Anyway, thanks for making a great library!

Version 0.9.1 has been released. It did not quite get all the features from the 0.9 roadmap, so I'll list what did get done here.

• Interfaces were added for reference indicators. This gives a simple but slow way to calculate an indicator. It is intended for testing and to help expose bugs.

• A streaming indicator interface was added. This gives an option to update indicators one bar at a time. It's complicated to support, so most indicators won't support this.

• Candlestick pattern recognition was added. This should be considered beta, and the interface might change in the future. Documentation is coming soon.

• DX, ADX, ADXR no longer take close as in input.

• DX, ADX, ADXR avoid unnecessary NaNs.

• Fix outputs names for ADX and ADXR (previously was 'dx', now is 'adx' and 'adxr' respectively)

• Spaces and percent signs were removed from option names for some indicators.

• Many new indicators were added to a "beta" directory. These need more testing, documentation, and in some cases, still have serious memory bugs.

• The build process was changed up a bit. tiamalgamation.c will now be checked into the repo, and it's a very easy way to use this library. (i.e. it contains all of the code in one file).

There were a few other back end changes, a lot of clean up, and I hope this is the start of some good momentum going forward.

Hi @codeplea, I have checked your Stochastic RSI implementation and was wondering why it becomes negative (-0.54) at the end of your "Example Calculation"? From what I have read on Investopedia the Stochastic RSI ranges only between 0 and 1: https://www.investopedia.com/terms/s/stochrsi.asp

Your tests actually show the same by expecting 0.000 at the end:

https://github.com/TulipCharts/tulipindicators/blob/0bc8dfc46cfc89366bf8cef6dfad1fb6f81b3b7b/tests/untest.txt#L382-L384

So how come your website lists "-0.54"?

Polarized Fractal Efficiency (PFE) is a technical indicator that was developed by Hans Hannula to determine price efficiency over a user-defined period. This indicator fluctuates between -100 and +100, with 0 as the centerline. Securities with a PFE greater than zero are deemed to be trending up, while a reading of less than zero indicates the trend is down. Polarized Fractal Efficiency's signature characteristic is its use of fractal geometry in determining how efficiently a security's price is moving.

A description of the formula is available e.g. here https://www.investopedia.com/terms/p/pfe.asp