docs: update the docs.

docs/data.rst

@@ -1,7 +1,7 @@
 Data
 ====
 
-Please see https://github.com/nkaz001/hftbacktest/tree/master/collector or
+Please see `Data Collector <https://github.com/nkaz001/hftbacktest/tree/master/collector>`_ or
 :doc:`Data Preparation <tutorials/Data Preparation>` regarding collecting and converting the feed data.
 
 Format

docs/debugging_backtesting_and_live_discrepancies.rst

@@ -25,9 +25,9 @@ infrastructure provides a competitive advantage is beneficial.
 
 2. Queue Model:
 Selecting an appropriate queue model that accurately reflects live trading results is essential. You can either develop
-your own queue model or utilize existing ones. Hftbacktest offers three primary queue models such as PowerProbQueueModel
-series, allowing for adjustments to align with your results. For further information, refer to
-`ProbQueueModel <https://hftbacktest.readthedocs.io/en/latest/order_fill.html#probqueuemodel>`_.
+your own queue model or utilize existing ones. Hftbacktest offers three primary queue models such as
+``PowerProbQueueModel`` series, allowing for adjustments to align with your results. For further information, refer to
+:ref:`ProbQueueModel <order_fill_prob_queue_model>`.
 
 One crucial point to bear in mind is the backtesting conducted under the assumption of no market impact. A market order,
 or a limit order that take liquidity, can introduce discrepancies, as it may cause market impact and consequently make

docs/index.rst

@@ -61,7 +61,7 @@ Or you can clone the latest development version from the Git repository with:
 Data Source & Format
 --------------------
 
-Please see `Data <https://hftbacktest.readthedocs.io/en/latest/data.html>`_ or `Data Preparation <https://hftbacktest.readthedocs.io/en/latest/tutorials/Data%20Preparation.html>`_.
+Please see :doc:`Data <data>`_ or :doc:`Data Preparation <tutorials/Data Preparation>`.
 
 A Quick Example
 ---------------
@@ -152,17 +152,17 @@ Get a glimpse of what backtesting with hftbacktest looks like with these code sn
 
 Tutorials
 =========
-* `Data Preparation <https://hftbacktest.readthedocs.io/en/latest/tutorials/Data%20Preparation.html>`_
-* `Getting Started <https://hftbacktest.readthedocs.io/en/latest/tutorials/Getting%20Started.html>`_
-* `Working with Market Depth and Trades <https://hftbacktest.readthedocs.io/en/latest/tutorials/Working%20with%20Market%20Depth%20and%20Trades.html>`_
-* `Integrating Custom Data <https://hftbacktest.readthedocs.io/en/latest/tutorials/Integrating%20Custom%20Data.html>`_
-* `Making Multiple Markets - Introduction <https://hftbacktest.readthedocs.io/en/latest/tutorials/Making%20Multiple%20Markets%20-%20Introduction.html>`_
-* `High-Frequency Grid Trading <https://hftbacktest.readthedocs.io/en/latest/tutorials/High-Frequency%20Grid%20Trading.html>`_
-* `Impact of Order Latency <https://hftbacktest.readthedocs.io/en/latest/tutorials/Impact%20of%20Order%20Latency.html>`_
-* `Order Latency Data <https://hftbacktest.readthedocs.io/en/latest/tutorials/Order%20Latency%20Data.html>`_
-* `Guéant–Lehalle–Fernandez-Tapia Market Making Model and Grid Trading <https://hftbacktest.readthedocs.io/en/latest/tutorials/GLFT%20Market%20Making%20Model%20and%20Grid%20Trading.html>`_
-* `Making Multiple Markets <https://hftbacktest.readthedocs.io/en/latest/tutorials/Making%20Multiple%20Markets.html>`_
-* `Risk Mitigation through Price Protection in Extreme Market Conditions <https://hftbacktest.readthedocs.io/en/latest/tutorials/Risk%20Mitigation%20through%20Price%20Protection%20in%20Extreme%20Market%20Conditions.html>`_
+* :doc:`Data Preparation <tutorials/Data Preparation>`
+* :doc:`Getting Started <tutorials/Getting Started>`
+* :doc:`Working with Market Depth and Trades <tutorials/Working with Market Depth and Trades>`
+* :doc:`Integrating Custom Data <tutorials/Integrating Custom Data>`
+* :doc:`Making Multiple Markets - Introduction <tutorials/Making Multiple Markets - Introduction>`
+* :doc:`High-Frequency Grid Trading <tutorials/High-Frequency Grid Trading>`
+* :doc:`Impact of Order Latency <tutorials/Impact of Order Latency>`
+* :doc:`Order Latency Data <tutorials/Order Latency Data>`
+* :doc:`Guéant–Lehalle–Fernandez-Tapia Market Making Model and Grid Trading <tutorials/GLFT Market Making Model and Grid Trading>`
+* :doc:`Making Multiple Markets <tutorials/Making Multiple Markets>`
+* :doc:`Risk Mitigation through Price Protection in Extreme Market Conditions <tutorials/Risk Mitigation through Price Protection in Extreme Market Conditions>`
 
 Examples
 ========
