WO2023183990A1

WO2023183990A1 - System and method for measuring outcomes from events

Info

Publication number: WO2023183990A1
Application number: PCT/AU2023/050254
Authority: WO
Inventors: Steven James Gray
Original assignee: ZeroFlucs Labs Pty Ltd
Priority date: 2022-03-31
Filing date: 2023-03-31
Publication date: 2023-10-05

Abstract

A system and method for measuring an outcome from events. The method includes receiving an input expression defining one or more outcomes to be measured, converting the input expression to a plurality of tokens, applying a set of rules to the plurality of tokens form a plurality of nodes, wherein a rule from the set of rules is individually applied to a group of tokens of the plurality of tokens form a node of the plurality of nodes, encoding the plurality of nodes in an abstract syntax tree, receiving and processing an input transcript through the abstract syntax tree, the input transcript comprising one or more events, and calculating a result for each outcome of the one or more outcomes to be measured when assessed against each event of the input transcript.

Description

SYSTEM AND METHOD FOR MEASURING OUTCOMES FROM EVENTS

TECHNICAL FIELD

[1] The present invention relates to a system and method for measuring and determining outcomes occurring from one or more events.

BACKGROUND

[2] Any references to methods, apparatus or documents of the prior art are not to be taken as constituting any evidence or admission that they formed, or form part of the common general knowledge.

[3] Sports bookmaking often involves the acceptance of bets of a “same game” or “same race” nature (also commonly known as a multi bet), where multiples outcomes can be combined into a single bet. For example, in a Team A versus Team B scenario, the bet may include three outcomes: 1 ) Team A to win; 2) Total goals scored is greater than 2.5; and 3) Player X from Team B scores at any time in the first half.

[4] As the above outcomes in the example are correlated, this requires specific mathematical techniques in order to be correctly priced based on the statistical probabilities of the outcomes. One solution used to correctly calculate the statistical probabilities of the outcomes is through a simulation based approach where prices are determined by the probabilities of all chosen outcomes occurring in each simulation.

[5] While a simulation based approach allows for capturing of the subtleties of random distributions and variances, in order to obtain the best results, a large number of simulations are required.

[6] When defining the “outcome to measure”, regardless of use context, the contemporary standard is to write specific code for each type of scenario being measured for an occurrence or non-occurrence.

SUMMARY OF INVENTION

[7] In an aspect, the invention provides a method for measuring an outcome from events, the method including the steps of: receiving an input expression defining one or more outcomes to be measured; converting the input expression to a plurality of tokens; applying a set of rules to the plurality of tokens to form a plurality of nodes, wherein a rule from the set of rules is individually applied to a group of tokens of the plurality of tokens to form a node of the plurality of nodes; encoding the plurality of nodes in an abstract syntax tree; receiving and processing an input transcript through the abstract syntax tree, the input transcript comprising one or more events; and calculating a result for each outcome of the one or more outcomes to be measured when the abstract syntax tree is assessed against each event of the input transcript.

[8] In another aspect, the invention provides a method for measuring an outcome from events, the method including the steps of: receiving an input expression defining one or more outcomes to be measured; converting the input expression to a plurality of tokens; applying a set of rules to the plurality of tokens to form a plurality of nodes, wherein a rule from the set of rules is individually applied to a group of tokens of the plurality of tokens to form a node of the plurality of nodes; encoding the plurality of nodes in an abstract syntax tree; generating an executable runtime tree from the abstract syntax tree; optimising the executable runtime tree; receiving an input transcript defining one or more events to be assessed against the executable runtime tree; and calculating a result for each outcome of the one or more outcomes to be measured when assessed against each event of the input transcript by assessing the input transcript against the optimised executable runtime tree.

[9] In another aspect, the invention provides a system for measuring an outcome from events, the system comprising: a lexical analyser that receives an input expression defining one or more outcomes to be measured and generates a plurality of tokens from the input expression; a parser that receives the plurality of tokens and the parser: applies a set of rules to the plurality of token to form a plurality of nodes, wherein a rule from the set of rules is individually applied to a group of tokens of the plurality of tokens to form a node of the plurality of nodes; and encodes the plurality of nodes in an abstract syntax tree; a planner that receives the abstract syntax tree and generates an executable runtime tree from the abstract syntax tree; an optimiser that receives the executable runtime tree and optimises the executable runtime tree; and a runtime environment that receives the optimised executable runtime tree and an input transcript defining one or more events to be assessed, the runtime environment assessing the input transcript against the optimised executable runtime tree to calculate a result for each outcome of the one or more outcomes to be measured when assessed against each event of the input transcript.

