A method for generating a tick-by-tick collective bidding market information suitable for a securities trading system

Abstract

The present application relates to the technical field of securities trading system, and in particular to a kind of method for generating tick-by-tick collective bidding market information applicable to securities trading system, and the method steps are specifically as follows: order includes a buy order chain, a sell order chain, the two chains can be discretely across the entire orderable price interval, if the two chains have overlapping parts on the price interval, then virtual transaction market information can be generated, the overlapping price of the two chains and the order set covered by the equal overlapping amount are tracked and recorded by virtual transaction buy order chain and virtual transaction sell order chain respectively, the new scheme adds a virtual remaining transaction amount field inside each order structure, so that we can record the remaining transaction amount after virtual matching transaction of each order in real time.

Description

Technical Field

[0001] This invention relates to the field of securities trading system technology, specifically a method for generating tick-by-tick auction data for securities trading systems. Background Technology

[0002] According to the "Shanghai Stock Exchange Trading Rules (2018 Revision)," securities auction trading adopts two methods: call auction and continuous auction. Call auction refers to a bidding method in which buy and sell orders accepted within a specified time are matched all at once. Continuous auction refers to a bidding method in which buy and sell orders are matched one by one.

[0003] During the call auction, the principles for determining the transaction price are: 1. The price that can achieve the maximum transaction volume; 2. The price at which all buy orders above the price and all sell orders below the price are executed; 3. The price at which at least one side of the buyers or sellers at the same price is fully executed.

[0004] If two or more bid prices meet the above conditions, the bid price that results in the smallest unexecuted volume shall be the transaction price; if there are still two or more bid prices that result in the smallest unexecuted volume meeting the above conditions, the median price shall be the transaction price. All transactions in the call auction shall be executed at the same price.

[0005] During the opening call auction period from 9:15 to 9:25 and the closing call auction period from 14:57 to 15:00 each trading day, the real-time market information includes: security code, security abbreviation, previous closing price, virtual reference price for the call auction, virtual matched volume, and virtual unmatched volume.

[0006] Call auction is a method of securities trading, generally used to determine the opening and closing prices of a trading instrument for the day. During the call auction phase, the exchange needs to compile statistics on all received order submissions and cancellations to calculate a transaction price (called the virtual transaction price) and the number of transactions at that price (called the virtual transaction volume). This information is then disclosed to all market participants through market data. In the following text, we will collectively refer to "virtual transaction price, virtual transaction volume, virtual unexecuted buy orders, and virtual unexecuted sell orders" as call auction market data.

[0007] Because it requires statistical analysis of all orders submitted to the system, the cumulative number of orders during the call auction period for a single trading instrument can reach hundreds of thousands. The exchange cannot calculate the virtual transaction price and volume for each order individually, and therefore cannot disclose market information in a timely manner. This results in inefficient price discovery and affects the accuracy of investment decisions made by market participants. The root cause of these problems lies in the high complexity of the call auction algorithm in the Shanghai Stock Exchange's existing trading system, which fails to meet the requirement of disclosing market information for each order individually. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method for generating tick-by-tick auction data suitable for securities trading systems. The method is characterized by the following specific steps:

[0009] S1. An order consists of a buy order chain and a sell order chain. These two chains can discretely span the entire price range where orders can be placed. If the two chains overlap in the price range, virtual transaction quotes can be generated. The order set covered by the overlapping price and equal overlap amount of the two chains is tracked and recorded using the virtual transaction buy order chain and the virtual transaction sell order chain, respectively.

[0010] S2. Each time an order is inserted or deleted, it is necessary not only to maintain the buy order chain and sell order chain, but also to maintain the virtual transaction buy order chain and virtual transaction sell order chain based on whether the order is within the virtual transaction overlap range. Adding these two virtual transaction chains does not require the creation of additional data structures; it is only necessary to save the order pointer at the head of the chain, and add a field to each order to store the virtual remaining order quantity. The virtual remaining order quantity has the following relationship with the original order quantity and the virtual transaction quantity of the order: Original order quantity = Virtual remaining order quantity + Virtual transaction quantity.

[0011] S3. If a newly inserted order or a deleted order happens to be in the virtual transaction chain, perform shrink and expand operations on the order at the head of the chain to maintain the attributes of the two virtual transaction chains and ensure that the virtual transaction chain contains all the orders that will be executed by the virtual continuous bidding.

[0012] The present invention also has the following preferred technical solutions:

[0013] (1) The specific steps for inserting a new order in the method are as follows:

[0014] 1. When an order is inserted, we denote it as newOrder. We denote its buy / sell direction as leftSide, and the opposite direction of leftSide as oppoSide;

[0015] 2. Obtain the order with the best price in that direction based on oppoSide, denoted as oppoBest, which is either the highest-priced order inserted earliest or the lowest-priced order inserted earliest.

[0016] 3. Obtain the first order on the virtual transaction chain in this direction based on oppoSide, denoted as virtualWorst[oppoSide], and save it to the temporary pointer oppoBorder: oppoBorder = virtualWorst[oppoSide];

[0017] 4. Obtain the first order on the virtual transaction chain in this direction based on leftSide, denoted as virtualWorst[leftSide], and save it to a temporary pointer border: border = virtualWorst[leftSide];

[0018] 5. If the price of newOrder is lower than the price of oppoBorder, it means that the prices of the new order and the counterparty's order do not overlap, and no further processing is required. The logic for inserting the new order can be exited directly.

[0019] 5.1. If border is a null pointer, it means that this is the first time price overlap has occurred. Set border to point to newOrder, i.e., border = newOrder;

[0020] 5.2. If border is not a null pointer, it means that there is already a virtual transaction chain. Check the next adjacent order of newOrder on the order chain and record it as whether prevOrder is null. If prevOrder is not null and the virtual remaining order quantity of prevOrder is greater than 0, it means that there are no orders to be executed on the opponent's order chain, and the logic of inserting a new order is directly exited. If prevOrder points to the same order as border, it means that newOrder is the new best order in this direction, and border needs to be updated to point to newOrder, that is, border=newOrder.

[0021] 6. At this point, the order quantity of newOrder represents the unbalanced quantity that causes the two virtual transaction chains. Next, the unbalanced quantity will be reduced to 0 through shrink and extend operations. The shrink operation is called shrink, and the extend operation is called extend.

[0022] 6.1. If unBalanceQuantity equals 0, then directly exit the logic for inserting a new order;

[0023] 6.2. If oppoBorder is empty, or the price of border is different from the price of oppoBorder, execute a shrink call and assign the two return values ​​to the variables balance and border: balance, border = shrink(unBalanceQuantity, leftSide, border);

[0024] 6.2.1. Subtract the balance returned by shrink from unBalanceQuantity: unBalanceQuantity = unBalanceQuantity - balance, then jump back to 6.1 to continue execution;

[0025] 6.3. Execute an extend call once and assign the two return values ​​to the variables balance and oppoBorder: balance, oppoBorder = extend (unBalanceQuantity, oppoSide, oppoBorder);

[0026] 6.4. Subtract the balance returned by extend from unBalanceQuantity: unBalanceQuantity = unBalanceQuantity - balance, then jump back to 6.1 to continue execution.

[0027] (2) The logic of the shrink(unBalanceQuantity, side, border) function in the method:

[0028] 1. The original order quantity is Quantity, and the virtual remaining order quantity is VLQuantity. Calculate the virtual transaction volume generated by the order pointed to by the border using Quantity and VLQuantity in the border, denoted as filled: filled = border.Quantity - border.VLQuantity;

[0029] 2.1. If filled is greater than unbalanceQuantity, then set the balancing amount for this operation, denoted as balance, where balance = unbalanceQuantity.

[0030] 2.2. Otherwise, set the balance value for this operation to filled: balance = filled;

[0031] 3. Modify the border's virtual remaining trading volume to track its decrease in virtual trading volume:

[0032] border.VLQuantity = border.VLQuantity + balance;

[0033] 4. If the virtual remaining transaction volume VLQuantity of border is equal to border.Quantity at this time, set border to the next adjacent order in the order chain of border, and save border as the head of the latest virtual transaction chain of border, denoted as virtualWorst[side], virtualWorst[side] = border;

[0034] 5. Exit the shrink function and return two values: balance and border.

[0035] (3) The logic of the extend(unBalanceQuantity, side, border) function:

[0036] 1. Determine if a portion of the border order has already been virtually fulfilled (the virtual remaining order quantity of the order is less than the actual remaining order quantity of the order, border.VLQuantity), and save it to the boolean variable inVOrders: inVOrders = border.VLQuantity <border.LeftQuantity;

[0037] 2.1. If the virtual remaining order quantity of the border is greater than unBalanceQuantity, then set the balancing amount for this operation to balance = unBalanceQuantity:

[0038] 2.2. Otherwise, set balance = border.VLQuantity;

[0039] 3. Subtract the balance from border.VLQuantity: border.VLQuantity = border.VLQuantity – balance;

[0040] 4. Add the current balance amount to the total virtual transaction amount, denoted as virtualQuantity, where virtualQuantity = virtualQuantity + balance;

[0041] 5. If inVOrder is false, then save border as the head of the latest local virtual transaction chain, denoted as virtualWorst[side]: virtualWorst[side] = border;

[0042] 6. Set the border to point to the next adjacent order in the same order chain;

[0043] 7. Exit the extend function and return two values: balance and border.

[0044] (4) The specific method for deleting an order is as follows:

[0045] 1. When an order is deleted, record this order as oldOrder, its buy / sell direction as leftSide, and the opposite direction of leftSide as oppoSide;

[0046] 2. Obtain the first order on the virtual transaction chain in this direction based on oppoSide, denoted as virtualWorst[oppoSide], and save it to the temporary pointer oppoBorder: oppoBorder = virtualWorst[oppoSide];

[0047] 3. Obtain the first order on the virtual transaction chain in this direction based on leftSide (denoted as virtualWorst[leftSide]), and save it to a temporary pointer border: border = virtualWorst[leftSide];

[0048] 4. If the border is a null pointer, it means there are no orders on the virtual transaction chain. Directly delete the order from the order buying and selling chain and exit the "delete order" logic;

[0049] 5. If the VLQuantity of oldOrder is equal to the order quantity of oldOrder, it means that oldOrder has not generated a virtual transaction. The order is directly deleted from the order buying and selling chain and the "delete order" logic is exited.

[0050] 6. If border and oldOrder are equal, it means we are deleting the order at the head of the virtual transaction chain. At this time, we need to get the next order on the chain and save it to border and virtualWorst[leftSide].

[0051] 7. At this point, the virtual transaction volume of oldOrder represents the imbalance that causes the two virtual transaction chains, denoted as unBalanceQuantity. Next, the shrink and extend operations are used to reduce unBalanceQuantity to 0: unBalanceQuantity = oldOrder.LeftQuantity - oldOrder.VLQuantity;

[0052] 8. Include the decrease in virtual transaction volume caused by order deletion in the virtual transaction volume statistic: virtualQuantity = virtualQuantity – unBalanceQuantity;

[0053] 9.1. If unBalanceQuantity equals 0, then exit the "Delete Order" logic directly;

[0054] 9.2. If border is empty, or the price of oppoBorder is different from the price of border, execute a shrink call and assign the two return values ​​to the variables balance and oppoBorder: balance, oppoBorder = shrink(unBalanceQuantity, oppoSide, oppoBorder);

[0055] 9.2.1. Subtract the balance returned by shrink from unBalanceQuantity: unBalanceQuantity = unBalanceQuantity - balance, then jump back to 9.1 to continue execution;

[0056] 9.3. Execute an extend call once, and assign the two return values ​​to the variables balance and border: balance, border = extend (unBalanceQuantity, leftSide, border);

[0057] 9.4. Subtract the balance returned by extend from unBalanceQuantity: unBalanceQuantity = unBalanceQuantity - balance, then jump back to 9.1 to continue execution.

[0058] Compared with the prior art, the advantages of this invention are:

[0059] 1. The new solution adds a virtual remaining transaction volume field to the structure of each order, so that we can record the remaining transaction volume after each order is virtually matched and executed in real time;

[0060] 2. We transformed the simulated trading process into a real-time process of maintaining consistency between the virtual buy order volume and the virtual sell order volume;

[0061] 3. In each order insertion and deletion operation, the virtual transaction volume of the inserted or deleted order is the unbalanced quantity (the balance variable in the previous chapter). We only need to expand or shrink the virtualWorst pointer positions on the two chains of buy and sell orders to bring the virtual transaction volumes of buyers and sellers back to balance. This is an operation involving only a single order declaration quantity, i.e., an O(1) operation. This allows us to complete the entire process in tens of nanoseconds. Attached Figure Description

[0062] Figure 1 This is the order list during the call auction;

[0063] In the diagram: 1. Optimal buyer order price tier.

[0064] 2. Optimal buyer's order.

[0065] 3. Seller's order chain (head of the chain is Order2,1).

[0066] 4. Worst seller order price tier.

[0067] 5. The order volume of newly inserted buyer orders will be used as a balance value to balance the virtual transaction volume between buyers and sellers.

