mirror of
https://github.com/mihakralj/QuanTAlib.git
synced 2026-08-03 03:47:42 +00:00
a7b7207801
- Updated mathematical foundations and performance profiles where necessary to maintain clarity and coherence.
35 lines
7.0 KiB
Markdown
35 lines
7.0 KiB
Markdown
# Glossary
|
|
|
|
Short reference for core QuanTAlib terminology and types.
|
|
|
|
| Term | Definition |
|
|
| :--- | :--------- |
|
|
| **Accuracy** | Measure of how well an indicator preserves the important structure of the original price series while still filtering out noise. It captures closeness to the original data: more *smoothness* removes zigzagging noise but will also reduce *accuracy* if it starts erasing meaningful swings and cycles. |
|
|
| **AVX2** | **256-bit SIMD** extension for x86-64 (AMD64) CPUs from Intel and AMD. Used to accelerate vectorized span-based calculations. |
|
|
| **AVX-512** | **512-bit SIMD** extension available on many x86-64 (AMD64) desktop and server CPUs released since around **2015**. Doubles vector width over AVX2 and adds masking and extra math operations. |
|
|
| **Array of Structs (AoS)** | Memory layout where each element is a full record, for example `struct Bar { double Open, High, Low, Close; }` stored as `Bar[]`. Simple to model but cache-inefficient for single-field operations and harder to **SIMD-vectorize** than structure of arrays (SoA). Avoided in QuanTAlib. |
|
|
| **Batch Mode** | Mode where indicators operate on `TSeries` objects instead of raw spans. Handles timestamps, resizing, and time alignment while still using span-based implementations internally. Best for historical analysis where you want time-aware series without managing arrays directly. |
|
|
| **Eventing Mode** | **Reactive** usage pattern where indicators implement `ITValuePublisher` and raise events as values change or warmup completes (`IsHot`). Used to build chains of indicators and trading logic that react to state changes instead of polling for values. |
|
|
| **FIR filter** | **Finite impulse response** filter. Output depends on a finite window of past inputs with no feedback from the past. Always stable. Typical examples in TA are a *simple moving average*, *weighted moving average* or *hull moving average*. |
|
|
| **Hot path** | Code that executes for every incoming tick or bar during live trading. In QuanTAlib, hot paths (such as `Update` and span-based `Calculate` loops) must *avoid heap allocations*, run in *constant time* $O(1)$ where possible, and be *SIMD-optimized* when the algorithm allows. |
|
|
| **IIR filter** | **Infinite impulse response** filter. Output depends on both current input and past outputs via feedback. More responsive for a given period but requires care for numerical stability. Typical examples in TA are an *exponential moving average*, *kaufman adaptive moving average* and *variable index moving average*. |
|
|
| **isHot** | Boolean property on indicators that becomes **`true`** after sufficient data has been processed (for example once the internal period / warmup length is reached). Before `isHot` is `true`, output values are considered **not fully reliable**. |
|
|
| **`isNew` flag** | Boolean parameter on `Update(TValue input, bool isNew = true)` that controls bar-correction behavior: `isNew = true` advances state to the next bar; `isNew = false` updates the most recent bar in-place (intra-bar correction) for streaming feeds where the latest bar can change before it closes. |
|
|
| **NEON** | **128-bit SIMD** architecture for ARM CPUs (including many mobile devices and Apple Silicon). .NET exposes NEON via `System.Runtime.Intrinsics.Arm` so the same span-based indicator code can vectorize on ARM hardware. |
|
|
| **O(1)** | **Constant-time** complexity. Work per update does not grow with the length of the time series or lookback window. Target complexity for streaming `Update` methods in QuanTAlib whenever mathematically possible. |
|
|
| **O(n)** | **Linear-time** complexity in the number of input points $n$. Typical for batch calculations that walk the series once. Acceptable for one-off batch work, not for hot-path streaming updates. |
|
|
| **Overshoot** | Degree to which an indicator *overreacts* around turning points, swinging past the underlying price or signal before settling. High overshoot produces dramatic but potentially misleading signals, especially near reversals. |
|
|
| **Period** | Configuration parameter that describes how many bars or samples an indicator considers for its calculation. Relevant for FIR, not so much for IIR indicators. |
|
|
| **RingBuffer** | **Fixed-size circular buffer** used for sliding-window calculations. New values overwrite the oldest entries once the buffer is full, keeping time and memory usage effectively constant regardless of history length. |
|
|
| **SIMD** | *Single Instruction, Multiple Data*. Hardware feature allowing the CPU to apply one instruction to many values at once. QuanTAlib uses .NET SIMD support (for example **AVX2**, **AVX-512**, or **NEON** when available) to accelerate span-based calculations. |
|
|
| **Smoothness** | Measure of how visually and numerically *calm* an indicator's line is. More *smoothness* filters random noise but usually increases lag; less smoothness responds faster but exposes more short-term fluctuation. |
|
|
| **Span Mode** | Lowest-level, **zero-allocation** mode operating directly on `Span<double>` / `ReadOnlySpan<double>`. Designed for backtesting and research workloads that process large arrays with maximum SIMD acceleration and no object overhead. |
|
|
| **Streaming Mode** | Real-time update mode using `Update(TValue input, bool isNew = true)`. Maintains internal state between calls and distinguishes between **new bars** and **intra-bar corrections** via the `isNew` flag. Intended for live feeds and tick-by-tick data. |
|
|
| **Structure of Arrays (SoA)** | Memory layout where each field of a logical record is stored in its own contiguous buffer (for example, prices and timestamps in separate arrays). Improves cache locality and enables **vectorized operations** across large segments of a single field. |
|
|
| **TBar** | Struct representing an **OHLCV bar**: time, open, high, low, close, and volume. Used when indicators need full bar context instead of a single price. |
|
|
| **TSeries** | Primary time series container. Uses *structure-of-arrays* layout: timestamps and values stored in separate buffers and exposed as `ReadOnlySpan<T>` for **SIMD-friendly access**. Represents a sequence of scalar values over time. |
|
|
| **Throughput** | Number of ticks or bars an indicator can **process per second** on a given machine. Driven by per-update complexity (target $O(1)$), SIMD utilization, and zero-allocation hot paths. |
|
|
| **Timeliness** | Measures how much an indicator **lags** behind the underlying price series. Excessive lag pushes entries and exits late and can cut profits. For classic moving averages (SMA, WMA, EMA) more *smoothness* almost always means more lag; designs like DEMA, HMA or JMA aim to stay close to price while still filtering noise. |
|
|
| **TValue** | Struct pairing a `DateTime` with a single `double` value. Standard input and output type for indicators in **streaming mode**. |
|
|
| **Zero-allocation design** | Design rule that hot paths must **not allocate** on the managed heap. Achieved by using `Span<T>` or `ReadOnlySpan<T>` for batch APIs, preferring **`stackalloc`** for small temporaries, and reusing internal state instead of creating new objects on each update. |
|