[10] Preferably, the method further comprises the step of executing the executable runtime tree in a runtime environment. Preferably, the executable runtime tree is an executable execution plan.

[11] Preferably, the input transcript comprises one or more events over a window of time (such as a sports match, for example).

[12] Preferably, the optimiser applies transformations to the execution plan to restructure, remove or replace elements of the execution plan. Preferably, the optimiser calculates inferences and optimisations across single queries and batches of queries of the execution plan.

[13] Preferably, the system further comprises a plan cache having cached execution plans generated by the planner and/or the optimiser. Preferably, at least one of the cached execution plans comprises an optimised execution plan generated by the optimiser.

[14] Preferably, the plan cache provides is in communication with the planner and/or the optimiser and provides cached execution plans to the planner and/or the optimiser.

[15] Preferably, the result is a binary result. Alternatively, or additionally, the result is a numerical result.

[16] Preferably, the system further comprises a bitmap generator.

[17] Preferably, the system via the runtime environment or method generates a plurality of sets of results, each set of results of the plurality of sets of results comprising a plurality of results for an outcome to be measured.

[18] Preferably, the bitmap generator receives the plurality of sets of results and generates a single outcome bitmap for each of the sets of results. Preferably, the bitmap generator logically ANDs each of the single outcome bitmaps to generate a multi-outcome bitmap.

[19] In another aspect, the invention provides a method for measuring an outcome from events, the method including the steps of: receiving an input expression defining one or more outcomes to be measured; converting the input expression into a machine readable model-representation of a sequence of outcomes; converting the machine readable model representation into an execution plan in an executable format; optimising the execution plan; receiving an input transcript defining one or more events to be assessed; and calculating a result for each outcome of the one or more outcomes to be measured when assessed against each event of the input transcript.

[20] Preferably, the execution plan is optimised by applying transformations to the execution plan to restructure, remove or replace elements of the execution plan.

BRIEF DESCRIPTION OF THE DRAWINGS

[21] Preferred features, embodiments and variations of the invention may be discerned from the following Detailed Description which provides sufficient information for those skilled in the art to perform the invention. The Detailed Description is not to be regarded as limiting the scope of the preceding Summary of the Invention in any way. The Detailed Description will make reference to a number of drawings as follows:

Figure 1 is a schematic overview of an embodiment of a system for measuring outcomes within an event;

Figure 2 is an example of an input expression for the system of Figure 1 ;

Figure 3 is a schematic overview of another embodiment of a system for measuring outcomes within an event;

Figure 4 illustrates a flow diagram for an execution plan of the system;

Figure 5 illustrates an example of a multi-outcome bitmap generated by the system for determining the probability of multiple outcomes all occurring during a single event.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS [22] Embodiments of the invention provide a system and method for measuring outcomes in one or more events. The system provides for analysis of event transcripts and game flow information to reduce the need for scenario-specific code defining each possible outcome in a range of scenarios.

[23] Figures 1 to 2 illustrate a first embodiment of a system 100 and method for measuring outcomes from events and predicting an outcome through analysis of event transcriptions.

[24] The system 100 receives an input expression 101 in the form of an expression language which is processed and optimised to form a plan (described later) which can be executed in a runtime environment to determine outcomes from events defined in an input transcript 105. At its most basic, the input expression 101 must define at least one condition to evaluate or sequence of events to measure.

[25] An example of the expression language syntax can be seen in Figure 2, where the input expression 101 includes three component functions: 1 ) a Predicate function 102; 2) a Stop function 103; and 3) a Scope function 104.

[26] The Predicate function 102 defines a condition to evaluate or a sequence of events to measure (in this example, a goal scored by Team A or Player 1 ) within the input transcript 105.

[27] The Stop function 103, which is optional, defines a condition, which if satisfied, ceases additional processing. The Stop function 103 can be omitted to allow the entirety of the input transcript 105 to be processed until exhausted or finished.