[0068] 6. After balancing the virtual transaction volume, it is expanded into the new order pointed to by virtualWorst[Sell].

[0069] 7. Order3, the order that virtualWorst[Buy] points to before and after order insertion.

[0070] 8. Order3, the order that virtualWorst[Sell] points to before the order is inserted.

[0071] 9. Worst buyer order price tier.

[0072] 10. Buyer's order chain.

[0073] 11. Optimal seller order.

[0074] 12. Optimal seller order price tier. Detailed Implementation

[0075] The present invention will be further described below with reference to the accompanying drawings. The structure and principle of the present invention are very clear to those skilled in the art. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0076] Based on the natural law that the essence of "call auction" is "virtual continuous auction" (law 1), in the process of designing the next generation of trading system, we have specially redesigned the call auction algorithm to achieve the goal of revealing the virtual reference price, virtual matching quantity and virtual unmatched quantity one by one in O(1) time complexity.

[0077] The order list during the call auction is as follows: Figure 1 As shown, for simplicity, we view orders as a buy order chain and a sell order chain; these two chains can discretely span the entire price range where orders can be placed. If the two chains overlap in the price range, virtual transaction quotes can be generated.

[0078] like Figure 1 As shown, the order sets covered by the overlapping prices and equal overlap amounts of the two chains can be tracked and recorded using virtual buy order chains and virtual sell order chains, respectively. According to Rule 1, we can derive the following properties from the two virtual transaction chains:

[0079] 1. On a single transaction chain, the sum of the transaction volume of all orders is equal to the sum of the transaction volume of all orders on another transaction chain.

[0080] 2. When a buy order is executed on the blockchain, the order at the top of the chain is the order with the lowest price and the latest insertion time. The virtual transaction volume of this order is not necessarily exactly equal to its order volume.

[0081] 3. When a buy order is executed on the blockchain, the order at the end of the chain is the order with the highest price and the earliest insertion time among the orders on the chain. If there are other orders on the chain, their virtual transaction volume will be exactly equal to their order volume.

[0082] 4. On the order transaction chain, the virtual transaction volume of all orders between the first and last orders on the chain must be exactly equal to their order volume.

[0083] 5. On the sell order execution chain, the order at the top of the chain is the order with the highest price and the latest insertion time among the orders on the chain. The virtual transaction volume of this order is not necessarily exactly equal to its order volume.

[0084] 6. When a sell order is executed on the blockchain, the order at the end of the chain is the order with the lowest price and the earliest insertion time among the orders on the chain. If there are other orders on the chain, their virtual transaction volume will be exactly equal to their order volume.

[0085] 7. On the sell order transaction chain, the virtual transaction volume of all orders between the first and last orders on the chain must be exactly equal to their order volume.

[0086] Each time an order is inserted or deleted, we need to maintain not only the buy order chain and sell order chain, but also the virtual transaction buy order chain and virtual transaction sell order chain, depending on whether the order is within the virtual transaction overlap range. Adding these two virtual transaction chains does not require building additional data structures; we only need to store the order pointer at the head of the chain (denoted as virtualWorst, the same pointer as the virtualWorst mentioned in the previous chapters), and add a field to each order to store the virtual remaining order quantity (denoted as VLQuantity). The following relationship exists between VLQuantity, the original order quantity (denoted as Quantity), the actual remaining order quantity (denoted as LeftQuantity), and the virtual transaction quantity (denoted as CumQuantity):

[0087] LeftQuantity = Quantity;

[0088] LeftQuantity =VLQuantity+CumQuantity.

[0089] If a newly inserted or deleted order happens to be in the virtual transaction chain, we can perform shrink and extend operations on the order at the head of the chain to maintain the above 7 attributes and ensure that the virtual transaction chain contains all the orders that will be executed by the virtual continuous bidding.

[0090] The following details the processing logic when inserting a new order in "Virtual Continuous Bidding":

[0091] 1. When an order is inserted, we denote it as newOrder. We denote its buy / sell direction as leftSide, and the opposite direction of leftSide as oppoSide.

[0092] 2. Obtain the order with the best price in that direction based on oppoSide (denoted as oppoBest), which is either the highest-priced order inserted earliest or the lowest-priced order inserted earliest.

[0093] 3. Obtain the first order on the virtual transaction chain in this direction (i.e., virtualWorst[oppoSide]) based on oppoSide, and save it to the temporary pointer oppoBorder: oppoBorder = virtualWorst[oppoSide].

