nimo23

I added `Position#getType()` to determine its `PositionType`. With this, even more code simplifications can be made in dedicated Criteria (for example, a future criteria which uses `positionType == PositionType.PROFIT ?...

>I think some Criteria are not really useful. For instance you do not need a NumberOfLosingPositionsCriteria, because it is the same as all positions minus number of winning positions I...

@GxtPerfectoM would be nice if you can make a PR with your suggestion.

See https://github.com/ta4j/ta4j/issues/522#issuecomment-601354192. See https://github.com/ta4j/ta4j/issues/103#issuecomment-347548043

>there are *so many easy fixes** that you or anyone could make to this library to clean up the array allocations its boggles my mind..**you are stuck with some very...

@johnthetireless This is just another example of where instead of addressing the issue, you're again distracting and being rude. Me and the community are here to help and spend time...

Also explained here https://github.com/uniVocity/univocity-trader/issues/7#issuecomment-687837498 and https://github.com/uniVocity/univocity-trader/issues/2#issuecomment-561460200

>re-use Indicator (expecially cacheindicator) in multiple threads Nothing stops you from putting those indicator values into a thread safe collection type and consume it from there by multiple threads. This...

>Using a nonblocking collection that work as a fifo, will give you the benefit of became threadsafe, remove all the computation overhead to keep track of removedIndex/startIndex/endIndex, and allow parallel...

@Solom00n Again, I see no reason to have synchronized indicator values or snychronized barSeries. Can you please share some broad use cases? However, I suggest, that you provide a PR...