[28] The Scope function 104 defines a specification that limits the stream of events considered from the input transcript 105 to specific portions of the game (or scenario on the input transcript, more generally), or to specific team or player related events. The Scope function 104 can also be omitted to allow the entirety of the events within the input transcript 105 to be processed/considered.

[29] It will be appreciated that the structure and phraseology of the language within the input expression is arbitrary and can be customised dependent on the specific domain that embodiments of the invention are applied to. For example, applications outside sports analysis may have different terms instead of “scoring”.

[30] The system 100 incudes a lexical analyser 110 which receives the input expression 101 . [31] The lexical analyser 110 is configured to convert the text representation of the input expression 101 into a stream of tokens 11 1 (token values). The token values represent granular elements of the expression language used to describe the outcomes being measured.

[32] The system 100 also includes a parser 120 which processes the tokens 111 and converts the tokens 111 into a machine readable model-representation of the sequence of outcomes specified in the input expression 101. This model can then ultimately be used to efficiently determine a “true”, “false,” or “indeterminate” result for whether a specific outcome occurs in the input transcript 105, which will become clear below.

[33] The parser 120 is configured to apply a series of rules to the stream of tokens 111 generated by the lexical analyser 1 10 and recursively defines the predicate, stop and scope of the input expression 101 , as well as any child language constructs. The parser 120 effectively records a sequence (or set) of rules that the parser 120 applies to the tokens 111 to recognise the input and ensures the stream of tokens 111 form a valid expression.

[34] The matching of each rule to a group of tokens from the tokens 111 converts the group of tokens into a node that form a part of an abstract syntax tree 121 described below.

[35] As mentioned above, the parser 120 outputs an abstract syntax tree 121 which provides a tree representation of the input expression 101 parsed by the parser 120 and the lexical analyser 110 in a structured, machine-readable format. Usefully, conversion between the input expression 101 and the abstract syntax tree 121 can be performed bidirectionally.

[36] The abstract syntax tree 121 is then passed from the parser 120 to an interpreter 120, along with an input transcript 105 defining a set of events (105a, 105b, 105C....105n) that occur over a window of time (such as in a specific scenario, game, sporting match, or the like, for example).

[37] The interpreter 130 is configured to evaluate an ad-hoc expression without a planning and optimisation phase. In use, the interpreter 130 processes the entire set of events in the input transcript 105 as a whole by assessing each of the nodes of the abstract syntax tree 121 algorithmically and calculating a result 131 (e.g. “true” or “false”) for whether a specific outcome to be measured defined in the input expression 101 occurs in the input transcript 105. [38] The interpreter 130 then combines these results 131 hierarchically and provided as an output.

[39] Figure 3 illustrates a second embodiment of a system 200 and method for measuring outcomes from events and predicting an outcome through analysis of event transcriptions.

[40] The operation of the system 200, generally, includes receiving an input in the form of an input expression 101 representing an outcome (or multiple outcomes) to be measured for a sport event (X) which is passed through a lexical analyzer 110, to convert the expression into a stream of tokens 11 1.

[41] The stream of tokens 111 is assembled by a parser 120 into an abstract syntax tree 121 , representing the expression (AST^X). The abstract syntax tree 121 is processed by the planner 230, converting the abstract syntax tree 121 to an algorithmically selected strategy (an execution plan 231 ) for evaluating an arbitrary transcript (the input transcript 105).

[42] The optimizer 240 reviews the execution plan 231 , identifying redundancies in constructs or duplicated effort, yielding a rewritten plan in the form of an optimized execution plan 241 .

[43] These optimized execution plans 241 are executed within a runtime environment 250 by flowing the stream of events 105a,... ,105n of the input transcript 105 within the sporting outcome (or other type of outcome to be evaluated) sequentially through the optimized execution plan 241 to calculate a result 251 (e.g. “true” or “false”) for whether a specific outcome to be measured defined in the input expression 101 occurs in the input transcript 105. The stream of events may include, as shown in the examples, game start, first half start, a goal by player 1 , a goal by player 2 and game end. It will be appreciated that the input transcript 105 can define any number and sequence of events to be analysed and assessed based on the requirements of the users.

