# Differences

This shows you the differences between two versions of the page.

Both sides previous revision Previous revision Next revision | Previous revision | ||

introduction [2019/05/04 17:14] a.leofreddi |
introduction [2019/05/09 16:39] (current) admin |
||
---|---|---|---|

Line 3: | Line 3: | ||

A lot of data comes in the form of time-series, and while usually they're easy to manipulate, the process can become tricky. Here TimEL comes to help! | A lot of data comes in the form of time-series, and while usually they're easy to manipulate, the process can become tricky. Here TimEL comes to help! | ||

- | Indeed TimEL is an excellent fit to solve various time-series problems, mainly the metering and billing ones (that's where it originates from). | + | Indeed TimEL is a good fit to solve various time-series problems, mainly the metering and billing ones (that's where it originates from). |

- | Now let's image an hypothetical scenario to see how TimEL could help. Let's say you're implementing a next killer web game where you get a point for each rescued kittens. Now you want to praise your most loyal players with an in game bonus based on the achieved score. | + | Now let's image an hypothetical scenario to see how TimEL could help. Let's say you're implementing a next killer web game where you get a point for each rescued kitten. Now you want to reward your most loyal players with an in game bonus based on the achieved score. |

- | More specifically, imagine that for each player session your backend system logs hourly the user session interval start-end and its relative score totalled during the session. | + | More specifically, imagine that for each player session your backend system logs hourly the user session length (rounded hourly) and the relative score totalled during the session. |

- | It might happen that sometimes a user session is still open, so in such a case the backend will emit a single entry covering more than hours when the session is complete. | + | It might happen that sometimes a user session is still open, so in such a case the backend will emit a single entry covering more than 1 hour when the session is complete. |

Now imagine we have two players, A and B, with the following scores: | Now imagine we have two players, A and B, with the following scores: | ||

Line 64: | Line 64: | ||

Now let's imagine that we want to compute the total score achieved by A and B together, every hour. | Now let's imagine that we want to compute the total score achieved by A and B together, every hour. | ||

- | What would be the score in between Monday 12:00 and Tuesday 00:00 ? Well, it would be only A's one, but we have to consider that he saved 36 kittens for the whole 2 hours period. | + | What would be the score in between 9:00 and 10:00 ? Well, it would be only A's one, but we have to consider that he saved 36 kittens for a 2 hours period. |

Without more data, we can assume that if he saved 36 kittens in 2 hours, he saved 18 each hour. So we can say that between 09:00 and 11:00, 18 kittens were saved. One hour later 38 kittens were saved (18 by A, and 20 by B)! | Without more data, we can assume that if he saved 36 kittens in 2 hours, he saved 18 each hour. So we can say that between 09:00 and 11:00, 18 kittens were saved. One hour later 38 kittens were saved (18 by A, and 20 by B)! | ||

- | Now let's compute the sum of the scores of A and B via TimEL: | + | And that's what TimEL will automatically do, because we feed it using an [[Integral]] variable. |

- | | + | |

- | | + | |

- | Note that k<sub>i</sub> is a constant value in the range [a<sub>i</sub>, b<sub>i+1</sub>) and that the interval duration depends on the sampling frequency of the discretization process, but TimEL does not make any assumption regarding the duration of intervals: both constant-duration and irregular intervals are accepted. | + | |

- | | + | |

- | The explicit reference to the interval underlying the validity of a value allows TimEL to clearly identify the undefined intervals - that is time intervals where the value is not available (or maybe just not available yet, for queue systems). | + | |

- | | + | |

- | This approach is suitable to express a number of various processes, as example: | + | |

- | | + | |

- | * The value of a stock quote for a given period; | + | |

- | * The consumption read by a meter reading for a given period; | + | |

- | * An average speed for the given interval for a given period. | + | |

- | | + | |

- | Below an example of TimEL code to evaluate A + B with the following values: | + | |

- | | + | |

- | <HTML> | + | |

- | <div id="container" style="min-width: 310px; height: 400px;"></div> | + | |

- | </HTML> | + | |

- | | + | |

- | <JS> | + | |

- | jQuery('#container').highcharts({ | + | |

- | // | + | |

- | title: { text: 'Evaluation example' }, | + | |

- | xAxis: { | + | |

- | categories: ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'Jan'] | + | |

- | }, | + | |

- | plotOptions: { | + | |

- | series: { | + | |

- | step: 'left' | + | |

- | } | + | |

- | }, | + | |

- | series: [{ | + | |

- | name: 'A', | + | |

- | data: [ | + | |

- | [0, 20], | + | |

- | [3, 60], | + | |

- | [9, 90], | + | |

- | [12, 90], | + | |

- | ] | + | |

- | }, { | + | |

- | name: 'B', | + | |

- | data: [ | + | |

- | [0, 100], | + | |

- | [6, 130], | + | |

- | [12, 130] | + | |

- | ] | + | |

- | }, { | + | |

- | name: 'A + B', | + | |

- | data: [ | + | |

- | [0, 120], | + | |

- | [3, 160], | + | |

- | [6, 190], | + | |

- | [9, 220], | + | |

- | [12, 220], | + | |

- | ] | + | |

- | }] | + | |

- | // | + | |

- | }); | + | |

- | </JS> | + | |

- | | + | |

- | As you can see, TimEL will split A in the interval [April, October) as B has a value change in July, keeping thus the highest granularity possible resampling the input when needed. | + | |

- | | + | |

- | Note that the resampling process behaves differently on the data type, for more information checkout [[Interpolation]]. | + | |

- | | + | |

- | TimEL's expressivity comes mainly form the ability of model time recurrent events with a number of specific aggregation functions. | + | |

- | | + | |

- | As the data type is very important since it affects the computation, multiple resample functions are available to support both rescale and data type conversion on the fly when needed. | + | |

- | | + | |

- | The following basic function are available: | + | |

- | | + | |

- | * [[Scalar]] | + | |

- | * [[Integral]] | + | |

- | * [[Average]] | + | |

- | | + | |

- | Each of these functions receive the value to resample as first argument, and can be used with an optional 2nd argument which is the temporal interval to which the resample should be applied. | + | |

- | | + | |

- | Note that the temporal interval may be a fixed (defined using the [[Interval]] function) or a recurring one (defined using the [[Every]] function). | + | |

- | | + | |

- | When no interval is provided, an aggregation function will produce a single output with the longest interval possible. | + | |

- | | + | |

- | Follows an example of the following function, evaluated in the interval 2015-01-01 to 2015-02-01 (we use the ISO format to avoid confusion): | + | |

- | | + | |

- | | + | |

- | | + | |

- | | + | |