nimo23

I will remove this PR after https://github.com/ta4j/ta4j/pull/1085 is merged.

>Not that you would do something like that but the fact that the design allows it could lead to issues and/or misunderstanding of intended usage . Please describe those issues...

> I agree in principle. Indicators shouldn't be able to mutate the BarSeries when calculating values I also agree. However, there may actually be other classes (like `BarSeriesUtil` or custom/user...

Would it make sense to just remove the cache from the project **entirely**? Why caching when most users never actually use the cache because: - For backtesting: They only calculate...

Yes, we also need it for its child `RecursiveCachedIndicator`..

>I would prefer to have a cache in the default mode and adding the possiblity to disable the cache. **After considering the importance of the caching in ta4j, I have...

>Yes, independently of the cache fix or enhancement we need to eliminate all usages of instance variables that store context information that depend on an index I think before providing...

>if we want to solve these issues, we should think about complete new concepts instead of enhancing the api that is meant to be used only for backtesting. This issue...

I think, the best points which justifies the need of Num abstraction layers are: - https://github.com/ta4j/ta4j/issues/113#issuecomment-348716609 - https://github.com/ta4j/ta4j/issues/113#issuecomment-349457768 However, if so, then why should we use a `Num` abstraction layer...

**After thinking about it, I come actually to the following conclusions:** 1) It would be better to remove `Num`from taj4 completely and only use `Double`. 2) To eliminate the drawbacks...