[44] After each event 105a,... ,105n is considered, the plan state is checked to determine “Shall we continue”, as well as determining if an outcome is determinable.

[45] It will be appreciated that it is possible for many outcomes to be known early (for example, “To Score at Least 3 Goals” is known to be true if a 3^rd goal is measured, even if the sequence of events is only partially processed) which can be used to terminate analysis of the stream of events early to reduce the overall computing expense. That is, in a binary outcome situation (i.e. true or false), once an outcome has been deemed to have occurred, no subsequent event can be have an effect on the determination in relation to that outcome and therefore the execution plan can be eagerly terminated. This equally applies to individual elements within the execution plan. The system 200 may also a third result, an indeterminate result, where a result cannot be determined from the input transcript and input expression.

[46] Information about the mathematical bounds of algebraic expressions is propagated at execution time through the execution plan-tree, enabling rapid resolution of sequenced outcomes to be measured.

[47] System 200, in contrast to the system 100 described above, utilises a planner and an optimiser. While omitting the planner and the optimiser forsakes the high performance/scale-friendly aspects of the plan/execute approach, the Inventor envisions that embodiments of the invention omitting the planner and the optimizer can be used in testing and development, where a user wishes to view an indicative outcome.

[48] The system 200 will now be described in more detail.

[49] Similar to the system 100, the system 200 incudes a lexical analyser 110 which receives an input expression 101 in the form of an expression language, an example of which can be seen in Figure 2 and is explained above.

[50] The lexical analyser 110 converts the text representation of the input expression 101 into a stream of tokens (token values) which are in turn parsed by the parser 120 to form nodes that in turn form an abstract syntax tree 121 .

[51] As mentioned above, the system 200 includes an abstract syntax tree 121 which provides a tree representation of the input expression 101 parsed by the parser 120 and the lexical analyser 110 in a structured, machine-readable format. Usefully, conversion between the input expression 101 and the abstract syntax tree 121 can be performed bidirectionally.

[52] The abstract syntax tree 121 is then passed from the parser 120 to a planner 230.

[53] Next, at the planner 230, the model (i.e. the abstract syntax tree 121 ) formed from the input expression 101 is converted at run-time into an execution plan 231 in a machine-executable format.

[54] The execution plan 231 , as mentioned above, is another type of tree representation (distinct from the abstract syntax tree 121 ) of the input expression 101 to be computed which focuses on the processes that physically comprise the steps to answer a question (i.e. determine an outcome from an event).

[55] While the nodes of the execution plan 231 and the abstract syntax tree 121 generally align in terms of concepts to the members of the abstract syntax tree 121 , there can be divergences/differences between the two in accordance with optimizations, or where required to perform the underlying execution of a matching check. For example, using the AND() operator. In an abstract syntax tree 121 , the AND operator is an n-ary construct that can take an arbitrary number of inputs that are combined in a logical union (i.e. AND(x, y, z)). In the execution plan 231 , if there are more than two inputs, these are joined through nested ANDS (i.e. AND(AND(x, y)> z)).

[56] Nodes of the execution plan 231 used to handle scoping/filtering of inputs operate in one of two modes: 1 ) “Pull” - The root of the query uses a “pull” based approach to stream the in-scope events to the predicate for analysis; and 2) “Push” - Where a predicate has an additional sub-scope expression applied, this scope cannot be “pulled” but instead the results of the main scope are pushed down into the construct. This allows materializing of the filtered events into a new list that can be "pulled” from, which would consume CPU and memory, to be avoided.

[57] The system 200 also includes an optimiser 240 which receives the execution plan 231 from the planner 230 and optimises the execution plan 231 to form an optimised execution plan 241 .

[58] The optimiser 240 is configured to perform inferences and optimisations across two levels: 1 ) Single Query; and 2) Batch of Queries.

[59] When optimizing a single query, the optimizer 240 applies transformations to the execution plan to re-structure or remove elements, or replace them with surrogates that re-use values computed elsewhere. For example, if the same Summation/Accumulation instruction is used multiple times, it can be computed once and subsequently re-used.