@@ -171,7 +171,7 @@ You can find more examples in `examples <https://github.com/nkaz001/hftbacktest/
 
 Migration to V2
 ===============
-Please see the `migration guide <https://hftbacktest.readthedocs.io/en/latest/Migration%20To%20v2.html>`_.
+Please see the :doc:`migration guide <migration2>`.
 
 Roadmap
 =======

docs/jit_compilation_overhead.rst

@@ -40,9 +40,7 @@ backtesting for multiple days, it can still be bothersome. To minimize this over
             .power_prob_queue_model3(3.0)
             .tick_size(0.01)
             .lot_size(0.001)
-            .maker_fee(-0.00005),
-            .taker_fee(0.0007),
-            .trade_len(0)
+            .trading_value_fee_model(0.0002, 0.0007)
     )
 
     hbt = HashMapMarketDepthBacktest([asset])

docs/latency_models.rst

@@ -13,16 +13,16 @@ HftBacktest has three types of latencies.
 
 This is the latency between the time the exchange sends the feed events such as order book change or trade and the time
 it is received by the local.
-This latency is dealt with through two different timestamps: ``local_timestamp`` and ``exch_timestamp`` (exchange timestamp).
+This latency is dealt with through two different timestamps: local timestamp and exchange timestamp.
 
 * Order entry latency
 
-This is the latency between the time you send an order request and the time it is received by the exchange.
+This is the latency between the time you send an order request and the time it is processed by the exchange's matching engine.
 
 * Order response latency
 
-This is the latency between the time the exchange processes an order request and the time the order response is received by the local.
-The response to your order fill is also affected by this type of latency.
+This is the latency between the time the exchange's matching engine processes an order request and the time the order
+response is received by the local. The response to your order fill is also affected by this type of latency.
 
 .. image:: images/latency-comparison.png
 
@@ -35,151 +35,39 @@ ConstantLatency
 ~~~~~~~~~~~~~~~
 It's the most basic model that uses constant latencies. You just set the latencies.
 
-..  code-block:: python
+You can find details below.
 
