Ticks of different duration in same TimeSeries

[martinklepsch]

I just noticed that you can add ticks of different durations to a TimeSeries. I wonder if there should be an assertion that this isn't done? (Similar to adding Ticks that are before the endTime of the TimeSeries.)

Or maybe there are practical use cases for when you want to add a minute Tick to a hourly TimeSeries or similar?

[nimo23]

There are (edge) cases where data providers could give you a (for example) "1-min-timeseries" with leaks . For example, if a timeseries consists of 200 ticks, getting from a data-provider where each tick should represent 1-min, then there are cases for leaks (e.g. the first tick has a duration of 4 min for any reason, and the rest of the ticks have a right duration of 15-min). Unfortunatley, ta4j calculates "series.getTimePeriod()" with the first tick (by "computeTimePeriod"). So it can give you a wrong "PT4M" instead of "PT1M". However, it would be bad to do a assertion, because then the whole timeseries could not be uses only because of a few "leaks".

[martinklepsch]

@nimo23 hey, good points but isn't it job of the end user to provide clean data? Is there any utility in putting leaks into the timeseries?

[nimo23]

The end user cannot guarantee that all ticks coming from 3 party fullfills the requirement of ta4j. Leaks can occur and ta4j should not stop to work if only one tick or so of 200 is in a other period..Putting assertion in timeseries limits the flexibility..

[nimo23]

What ta4j can provide is to make these "leaks" visible by a new method for example,

public Map<Period, List<Tick>> checkTicks(TimeSeries s)

which returns all Ticks with another period and then the end user can then make the decision what to do with the whole timeseries..

[martinklepsch]

The end user cannot guarantee that all ticks coming from 3 party fullfills the requirement of ta4j. Leaks can occur and ta4j should not stop to work if only one tick or so of 200 is in a other period..Putting assertion in timeseries limits the flexibility..

If I have a tick that is four days instead of one that will also have about 4 times the value of other ticks. This can break strategies, cause false signals etc. IMO a library like this should be on the safe side rather than being on the flexible side.

[ElMoe]

It’s not easy to implement some kind of filtering of ticks that you want. You have to calculate the dominant frequency of all the old ticks and then check if the recent tick and the tick before comply to that dominant frequency. If not, you have to exclude the recent tick from the tick set or interpolate a new one or take the last good one twice. I have implemented a frequency calculation. You can have look at: https://github.com/ElMoe/Lib_ConvertTimeSeriesObjects <https://github.com/ElMoe/Lib_ConvertTimeSeriesObjects> The methods are: public double FindDominantFrequency(…) But as you see: it’s not that simple and due to the complexity I think that it should not be part of the core library. Regards, B.

…

Am 27.08.2017 um 18:05 schrieb Martin Klepsch ***@***.***>: The end user cannot guarantee that all ticks coming from 3 party fullfills the requirement of ta4j. Leaks can occur and ta4j should not stop to work if only one tick or so of 200 is in a other period..Putting assertion in timeseries limits the flexibility.. If I have a tick that is 4 days instead of one that will also have about 4 times the value of other ticks. This can break strategies, cause false signals etc. IMO a library like this should be on the safe side rather than being on the flexible side. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#180 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APJHtKHHcnViEvbVWEOf67_WOaS3dXa3ks5scZPcgaJpZM4PCu2Y>.

[martinklepsch]

@ElMoe Instead of calculating the dominant tick-size I think the better/simpler approach might be to allow setting a field on the TimeSeries object that contains a duration against which all ticks are validated.

[nimo23]

If validate, then let the end user decide by using a property. There are cases where timeseries has such leaks and "it should not stop the system" only because of one tick of 200 fails while running each tick.

[mdeverdelhan]

Instead of calculating the dominant tick-size I think the better/simpler approach might be to allow setting a field on the TimeSeries object that contains a duration against which all ticks are validated.

@martinklepsch OK for that. But with just a warning log message. I don't want to add a property or blocking the system just for that.

By the way, from my experience, time management is always painful. So the less we accept to manage it the better it is.

[TheCookieLab]

Perhaps I'm missing something, but if the data provider explicitly denotes tick-size (in addition to OHLC + V) and it has potential to be wrong, why not just check for it before instantiating a ta4j Tick?

[ElMoe]

When you take e.g. EndOfDay ticks then you have tick size of 24h but a natural gap on weekends and holidays. So having a weekend and getting the next tick on Monday means you have 48h hours of gap. A tick size of 24h would indicate then that the Monday tick is wrong.

…

Am 09.09.2017 um 16:00 schrieb TheCookieLab ***@***.***>: Perhaps I'm missing something, but if the data provider explicitly denotes tick-size (in addition to OHLC + V) and it has potential to be wrong, why not just check for it before instantiating a ta4j Tick? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#180 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APJHtAXk1ADS8pA7sUPDEGy0YVGbqLi2ks5sgpoHgaJpZM4PCu2Y>.

[dpalic]

I am not sure how to go on with this discussion.
This repository was dropped See #192
If this issue is still in clearance, could you please do me a favour and repost your question there? https://github.com/ta4j/ta4j
After reposting, could you close this issue here?

[mdeverdelhan]

To be continued on the new repo: https://github.com/ta4j/ta4j/issues