[60] Across a batch of expressions, some elements that perform filtering/scoping of the data to process can be done once, and the filtered list re-shared amongst the execution of multiple other queries. For example, if three (3) queries all have a “SCOPE SEGMENTS(half_2)”, the list of events in the second half of a match are computed once, then distributed to all queries that require the data in parallel, instead of being computed thrice independently. [61] The objective of the optimiser 240 is to reduce the computing cost (e.g. time and resources utilised) to measure the occurrence, or non-occurrence, of the outcomes in the input transcript of an event (e.g. game, scenario, etc.) by removing redundant steps and/or avoiding repetitions of work.

[62] The system 200 also includes a plan cache 260 which is a repository of historical execution plans in the form of cached plans 261. In practice, the plan cache 260 takes the form of an LRU (Least Recently Used) cache, such that more frequently requested execution plans remain stored, whilst infrequently used execution plans gradually expire and are removed from the cache.

[63] The Inventor envisions that the expression text (i.e. the input expression 101 ) used is the key to performing lookups inside the plan cache 260. As execution plans 231 are trees of stateful objects, each cached plan 261 stored in the plan cache 260 is a “template”, which can then be cloned. The planner 230 or optimizer 240 (to be explained below) will store a copy of the final execution plan 231 in the plan cache 260 as a cached plan 261 , if the requested execution plan itself did not exist in the cache.

[64] Both the planner 230 and the optimizer 240 interact with the plan cache 260 described above to determine if a given input expression 101 has already been planned or optimised and is therefore already the subject of an execution plan 231 stored as a cached plan 261 . As planning takes significant computational resources and memory, the Inventor envisions that the use of the plan cache 260 allows for an execution plan 231 to be cached and later re-used, thus eliminating the planning phase and reducing the use of computational resources and saving time. When an execution plan 231 is re-used between input transcripts 105, the status of the nodes is “Reset” back to default values, such that the process can begin again without constructing a new execution plan per transcript.

[65] The optimised execution plan 241 or plans are then executed within a runtime environment 250 by flowing the stream of events 105a,... ,105n of the input transcript 105 within the sporting outcome (or other type of outcome to be evaluated) sequentially through the optimized execution plan 241. When processing events through the optimized execution plan 241 , the design of the runtime avoids allocation of memory at all costs, preferring to use a fixed nominal footprint. For example, a “COUNT” can be achieved through just maintaining a single datum, and incrementing that value. In an example shown in Figure 4, after the first input (event 105a), the counter is one but the comparison (>=) is unknown as the end of the input transcript 105 has not yet been reached. If it was signaled to the optimized execution plan 241 that the input transcript 105 had been exhausted, the outcome of the input expression 101 could be resolved as “false”, however it is presently unknown.

[66] As a second input, event 105b, from the input transcript 105 is added, the existing memory is re-used and thus no new memory allocations are incurred.

[67] As the “Count” operator projects minimum and maximum values, the system determines from the comparison that the “Count” can never be less than 2 and the other value (2) is a constant, whose bounds are known. Thus, the system can instantly resolve the outcome and stop processing immediately.

[68] The outputs from the system and method described above there can be an significant amount of data to be processed and interpreted. For example, for a soccer game on a weekend, there can be 50,000 transcripts with 100 events per transcript and 1000 outcomes. This equates to 5 million transcript events per match, each of which must be reviewed against the outcomes to produce a probability or price. Computationally, each probability request considers all of the data.

[69] While the systems and methods described above provide efficiencies and reduce the use of computing resources and time, the amount of data to be processed remains considerable and somewhat prohibitive. Furthermore, during this analysis, the entirety of the transcript data must remain available and in-memory. Unloading/reloading the data on demand would be impractical at scale.

[70] To address this problem, the Inventor has found that given a finite number of distinct betting propositions, it is possible to pre-compute bitmaps of the true/false outcomes for the input expressions.

[71] As a result, at 1 bit per transcript, the pre-computing of the bitmaps allows the complete set to be stored in under 7 kilobytes for a single expression.

[72] Advantageously, the performance of the solution overall permits rapid precalculation of these proposition as a one-off “analysis” phase of processing, after the generation of the transcript data. Further advantageously, the full transcripts do not need to be in-memory during analysis and processing.