-    from hftbacktest import ConstantLatency
-
-    hbt = HftBacktest(
-        data,
-        tick_size=0.01,
-        lot_size=0.001,
-        maker_fee=-0.00005,
-        taker_fee=0.0007,
-        order_latency=ConstantLatency(entry_latency=50, response_latency=50),
-        asset_type=Linear
-    )
-
-
-BackwardFeedLatency
-~~~~~~~~~~~~~~~~~~~
-This model uses the latest feed latency as order latencies.
-The latencies are calculated according to the given arguments as follows.
-
-.. code-block:: python
-
-    feed_latency = local_timestamp - exch_timestamp
-    entry_latency = entry_latency_mul * feed_latency + entry_latency
-    resp_latency = resp_latency_mul * feed_latency + resp_latency
-
-.. code-block:: python
-
-    from hftbacktest import BackwardFeedLatency
-
-    hbt = HftBacktest(
-        data,
-        tick_size=0.01,
-        lot_size=0.001,
-        maker_fee=-0.00005,
-        taker_fee=0.0007,
-        order_latency=BackwardFeedLatency(
-            entry_latency_mul=1,
-            resp_latency_mul=1,
-            entry_latency=0,
-            response_latency=0
-        ),
-        asset_type=Linear
-    )
-
-
-ForwardFeedLatency
-~~~~~~~~~~~~~~~~~~
-This model uses the next feed latency as order latencies using forward-looking information.
-
-.. code-block:: python
-
-    from hftbacktest import ForwardFeedLatency
-
-    hbt = HftBacktest(
-        data,
-        tick_size=0.01,
-        lot_size=0.001,
-        maker_fee=-0.00005,
-        taker_fee=0.0007,
-        order_latency=ForwardFeedLatency(
-            entry_latency_mul=1,
-            resp_latency_mul=1,
-            entry_latency=0,
-            response_latency=0
-        ),
-        asset_type=Linear
-    )
-
-
-FeedLatency
-~~~~~~~~~~~
-This model uses the average of the latest and the next feed latency as order latencies.
-
-.. code-block:: python
-
-    from hftbacktest import FeedLatency
-
-    hbt = HftBacktest(
-        data,
-        tick_size=0.01,
-        lot_size=0.001,
-        maker_fee=-0.00005,
-        taker_fee=0.0007,
-        order_latency=FeedLatency(
-            entry_latency_mul=1,
-            resp_latency_mul=1,
-            entry_latency=0,
-            response_latency=0
-        ),
-        asset_type=Linear
-    )
+* `ConstantLatency <https://docs.rs/hftbacktest/latest/hftbacktest/backtest/models/struct.ConstantLatency.html>`_
+  and :meth:`constant_latency <hftbacktest.BacktestAsset.constant_latency>`
 
 IntpOrderLatency
 ~~~~~~~~~~~~~~~~
 This model interpolates order latency based on the actual order latency data.
 This is the most accurate among the provided models if you have the data with a fine time interval.
 You can collect the latency data by submitting unexecutable orders regularly.
 
-.. code-block:: python
+You can find details below.
 
-    latency_data = np.load('order_latency')
-
-    from hftbacktest import IntpOrderLatency
-
-    hbt = HftBacktest(
-        data,
-        tick_size=0.01,
-        lot_size=0.001,
-        maker_fee=-0.00005,
-        taker_fee=0.0007,
-        order_latency=IntpOrderLatency(latency_data),
-        asset_type=Linear
-    )
+* `IntpOrderLatency <https://docs.rs/hftbacktest/latest/hftbacktest/backtest/models/struct.IntpOrderLatency.html>`_
+  and :meth:`intp_order_latency <hftbacktest.BacktestAsset.intp_order_latency>`
 
 **Data example**
 
 .. code-block::
 
-    request_timestamp_at_local, exch_timestamp, receive_response_timestamp_at_local
-    1670026844751525, 1670026844759000, 1670026844762122
-    1670026845754020, 1670026845762000, 1670026845770003
+    req_ts (request timestamp at local), exch_ts (exchange timestamp), resp_ts (receipt timestamp at local), _padding
+    1670026844751525000, 1670026844759000000, 1670026844762122000, 0
+    1670026845754020000, 1670026845762000000, 1670026845770003000, 0
 
+FeedLatency
+~~~~~~~~~~~
+If the live order latency data is unavailable, you can generate artificial order latency using feed latency.
+Please refer to :doc:`this tutorial <tutorials/Order Latency Data>` for guidance.
 
 Implement your own order latency model
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-You need to implement ``numba`` ``jitclass`` that has two methods: ``entry`` and ``response``.
-
-See `Latency model implementation <https://github.com/nkaz001/hftbacktest/blob/master/hftbacktest/models/latencies.py>`_
-
-.. code-block:: python
-
-    @jitclass
-    class CustomLatencyModel:
-        def __init__(self):
-            pass
-
-        def entry(self, timestamp, order, proc):
-            # todo: return order entry latency.
-            return 0
-
-        def response(self, timestamp, order, proc):
-            # todo: return order response latency.
-            return 0
+You need to implement the following trait.
 
