# Differences

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

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

introduction [2016/02/26 23:39] a.leofreddi |
introduction [2019/05/09 16:39] admin |
||
---|---|---|---|

Line 1: | Line 1: | ||

- | ===== Introduction ===== | + | ====== Introduction ====== |

- | <PRELOAD> | + | 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! |

- | https://code.highcharts.com/highcharts.js | + | |

- | https://code.highcharts.com/modules/exporting.js | + | |

- | </PRELOAD> | + | |

- | The basic concept underlying TimEL design is that a given variable, let's say A, can be approximated over time with a finite number of measures (through a discretization process) and then defined as follows: | + | Indeed TimEL is a good fit to solve various time-series problems, mainly the metering and billing ones (that's where it originates from). |

- | <HTML> | + | 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. |

- | <p style="font-size: 140%; text-align: center"> | + | |

- | A = k<sub>i</sub> for t: t<sub>i</sub> ≤ t < t<sub>i + 1</sub>; | + | |

- | </p> | + | |

- | </HTML> | + | |

- | <HTML> | + | 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. |

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

- | </HTML> | + | |

- | <JS> | + | 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. |

- | var sin_high = Array(), sin_low = Array(), res = 1000.0; | + | |

- | | + | |

- | for (var i = 0; i <= res; i++) { | + | |

- | sin_high.push([i / res, Math.sin(2.0 * Math.PI * i / res)]); | + | |

- | } | + | |

- | res = 20.0; | + | Now imagine we have two players, A and B, with the following scores: |

- | | + | |

- | for (var i = 0; i <= res; i++) { | + | |

- | sin_low.push([i / res, Math.sin(2.0 * Math.PI * i / res)]); | + | |

- | } | + | |

- | jQuery('#discretization').highcharts({ | + | <HTML> |

- | // | + | <script src="https://code.highcharts.com/highcharts.js"></script> |

- | title: { text: 'Discretization process' }, | + | </HTML> |

- | plotOptions: { | + | |

- | series: { | + | |

- | step: 'center' | + | |

- | } | + | |

- | }, | + | |

- | series: [{ | + | |

- | name: 'Continuous', | + | |

- | data: sin_high | + | |

- | }, { | + | |

- | name: 'Discrete', | + | |

- | data: sin_low | + | |

- | }] | + | |

- | // | + | |

- | }); | + | |

- | </JS> | + | |

- | | + | |

- | 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> | <HTML> | ||

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

</HTML> | </HTML> | ||

<JS> | <JS> | ||

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

// | // | ||

- | title: { text: 'Evaluation example' }, | + | title: { text: 'Yesterday\'s player score' }, |

xAxis: { | xAxis: { | ||

- | categories: ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'Jan'] | + | categories: ['08:00', '09:00', '10:00', '11:00', '12:00', '13:00', '14:00', '15:00', '16:00', '17:00', '18:00'] |

}, | }, | ||

plotOptions: { | plotOptions: { | ||

Line 81: | Line 36: | ||

name: 'A', | name: 'A', | ||

data: [ | data: [ | ||

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

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

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

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

+ | [6, 0], | ||

+ | [7, 18], | ||

+ | [8, 0], | ||

] | ] | ||

}, { | }, { | ||

name: 'B', | name: 'B', | ||

data: [ | data: [ | ||

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

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

- | [12, 130] | + | [3, 0], |

- | ] | + | [5, 12], |

- | }, { | + | [6, 26], |

- | name: 'A + B', | + | [7, 0], |

- | data: [ | + | [8, 0], |

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

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

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

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

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

] | ] | ||

}] | }] | ||

Line 107: | Line 60: | ||

</JS> | </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. | + | At 9:00, player A started to play and stopped at 11, scoring 36 points - so your backend logged 36 points in between 9:00 and 11:00. Player B started one hour later, and played only for one hour (scoring 20 points). |

- | | + | |

- | 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): | + | |

+ | 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 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)! | ||

+ | And that's what TimEL will automatically do, because we feed it using an [[Integral]] variable. | ||