[73] To compute the logical probability of a scenario including multiple propositions, a logical AND over the bitmaps can be performed which compares each position with the corresponding position in all other bitmaps. [74] In an example shown in Figure 5, a bitmap generator 140 has been used to generate three bitmaps 300, 301 , 302 using three input expressions and input transcripts using the results derived from the systems and methods described above. Each of the bitmaps 300, 301 , 302 represents the results from each input expression and input transcript with a T (for true -occurrence) or an F (for false - no occurrence) and a green or red background, respectively.

[75] To compute the resultant probability of the intersection of the three outcomes to be measured from each of the input expressions and input transcripts, each of the single outcome bitmaps 300, 301 , 302 are logically AND-ed. The resultant multioutcome bitmap 303 represents the probability of the multi-outcome situation. In the example, the resultant probability is 25%.

[76] Using the bitmap allows for multi-element yes/no outcomes to be determined through an intersection of the bitmaps for each individual outcome to be measured as defined by the input expression.

[77] It is envisioned that the precomputed bitmaps can be further optimized with compression, run-length-encoding or other schemes to lossless-ly reduce memory footprint whilst remaining rapidly able to be interrogated.

[78] With the above in mind, it will be appreciated that most operations can be executed hierarchically without allocating additional memory, regardless of processing dozens, hundreds or tens of millions of streaming incidences.

[79] The components of the systems 100 and 200 such as the flow planner lexical analyser 110, parser 120, and interpreter 130 are implemented on a computing device or computing system, or on more than one computing system, the one or more computing systems may be networked computing systems. An exemplary computing system includes a processor, a program memory, and a data port. The processor, the program memory and the data port are connected together via a bus. The program memory is a non-transitory compute readable medium, such as a hard drive, a solid state disk or CDROM. A set of computer-executable instructions, that is, an executable software program stored on the program memory causes the processor to perform the methods described herein.

[80] While embodiments of the invention described herein relate and are directed to the calculation of “True/False” for a specific outcome, embodiments of the invention can be used to generate answers to numerical inquiries directly. For example, what was the total score for Team A in the first half?

[81] Embodiments of the invention remove the need to write code to define each outcome, enabling code-free generation of probabilities for a diverse range of scenarios.

[82] Furthermore, embodiments of the invention eliminates the need to run thousands (and often tens of thousands) of simulations which saves time and CPU resources.

[83] In addition, embodiments of the invention handling large numbers of expressions, utilising a planner and optimiser allows for the identification of overlapping constructs which reduces the repetition of computations that achieve the same result.

[84] A particular use case for embodiments of the invention described herein lies in sports analysis technology. Sport analysis can be better achieved through eefficient encoding of the semantics of a possible outcome, without writing specific computer code to represent or evaluate the expression and the likelihood of that outcome occurring. Furthermore, embodiments of the invention can be used during a sporting event to determine a true/false outcome of the input expression. Embodiments of the invention can also be used prior to a sporting event, to describe a sequence of outcomes defined and measured by input expressions.

[85] Embodiments of the invention can also be used to enhance the viewing experience through derivation of information from the game flow which is presented as information content. For example, “Team X is the fastest to 15 points in the last 25 games”, or “Player Y has won 80 of the last 100 points”).

[86] While embodiments of the invention are described in relation to creating execution plans to analyse a sequence of events in a sporting match or tournament, it will be appreciated that embodiments of the invention can be readily applied to other disciplines, such as engineering, for example, in simulations and Monte Carlo (risk) analysis. It is envisioned that embodiments of the invention can be applied to any problem involving analysis of either a single transcript (e.g. an event in progress), or repeated analysis of multiple transcriptions (e.g. historical samples, or forward-looking simulation outputs).

Definitions [87] The phrase “sports event” as used herein refers to a match, game, race or tournament.

[88] The term “incident” as used herein refers to a specific event or occurrence within the chronology of an event. For example, the start of the second half of a match, or a goal scored by Player X from Team Y.

[89] The term “transcript” as used herein refers to a time-ordered chronology of incidents for a given event. This can be sourced from either a simulation that yields a representation sampling of likely events for an event that has yet to occur, or the state of an actual sports event that is either in progress or has taken place (i.e. took place in the past).