-        def reset(self):
-            pass
+* `LatencyModel <https://docs.rs/hftbacktest/latest/hftbacktest/backtest/models/trait.LatencyModel.html>`_
 
+Please refer to `the latency model implementation <https://github.com/nkaz001/hftbacktest/blob/master/hftbacktest/src/backtest/models/latency.rs>`_.

docs/migration2.rst

@@ -9,20 +9,17 @@ The migration from version 1 to version 2 introduces several significant changes
 is used without modification. It is highly recommended to review the updated tutorials. This guide aims to help you
 avoid common pitfalls during the migration process.
 
-Checking Success: Use if `elapse() == 0` Instead of if `elapse()`
------------------------------------------------------------------
-In version 1, `elapse` function returns `True` on success and `False` otherwise. Typically, the strategy loop checks
-for successful elapsing using `while elapse(duration):`. However, in version 2, elapse returns a code instead of a
-boolean, with `0` indicating success and any other value indicating an error. Consequently, the code should be updated
-to check if the return value equals `0`.
-
-For instance:
-
-`while elapse(duration) == 0:`
-If the code remains unchanged, it will fail because a return value of `0` (indicating success) will be treated as
-`False`. Other methods that involve elapsing, such as `submit_buy_order` or `submit_sell_order`, also return a code
-similar to `elapse` instead of a boolean. Ensure to check if their return values equal `0` to confirm success instead of
-checking for `True`.
+Checking Success: Use ``elapse() == 0``
+---------------------------------------
+In version 1, ``elapse`` function returns ``True`` on success and ``False`` otherwise. Typically, the strategy loop
+checks for successful elapsing using ``while elapse(duration)``. However, in version 2, elapse returns a code instead
+of a boolean, with ``0`` indicating success and any other value indicating an error. Consequently, the code should be
+updated to check if the return value equals ``0``.
+
+For instance: ``while elapse(duration) == 0`` If the code remains unchanged, it will fail because a return value of
+``0`` (indicating success) will be treated as ``False``. Other methods that involve elapsing, such as
+``submit_buy_order`` or ``submit_sell_order``, also return a code similar to ``elapse`` instead of a boolean. Ensure to
+check if their return values equal ``0`` to confirm success instead of checking for ``True``.
 
 Data Format Changes
 -------------------
@@ -33,12 +30,15 @@ is provided.
 The major changes are as follows:
 
 * SOA to AOS: The format has shifted from a columnar array (SOA) to a structured array (AOS).
-* Side Column Removal: `side` column has been removed. In version 2, the side is indicated by the `ev` field flags,
-                       `BUY_EVENT` and `SELL_EVENT`.
+
+* Side Column Removal: ``side`` column has been removed. In version 2, the side is indicated by the ``ev`` field flags,
+  :const:`BUY_EVENT <hftbacktest.types.BUY_EVENT>` and :const:`SELL_EVENT <hftbacktest.types.SELL_EVENT>`.
+
 * Timestamp Handling: In version 1, the data utility corrects the event order by replacing one of the timestamps with
-                      `-1` to indicate an invalid event on either the exchange or the local side.
-                      In version 2, the validity of events on the exchange or local side is determined by `ev` field's
-                      `EXCH_EVENT` and `LOCAL_EVENT` flags.
-Timestamp Unit: Although not strictly enforced, the timestamp unit has changed from microseconds to nanoseconds.
+  ``-1`` to indicate an invalid event on either the exchange or the local side. In version 2, the validity of events on
+  the exchange or local side is determined by `ev` field's :const:`EXCH_EVENT <hftbacktest.types.EXCH_EVENT>` and
+  :const:`LOCAL_EVENT <hftbacktest.types.LOCAL_EVENT>` flags.
+
+* Timestamp Unit: Although not strictly enforced, the timestamp unit has changed from microseconds to nanoseconds.
 
 Additionally, the format for live order latency data has changed from SOA to AOS.