[0094] 3. Obtain the first order of the virtual transaction chain in this direction (i.e., virtualWorst[leftSide]) based on leftSide, and save it to a temporary pointer border: border = virtualWorst[leftSide].

[0095] 4. If the price of newOrder is lower than the price of oppoBorder (i.e., the buying price is lower than the selling price, and the selling price is higher than the buying price), it means that the prices of the new order and the counterparty's order do not overlap. No further processing is required, and the logic of inserting a new order can be exited directly.

[0096] 5.1. If border is a null pointer, it means that price overlap is occurring for the first time. We will point border to newOrder, i.e., border=newOrder.

[0097] 5.2. If `border` is not a null pointer, it means there is already a virtual order chain. Check if the next adjacent order (denoted as `prevOrder`) of `newOrder` in the order chain is null. If `prevOrder` is not null and its virtual remaining order quantity is greater than 0, it means there are no more orders to be executed in the competitor's order chain, and the logic for inserting a new order is directly exited. If `prevOrder` points to the same order as `border`, it means that `newOrder` is the new best order in this direction, and `border` needs to be updated to point to `newOrder`, i.e., `border = newOrder`.

[0098] 6. At this point, the order quantity of newOrder represents the imbalance that caused the two virtual transaction chains, denoted as unBalanceQuantity. Next, we will use the shrink and extend operations to reduce unBalanceQuantity to 0.

[0099] 6.1. If unBalanceQuantity equals 0, then exit the logic of inserting a new order directly.

[0100] 6.2. If oppoBorder is empty, or the price of border is lower than the price of oppoBorder (i.e., the buying price is lower than the selling price, and the selling price is higher than the buying price), execute a shrink call and assign the two return values ​​to the variables balance and border: balance, border = shrink (unBalanceQuantity, leftSide, border).

[0101] 6.2.1. Subtract the balance returned by shrink from unBalanceQuantity: unBalanceQuantity = unBalanceQuantity - balance, then jump back to 6.1 to continue execution.

[0102] 6.3. Execute an extend call and assign the two return values ​​to the variables balance and oppoBorder: balance, oppoBorder = f1.extendBorder(unBalanceQuantity, oppoSide, oppoBorder).

[0103] 6.4. Subtract the balance returned by extend from unBalanceQuantity: unBalanceQuantity = unBalanceQuantity - balance, then jump back to 6.1 to continue execution.

[0104] The logic of the shrink(unBalanceQuantity, side, border) function:

[0105] 1. Calculate the virtual transaction volume (denoted as filled) of the order pointed to by the border using the Quantity and VLQuantity in the border: filled = border.Quantity - border.VLQuantity.

[0106] 2.1. If filled is greater than unBalanceQuantity, then set the balance (denoted as balance) of this operation to unBalanceQuantity: balance = unBalanceQuantity.

[0107] 2.2. Otherwise, set the balance for this operation to filled: balance = filled.

[0108] 3. Modify the virtual remaining transaction volume of the border and track its decrease in virtual transaction volume: border.VLQuantity = border.VLQuantity + balance.

[0109] 4. If the virtual remaining transaction volume VLQuantity of border is equal to border.Quantity at this time, we will point border to the next adjacent order in the order chain of border, and save border as the head of the latest virtual transaction chain (denoted as virtualWorst[side]): virtualWorst[side] = border.

[0110] 5. Exit the shrink function and return two values: balance and border.

[0111] The logic of the extend(unBalanceQuantity, side, border) function:

[0112] 1. Determine if a portion of the border order has already been virtually fulfilled, and save this information to the `inVOrders` variable: `inVOrders = border.VLQuantity` <border.LeftQuantity。

[0113] 2.1. If the virtual remaining order quantity of border (border.VLQuantity) is greater than unBalanceQuantity, then set the balance of this operation to equal unBalanceQuantity: balance = unBalanceQuantity.

[0114] 2.2. Otherwise, set balance to border.VLQuantity: balance = border.VLQuantity.

[0115] 3. Subtract the balance from border.VLQuantity. border.VLQuantity = border.VLQuantity – balance.

[0116] 4. Add the current balance amount to the total virtual transaction amount (denoted as virtualQuantity): virtualQuantity = virtualQuantity + balance.

[0117] 5. If inVOrder is false, then save border as the head of the latest local virtual transaction chain (denoted as virtualWorst[side]): virtualWorst[side] = border.

[0118] 6. Set the border to the next adjacent order in the same order chain.