[90] In compliance with the statute, the invention has been described in language more or less specific to structural or methodical features. The term “comprises” and its variations, such as “comprising” and “comprised of” is used throughout in an inclusive sense and not to the exclusion of any additional features.

[91] It is to be understood that the invention is not limited to specific features shown or described since the means herein described comprises preferred forms of putting the invention into effect.

[92] The invention is, therefore, claimed in any of its forms or modifications within the proper scope of the appended claims appropriately interpreted by those skilled in the art.

Claims

1 . A system for measuring an outcome from events, the system comprising: a lexical analyser that receives an input expression defining one or more outcomes to be measured and generates a plurality of tokens from the input expression; a parser that receives the plurality of tokens and the parser: applies a set of rules to the plurality of token to form a plurality of nodes, wherein a rule from the set of rules is individually applied to a group of tokens of the plurality of tokens to form a node of the plurality of nodes; and encodes the plurality of nodes in an abstract syntax tree; a planner that receives the abstract syntax tree and generates an executable runtime tree from the abstract syntax tree; an optimiser that receives the executable runtime tree and optimises the executable runtime tree; and a runtime environment that receives the optimised executable runtime tree and an input transcript defining one or more events to be assessed, the runtime environment assessing the input transcript against the optimised executable runtime tree to calculate a result for each outcome of the one or more outcomes to be measured when assessed against each event of the input transcript.

2. The system of claim 1 , wherein the executable runtime tree is an executable execution plan.

3. The system of claim 1 or claim 2, wherein the input transcript comprises one or more events over a window of time.

4. The system of claim 2, wherein the optimiser applies transformations to the execution plan to restructure, remove or replace elements of the execution plan.

5. The system of claim 2 or claim 4, wherein the optimiser calculates inferences and optimisations across single queries and batches of queries of the execution plan.

6. The system of claim 2, wherein the system further comprises a plan cache having cached execution plans generated by the planner and/or the optimiser.

7. The system of claim 6, wherein at least one of the cached execution plans comprises an optimised execution plan generated by the optimiser.

8. The system of claim 6 or claim 7, wherein the plan cache provides is in communication with the planner and/or the optimiser and provides cached execution plans to the planner and/or the optimiser.

9. The system of any one of claims 1 to 8, wherein the result is a binary result.

10. The system of any one of claims 1 to 9, wherein the result is a numerical result.

11. The system of any one of claims 1 to 10, wherein the system further comprises a bitmap generator.

12. The system of claim 11 , wherein the runtime environment generates a plurality of sets of results, each set of results of the plurality of sets of results comprising a plurality of results for an outcome to be measured.

13. The system of claim 12, wherein the bitmap generator receives the plurality of sets of results and generates a single outcome bitmap for each of the sets of results.

14. The system of claim 13, wherein the bitmap generator logically ANDs each of the single outcome bitmaps to generate a multi-outcome bitmap.

15. A method for measuring an outcome from events, the method including: receiving an input expression defining one or more outcomes to be measured; converting the input expression to a plurality of tokens; applying a set of rules to the plurality of tokens form a plurality of nodes, wherein a rule from the set of rules is individually applied to a group of tokens of the plurality of tokens form a node of the plurality of nodes; encoding the plurality of nodes in an abstract syntax tree; receiving and processing an input transcript through the abstract syntax tree, the input transcript comprising one or more events; and calculating a result for each outcome of the one or more outcomes to be measured when the abstract syntax tree is assessed against each event of the input transcript.

16. The method of claim 15 including: generating an executable runtime tree from the abstract syntax tree; optimising the executable runtime tree; receiving the input transcript defining one or more events to be assessed against the executable runtime tree; and calculating the result for each outcome of the one or more outcomes to be measured when assessed against each event of the input transcript by assessing the input transcript against the optimised executable runtime tree.

17. The method according to claim 15 or claim 16, wherein the method further includes executing the executable runtime tree in a runtime environment.

18. A method for measuring an outcome from events, the method including the steps of: receiving an input expression defining one or more outcomes to be measured; converting the input expression into a machine readable model-representation of a sequence of outcomes; converting the machine readable model representation into an execution plan in an executable format; optimising the execution plan; receiving an input transcript defining one or more events to be assessed; and calculating a result for each outcome of the one or more outcomes to be measured when assessed against each event of the input transcript.