Added indicator streams and reference indicators

[codeplea]

Indicator streams #57
Reference indicators #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.

[codeplea]

I'm open to suggestions on naming.

Also, I'm thinking that ti_xxx_stream_new() could return an error code if the options are bad (currently it just returns a null pointer).

Should ti_stream_run() ever return an error? Once the indicator is set up, what could go wrong?

[rdbuf]

It all looks good to me.

Yes, returning an error code is a good idea, we must be consistent.

In the code I've seen so far, all the testing for erroneous conditions was performed prior to any calculations, conceptually at the _new stage. Provided that we trust the input data (high >= low, e.g.), I can't think of any example of an error occurring during the computation. In either case, I don't think that we would like to test for anything inside of a streaming function, because it could potentially cause a noticeable performance hit.

[rdbuf]

Have you benchmarked it yet?

[rdbuf]

why not to return the pointer just like malloc does? we would still be able to check for errors, wouldn't we?

[codeplea]

We can only have one return value, so it's either:

int stream_new(TI_REAL const *options, ti_stream **stream);

or

ti_stream *stream_new(TI_REAL const *options, int *return_code);

I don't think either is better or worse, really. The normal functions return int, so I just did that for consistency.

[G8XSU]

I think returning "ti_stream" would have been a better choice, since that's the actual return type and that is what the client needs to pass again and again to compute streaming indicator. Its req. in get_info/ progress/ stream_run / stream_free.

[codeplea]

Have you benchmarked it yet?

I haven't benchmarked anything. I think the next step is to integrate this with the benchmark program.

Also, either expand benchmark or write a new program which runs random data and options and compares the old indicators to the reference indicators to the stream indicators. I'll leave that up to you, if you want to work on it.

Finally, it should be integrated into fuzzer too. It's going to be really easy to make memory errors with the streaming indicators. Running fuzzer with valgrind will be a great way to find those.

I can't think of any example of an error occurring during the computation.

I think it would be very uncommon, but we may as well keep the return value. Maybe it'll come in handy at some point. About the only thing I can imagine is if a really complicated indicator needs to do memory allocation and that fails.

The other failure cases should usually be handled by just returning NaNs.

[codeplea]

I changed smoke so that it test streaming indicators both 1 bar at a time and all the bars at once. The streaming code is complicated enough that I think it's import to make sure it goes something both ways.

[codeplea]

Merged to 0.9.

I won't have time to work on TI for a while. Feel free to build on it.

[rdbuf]

I will. Thanks for the work done!