[0119] 7. Exit the extend function and return two values: balance and border.

[0120] The logic for deleting orders in "virtual continuous bidding" is similar to that for insertion, as detailed below:

[0121] 1. When an order is deleted, we denote it as oldOrder. We denote its buy / sell direction as leftSide, and the opposite direction of leftSide as oppoSide.

[0122] 2. Obtain the first order on the virtual transaction chain in this direction (i.e., virtualWorst[oppoSide]) based on oppoSide, and save it to the temporary pointer oppoBorder: oppoBorder = virtualWorst[oppoSide].

[0123] 3. Obtain the first order of the virtual transaction chain in this direction (i.e., virtualWorst[leftSide]) based on leftSide, and save it to a temporary pointer border: border = virtualWorst[leftSide].

[0124] 4. If the border is a null pointer, it means there are no orders on the virtual transaction chain. Directly delete the order from the order buying and selling chain and exit the "delete order" logic.

[0125] 5. If the VLQuantity of oldOrder is equal to the order quantity of oldOrder, it means that oldOrder has not generated a virtual transaction. The order is directly deleted from the order buying and selling chain and the "delete order" logic is exited.

[0126] 6. If border and oldOrder are equal, it means we are deleting the order at the head of the virtual transaction chain. At this time, we need to get the next order on the chain and save it to border and virtualWorst[leftSide].

[0127] 7. At this point, the virtual transaction volume of oldOrder represents the imbalance that causes the two virtual transaction chains, denoted as unBalanceQuantity. Next, we will reduce unBalanceQuantity to 0 through shrink and extend operations: unBalanceQuantity = oldOrder.LeftQuantity - oldOrder.VLQuantity.

[0128] 8. Include the decrease in virtual transaction volume caused by order deletion in the virtual transaction volume statistic: virtualQuantity = virtualQuantity – unBalanceQuantity.

[0129] 9.1. If unBalanceQuantity equals 0, then exit the "Delete Order" logic directly.

[0130] 9.2. If `border` is empty, or the price of `oppoBorder` is lower than the price of `border` (i.e., the buying price is lower than the selling price, and the selling price is higher than the buying price), execute a `shrink` call and assign the two return values ​​to the variables `balance` and `oppoBorder`:

[0131] balance, oppoBorder = shrink (unBalanceQuantity, oppoSide, oppoBorder).

[0132] 9.2.1. Subtract the balance returned by shrink from unBalanceQuantity: nBalanceQuantity = unBalanceQuantity - balance, then jump back to 9.1 to continue execution.

[0133] 9.3. Execute an extend call and assign the two return values ​​to the variables balance and border: balance, border = extend (unBalanceQuantity, leftSide, border).

[0134] 9.4. Subtract the balance returned by extend from unBalanceQuantity: unBalanceQuantity = unBalanceQuantity - balance, then jump back to 9.1 to continue execution.

Claims

1. A securities trading system suitable for sequential call auctions, characterized in that... The method steps used by this system to perform are as follows: S1. An order consists of a buy order chain and a sell order chain. These two chains can discretely span the entire price range where orders can be placed. If the two chains overlap in the price range, virtual transaction quotes can be generated. The order set covered by the overlapping price and equal overlap amount of the two chains is tracked and recorded using the virtual transaction buy order chain and the virtual transaction sell order chain, respectively. S2. Each time an order is inserted or deleted, it is necessary to maintain not only the buy order chain and sell order chain, but also the virtual transaction buy order chain and virtual transaction sell order chain, depending on whether the order is within the virtual transaction overlap range. On the virtual transaction buy order chain, the order at the head of the chain is the order with the lowest price and the latest insertion time among the orders on the chain; on the virtual transaction sell order chain, the order at the head of the chain is the order with the highest price and the latest insertion time among the orders on the chain. Adding these two virtual transaction chains does not require the creation of additional data structures, only the pointer of the order at the head of the chain needs to be stored, and an additional field is added to each order to store the virtual remaining order quantity. The virtual remaining order quantity has the following relationship with the original order quantity and the virtual transaction quantity of the order: Original order quantity = Virtual remaining order quantity + Virtual transaction quantity. S3. If a newly inserted order or a deleted order happens to be in the virtual transaction chain, perform shrink and expand operations on the order at the head of the chain to maintain the attributes of the two virtual transaction chains and ensure that the virtual transaction chain contains all the orders that will be executed by the virtual continuous bidding.

Images