Process exchange prints, volume checks, and client orders

You are writing a broker program that interfaces with an exchange via a stream of commands on **stdin**. You must process commands in order and write required outputs to **stdout**. Timestamps are integers (seconds since market open) and are **non-decreasing** across all input lines. Security names and client names are unquoted strings with no spaces. All numeric values fit in 32-bit signed integers. ## Command types ### 1) Trade print (market trade) A line of the form: `print <timestamp> <security> <quantity> <price>` - `quantity` and `price` are positive integers. - This updates the **most recent trade price** for that security. ### 2) Volume check (query) A line of the form: `volume-check <timestamp> <security>` For each `volume-check`, output **one line** containing the **trailing-minute market volume** for that security at that timestamp. - Trailing-minute market volume = sum of `quantity` from all **market trade prints** (`print ...`) for that security with timestamps in the last 60 seconds ending at the query time. - Use the window: `t-60 < trade_timestamp <= t`. **Output format (Part 1):** `<volume>` ## Part 2: Trading for a client (adds a new command) In addition to the above, the input may contain client orders: `order <timestamp> <security> <client> <goal_shares> <participation_rate>` - `goal_shares` is a positive integer (total shares the client wants to trade). - `participation_rate` is an integer percentage (e.g., `20` means 20%). ### Execution rules When processing the stream, you may generate your own trades to fill active orders. 1. **Trade price:** Every trade you execute for a security must use the **previous trade price** for that security (i.e., the most recent price seen for that security from a `print` line; if no price has ever been printed for that security yet, you cannot trade it). 2. **Participation constraint (per security):** At any timestamp `t`, the client’s cumulative executed shares for that security in the trailing minute must be at most: `floor( market_volume(t) * participation_rate / 100 )` where `market_volume(t)` is the trailing-minute market volume defined above (from **exchange `print` lines only**, not including your own executions). 3. **Trade ASAP:** After reading each input line, **before moving to the next line**, execute and output all trades that are currently feasible for any active orders (subject to remaining shares and participation constraints). 4. **Order completion:** An order stays active until its `goal_shares` are fully executed. ### Output format (Part 2) For each executed trade you generate, output a line: `print <timestamp> <security> <num_shares> <price>` - The `timestamp` is the time at which you execute it (i.e., the timestamp of the currently processed input line that enabled the trade). ## Example Input: ``` print 122 GOLD 100 10 print 123 GOLD 100 10 order 123 GOLD BOB 100 20 print 124 GOLD 100 10 ``` Output: ``` print 123 GOLD 40 10 print 124 GOLD 20 10 ``` Explanation (informal): at `t=123`, trailing-minute market volume is `200`, so max allowed is `floor(200*20/100)=40`. After the next market print at `t=124`, trailing-minute market volume is `300`, so max allowed becomes `60`, allowing 20 more shares. ## Task Implement this streaming processor. ### Notes / edge cases to handle - Multiple securities and multiple outstanding orders may exist. - Timestamps can repeat (multiple commands at the same second). - You must respect “trade ASAP” semantics (process all feasible executions at time `t` before reading the next input line). - Choose and document a deterministic policy for how to allocate capacity if multiple active orders compete for the same security at the same timestamp (e.g., FIFO by order arrival).