ADL® Documentation
- Fundamental Concepts
- ADL Learning Guide
- Basic Blocks
- Trading Blocks
- Discrete Blocks
-
Miscellaneous Blocks
- Round Block
- Display To Decimal Block
- Formula Block
- Average Block
- Stopwatch Block
- Clock Block
- Note Block
- Random Number Block
- Pause Block
- Log Block
- IsNumber Block
- Once True Always True Block
- Not Block
- Loop Block
- Exit Block
- Risk Block
- Workup State Block
- Alert Block
- Math Block
- Actor Blocks
- TT Analytics Block
-
Advanced Concepts
- Sniper Algo
- Order of Discrete Event Message Propagation
- Grouped Blocks and Library Functionality
- Rules Of Virtualization
- Jump Blocks
- Safety And Preventive Design With Visual Feedback
- Flip For Sell Orders Functionality
- Dynamic Data ExchangeLink
- Leave Orders On Pause Or Cancel
- Creating and Launching Order Ticket Algorithms (OTAs)
- Breakpoint Functionality
- Algorithm Behavior At Market Close and Disconnect
- Exporting Block Output Values
Continuous vs. Discrete Event Messages
During the execution of an automated strategy, ADL will continuously send and receive information from an exchange server. In ADL, every piece of information is characterized as either a Continuous Message or a Discrete Event Message.
Recommended
Tutorials For This Section
For a tactile learning experience, please try the following tutorials:
- Continuous vs. Discrete Events
- Getting Information About a Fill
- Using Discrete Events for Timing Precision
- Using Discrete Events to Trigger Downstream Actions
- Routing Discrete Event Messages in a Specific Order
- Enhancing Your Scalper Algorithm
Continuous Messages
- Continuous Messages: Information that is continuously disseminated by an exchange. For instance, the bid quantity available at a specific price level is considered to be a Continuous Message since this information is essentially a continuous stream of data available at all times.
- Continuous Messages
from an exchange are channeled into an algorithm through few designated
blocks such as the Instrument Attribute Block. Other downstream
blocks may use these channeled Continuous Messages to produce continuous
outputs of their own. Such continuous outputs flow through an algorithm
via Numeric, True/False, Instrument or Variable ports.
Example: The Instrument Attribute Block channels a stream of continuous data from an exchange
Discrete Event Messages
- Discrete Event Messages: Information disseminated from or submitted to an exchange upon occurrences of market events that happen at a single moment in time (denoted as Discrete Events). For instance, a Fill Confirmation message from an exchange server is considered to be a discrete event message since this information is a pulse of data disseminated only at the moment of an order execution.
- The following market events are considered to occur at a single moment in time: Fill Confirmation, Order Add Request/Confirmation, Order Modify Request/Confirmation, and Order Delete Request/Confirmation
- Several designated
blocks, such as the Order Block, may exchange discrete event messages
directly with an exchange. When a block submits or receives a discrete
event message, it will distribute a copy of the message throughout
the rest of the algorithm in the form a single pulse. A discrete
event message may flow through an algorithm via discrete event message
ports.
Example: The Order Block is one of several designated blocks in ADL which can submit and receive discrete event messages from an exchange server
- Several blocks which do not interact directly with an exchange can also send a pulse of discrete event message throughout an algorithm at user-defined moments. However, since such discrete event messages are not associated with any real requests or confirmations, these messages are void of information and merely provide the function of triggering downstream blocks to perform an action at user-defined moments (e.g., resetting a block's continuous output values).
Using Discrete Event Messages For Timing Precision
Discrete event messages have a key characteristic: when a block outputs a pulse of discrete event message, an algorithm temporarily stops channeling continuous messages from the exchange servers. Continuous message channels will remain closed while the pulse of discrete event message propagates throughout the algorithm. In effect, this behavior will "freeze" the output of blocks such as the Instrument Field Block which channels streaming market data. In this static state, the pulse of discrete event message will traverse the pathway designed by the user, updating the output values of the blocks which lie in its path. Once this propagation is complete, the algorithm will resume channeling continuous messages from all exchange servers.
Note that such propagation takes place within microseconds and will not be perceivable in practice. With this mechanism, however, ADL allows the user to capture and use the market data existing precisely at the moment of a discrete event.
The following is a simplified illustration of this mechanism in effect:
1. The diagram below shows an example of an Instrument Field Block (yellow block on the left) channeling a continuous numeric value into the Order Block (blue block on the right). The Instrument Field Block channels the best bid price of an instrument specified by the user, and the Order Block uses this streaming data to quote buy orders at the best bid price for the specified instrument with the specified quantity (instrument and quantity inputs are not shown in the illustration).
2. When one or more of the quoted orders are executed, the Order Block receives a Fill Confirmation message from the exchange server and outputs a discrete event message in the form of a single pulse. At this time, the algorithm stops channeling continuous messages from the exchange server. The pulse of discrete event message propagates through the algorithm, following the pathway designed by the user. It updates the output values of the blocks which lie in its path.
3. Once the propagation is complete, the algorithm resumes channeling continuous messages from the exchange server.
View: Application In A Spreader Strategy
Application In A Spreader Strategy
To see why this characteristic is essential for the sound execution of an algorithm, consider the following example:
- Suppose that a spreader
algorithm is designed to buy a 1:1 spread consisting of two legs:
ZS Mar 11 (the "quote leg") and ZS May 11 (the "hedge leg"). Specifically,
the algorithm is designed to quote a bid at the appropriate price
for ZS Mar 11, leaning on the best bid price of ZS May 11.
Example: ZS Mar11 - ZS May11 Spreader Algorithm
- Suppose that the quoted
bid for ZS Mar 11 is executed. However, one microsecond following
the fill, the best bid price of ZS May 11 (the lean price) changes
before the algorithm can submit the corresponding hedge order.
Example: Hedge Leg lean price changes following the fill
- In this case, it would
be undesirable for the algorithm to submit a hedge order at the
new best bid price of ZS May 11. However, by designing a block within
the algorithm to generate and output a discrete event message upon
the order execution in ZS Mar 11, the correct hedge price can be
captured at the precise moment of the quote leg fill. To be specific,
the algorithm will stop channeling continuous messages from the
exchange server at the exact moment of the quote leg fill, thereby
ignoring the change in the best bid price of ZS May 11 which occurred
one microsecond after the fill.
Example: Capturing the correct Hedge Price