7f1a6df202ff6a7fc2cb4b2b27e8b83a7ea7657f
27
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 kingchencandGitHub
|
24e723fa7d |
feat: Family 02 Momentum Oscillators — RVI / PGO / KST / SMI / Laguerre / Connors / Inertia (#40)
* feat(rvi): add Relative Vigor Index
Dorsey's RVI = SMA(close - open, period) / SMA(high - low, period) over
a rolling window of period candles. Candle input, single parameter
period (default 10). Positive on average-bullish windows, negative on
average-bearish. Holds the previous value if the entire window has
zero range (denominator undefined).
Reference: Donald Dorsey, also pandas-ta rvi.
Touchpoints: rvi.rs + mod.rs + lib.rs re-export, PyRvi + __init__.py
+ test_new_indicators CANDLE_SCALAR + test_known_values reference,
RviNode (4-column OHLC batch) + index.d.ts/index.js + indicators.test
.js factory + reference, WasmRvi + make_candle_ohlc helper, candle-fuzz
target + criterion bench, README + CHANGELOG.
* feat(pgo): add Pretty Good Oscillator
Mark Johnson's PGO = (close - SMA(close, period)) / EMA(TR, period).
Counts roughly how many ATR-equivalents the close sits from its
period-bar mean. Candle input, single parameter period (default 14).
Johnson's heuristic uses +3/-3 crossings as entry signals.
Touchpoints: pgo.rs + mod.rs + lib.rs re-export, PyPgo + __init__.py
+ test_new_indicators CANDLE_SCALAR + test_known_values flat-close
reference, PgoNode (h/l/c) + index.d.ts/index.js + indicators.test.js
factory + reference, WasmPgo, candle-fuzz target + bench, README +
CHANGELOG.
* feat(kst): add Know Sure Thing (Pring)
Pring's long-horizon momentum oscillator: weighted sum of four
SMA-smoothed ROC series with fixed weights 1, 2, 3, 4, plus an SMA
signal line. Nine parameters (four ROC periods, four SMA periods, one
signal period); classic() applies Pring's recommended defaults.
Multi-output indicator emitting KstOutput { kst, signal }.
Touchpoints: kst.rs + mod.rs + lib.rs re-export, PyKst + __init__.py
+ test_new_indicators MULTI + test_known_values flat-input reference,
KstNode + KstValue + index.d.ts/index.js + indicators.test.js multi
factory + reference, WasmKst (manual JsValue object), scalar-fuzz
target (handled outside the f64-output drive helper), README +
CHANGELOG.
* feat(smi): add Stochastic Momentum Index (Blau)
Blau's doubly-EMA-smoothed bounded oscillator: measures the close's
displacement from the centre of the recent high-low range, scaled by
the smoothed range. Candle input, three parameters (period, d_period,
d2_period) with defaults 5 / 3 / 3.
Internally feeds both the displacement-EMA stack and the range-EMA
stack on every candle so they warm up in parallel (gating either
behind the other starves the second by one input).
Touchpoints: smi.rs + mod.rs + lib.rs re-export, PySmi + __init__.py
+ test_new_indicators CANDLE_SCALAR + test_known_values flat-input
reference, SmiNode + index.d.ts/index.js + indicators.test.js factory
+ reference, WasmSmi, candle-fuzz target, README + CHANGELOG.
* feat(laguerre-rsi): add Ehlers Laguerre RSI
Four-stage Laguerre polynomial filter wrapped in an RSI-style up/down
accumulator. Single gamma in [0, 1] (default 0.5) trades lag for
smoothness. State is seeded by setting all four L_i to the first input
so a constant series stays at the neutral 50. Output clamped to
[0, 100] to absorb floating-point rounding.
Reference: Ehlers, Time Warp - Without Space Travel, 2002.
Touchpoints: laguerre_rsi.rs + mod.rs + lib.rs re-export, PyLaguerreRsi
+ __init__.py + test_new_indicators SCALAR + test_known_values neutral
reference, LaguerreRsiNode + index.d.ts/index.js + indicators.test.js
factory + reference, WasmLaguerreRsi via scalar macro, scalar-fuzz
target, README + CHANGELOG.
* feat(connors-rsi): add Connors RSI (CRSI)
Larry Connors' 3-component aggregate: RSI(close), RSI(streak), and
PercentRank of the 1-period return over the last period_rank returns.
Each component is bounded in [0, 100] so the aggregate is too.
Three parameters (period_rsi, period_streak, period_rank) with
defaults 3 / 2 / 100. Streak tracks consecutive up/down runs (resets
to 0 on unchanged close).
Touchpoints: connors_rsi.rs + mod.rs + lib.rs re-export, PyConnorsRsi
+ __init__.py + test_new_indicators SCALAR + test_known_values bounded
reference, ConnorsRsiNode + index.d.ts/index.js + indicators.test.js
factory + reference, WasmConnorsRsi via scalar macro, scalar-fuzz
target, README + CHANGELOG.
* feat(inertia): add Dorsey Inertia (RVI + LinReg)
Donald Dorsey's Inertia — a LinearRegression smoothing of the RVI
series. Endpoint of an n-bar least-squares fit of RVI is the indicator
reading. Preserves trend direction while damping the ratio. Candle
input, two parameters (rvi_period, linreg_period) with defaults 14 / 20.
Touchpoints: inertia.rs + mod.rs + lib.rs re-export, PyInertia +
__init__.py + test_new_indicators CANDLE_SCALAR + test_known_values
constant reference, InertiaNode (4-column OHLC batch) + index.d.ts /
index.js + indicators.test.js factory + reference, WasmInertia,
candle-fuzz target, README + CHANGELOG.
* test(kst): Move KST out of MULTI dict (it is scalar-input)
KST sits in the MULTI dict (candle-input, multi-output) but its
update() takes a single f64, not a candle tuple. The shared streaming
loop in test_multi_streaming_matches_batch fed the OHLCV tuple in,
which crashed with `TypeError: argument 'value': must be real number,
not tuple` on every Python matrix entry.
Split into a new MULTI_SCALAR_INPUT dict with its own test function
that feeds the close-price stream as floats. KST is currently the
only such indicator; structure is ready for future scalar-input
multi-output additions (e.g. some MACD-shaped indicators).
* test(coverage): Cover SMI zero-range and ConnorsRsi zero-prev cold paths
codecov/patch on PR 40 flagged two uncovered defensive branches:
- SMI returns self.current early when the smoothed range collapses to
zero (`r2 <= 0.0`) so the formula stays defined. Exercised by feeding
bars where high == low.
- ConnorsRsi skips the ROC ring-buffer update when the previous price
is exactly zero so the divide-by-zero in `(input - prev) / prev` is
impossible. Exercised by seeding the first bar at 0.0.
|
||
|
kingchencandGitHub
|
466faddd87 |
feat: Family 01 Moving Averages — ALMA / McGinley / FRAMA / VIDYA / JMA / Alligator / EVWMA (#39)
* feat(alma): add Arnaud Legoux Moving Average
Gaussian-weighted moving average with configurable centre (offset in
[0, 1]) and kernel width (sigma > 0). Pre-computes normalised weights
at construction so each update is a single rolling window dot product.
Reference: Arnaud Legoux and Dimitrios Kouzis-Loukas, 2009.
Touchpoints:
- crates/wickra-core: alma.rs + mod.rs + lib.rs re-export
- bindings/python: PyAlma + __init__.py + test_new_indicators +
test_known_values reference
- bindings/node: AlmaNode + index.d.ts/index.js + indicators.test.js
factory + reference value
- bindings/wasm: wasm_scalar_indicator! macro
- fuzz: indicator_update target covers ALMA(9, 0.85, 6.0)
- crates/wickra/benches: bench_scalar entry
- README + CHANGELOG: Moving Averages row + Unreleased entry
* feat(mcginley): add McGinley Dynamic moving average
John McGinley's self-adjusting moving average with the recurrence
MD + (price - MD) / (0.6 * period * (price / MD)^4). Speeds up when
price falls below the indicator and damps when price runs above the
indicator. Seeded with the simple average of the first period inputs.
Reference: McGinley, Technical Analysis of Stocks & Commodities, 1990.
Touchpoints:
- crates/wickra-core: mcginley_dynamic.rs + mod.rs + lib.rs re-export
- bindings/python: PyMcGinleyDynamic + __init__.py + test_new_indicators
+ test_known_values reference
- bindings/node: McGinleyDynamicNode (scalar macro) + index.d.ts/index.js
+ indicators.test.js factory + reference value
- bindings/wasm: wasm_scalar_indicator! macro
- fuzz: indicator_update target covers McGinleyDynamic(10)
- crates/wickra/benches: bench_scalar entry
- README + CHANGELOG: Moving Averages row + Unreleased entry
* feat(frama): add Fractal Adaptive Moving Average
Ehlers' FRAMA adapts its smoothing constant to the fractal dimension of
the recent window: tight tracking in trends, heavy smoothing in chop.
Uses the close-only variant where max/min over each window half drive
the dimension estimate. Period must be even (default 16).
Reference: Ehlers, Fractal Adaptive Moving Average, 2005.
Touchpoints:
- crates/wickra-core: frama.rs + mod.rs + lib.rs re-export
- bindings/python: PyFrama + __init__.py + test_new_indicators +
test_known_values reference (constant series + uptrend tracking)
- bindings/node: FramaNode (scalar macro) + index.d.ts/index.js +
indicators.test.js factory + reference value
- bindings/wasm: wasm_scalar_indicator! macro
- fuzz: indicator_update target covers Frama(16)
- crates/wickra/benches: bench_scalar entry
- README + CHANGELOG: Moving Averages row + Unreleased entry
* feat(vidya): add Variable Index Dynamic Average
Chande's VIDYA — an EMA whose alpha scales with |CMO(cmo_period)| / 100.
Strong directional momentum lifts the smoothing constant toward the
EMA-of-period rate; flat or choppy windows shrink it toward zero so
VIDYA coasts on its previous value. Two parameters: period (14) and
cmo_period (9). Reuses the existing wickra-core Cmo internally.
Reference: Chande, Stocks & Commodities, 1992.
Also fixes a silent gap from
|
||
|
kingchencandGitHub
|
e30b3c6b35 |
release: 0.2.7 (Windows ARM64 restored + CPU label fix) (#37)
* chore(docs): rename benchmark CPU from 7950X3D to 9950X
The "Reproduced on" line in the umbrella + binding READMEs and the
benchmark page on the site listed the wrong AMD CPU. The benchmarks
were actually produced on a Ryzen 9 9950X, not a 7950X3D. Same
column for absolute µs values applies — the speedup ratios in the
tables are unchanged either way because they're relative across
libraries on the same machine.
The performance-regression issue template's CPU example also
updated for consistency (it was a generic placeholder, but matching
the canonical machine makes the example concrete).
* chore(npm): restore Windows ARM64 sub-package + napi matrix entry
npm Support unblocked the `wickra-win32-arm64-msvc` package name and
transferred write access to @kingchenc (placeholder 0.0.1-security
was published from their side; we ship our first real version on
top of that). This re-enables every change
|
||
|
kingchencandGitHub
|
070be2eb27 |
release: 0.2.6 (docs.rs fix + README table reordering) (#36)
* fix(docs-rs): rename `doc_auto_cfg` to `doc_cfg` after Rust 1.92 merge `doc_auto_cfg` was removed in Rust 1.92.0 and folded back into `doc_cfg` (rust-lang/rust#138907). docs.rs builds with the latest nightly and sets `--cfg docsrs`, so the previous #![cfg_attr(docsrs, feature(doc_auto_cfg))] aborts compilation with E0557 on every published 0.2.x. GitHub CI never tripped this — stable rustc ignores the line because nothing sets the `docsrs` cfg there. Switch all three published library crates (`wickra`, `wickra-core`, `wickra-data`) to the merged-into `doc_cfg` gate. Same intent, same on-docs.rs output, builds again on nightly. * docs(readme): float Wickra to the top of the comparison tables Reorders the "Why Wickra exists" library-comparison table and the two benchmark headers so Wickra is the first row (with a ★ marker) instead of the last. The previous order placed Wickra at the bottom, which buries the only row a reader landing on the README is here to compare against. Same column data, same ★/winner annotations, just the row order flipped and a ★ prefix on the Wickra label. Mirrored across the umbrella README and every binding README so the crates.io / PyPI / npm landing pages stay in sync. * release: bump workspace + bindings to 0.2.6 Workspace, every binding (Python, Node, Node platform stubs), the release.yml comment and the CHANGELOG all move together to 0.2.6 so the next tagged release lines every artefact up. 0.2.6 carries two changes from the [0.2.6] CHANGELOG entry: - fix(docs-rs): swap the now-removed `doc_auto_cfg` feature gate for the merged-into `doc_cfg` so docs.rs nightly builds resume. - docs(readme): float ★ Wickra to the top of every comparison table across the umbrella + binding READMEs. wickra-win32-arm64-msvc stays excluded for this release with the same npm spam-filter rationale that held for 0.2.5. |
||
|
kingchencandGitHub
|
b5afc0a7e7 |
release: bump workspace + bindings to 0.2.5 (#35)
Workspace, every binding (Python, Node, Node platform stubs), and the release.yml comment are all updated together so the next tagged release on `v0.2.5` lines every artefact up. Also adds a short README "Disclaimer" section pointing out that Wickra is an indicator toolkit, not a trading system, and that production use is at the caller's own risk. The legal terms in LICENSE (PolyForm Noncommercial 1.0.0, "No Liability") already cover the warranty / as-is language — the README section just makes the trading-specific framing visible without burying it in a click-through. CHANGELOG carries the new 0.2.5 entry with the API addition (`BinanceConfig` + `connect_with_config`) and the best-effort Pong write change in `BinanceKlineStream::next_event`. wickra-win32-arm64-msvc stays excluded for this release with the same npm-spam-filter rationale that held for 0.2.1. |
||
|
kingchenc
|
8aa74cb638 |
release(0.2.1): bump to 0.2.1, skipping Windows ARM64 this cycle
The 0.2.0 release left wickra@npm stuck at 0.1.4 and never created a GitHub Release entry because the brand-new `wickra-win32-arm64-msvc` sub-package name was caught by npm's spam-detection filter on its first publish attempt (same situation that affected `wickra-win32-x64-msvc` through 0.1.4 until npm Support unblocked it). A support ticket is open; until it is resolved, ship 0.2.1 for the five platforms whose sub-packages are already on npm and re-add Windows ARM64 in a follow-up release. Changes for this cycle: - bindings/node/package.json: remove "wickra-win32-arm64-msvc" from optionalDependencies and "aarch64-pc-windows-msvc" from napi.triples.additional. - bindings/node/npm/win32-arm64-msvc/: removed (will be restored fresh once the npm name is unblocked). - .github/workflows/release.yml: comment out the aarch64-pc-windows-msvc entry of the node-build matrix with a TODO/restore note. - Bump every workspace and binding version to 0.2.1 (Cargo.toml, pyproject.toml, bindings/node/package.json, five npm/<target> templates, the wiki version table). Cargo.lock regenerated. - CHANGELOG: new [0.2.1] block consolidating every fix that has landed on main since 0.2.0 (HV epsilon, examples CI step, fuzz cargo-fuzz install, MSRV 1.85 -> 1.86 / 1.77 -> 1.88, criterion 0.5 -> 0.8, tokio-tungstenite 0.24 -> 0.29, tick_aggregator gap-fill cap, every GitHub Action SHA-pin bump). Compare-link added. The arm64 loader branch in bindings/node/index.js is left untouched: a Windows ARM64 user installing 0.2.1 will get the standard `Cannot find module 'wickra-win32-arm64-msvc'` error from the loader, which is accurate. PyPI's win-arm64 wheel is unaffected. Verified locally: cargo fmt/clippy/test --workspace --all-features -> 630 passed / 0 failed cargo build -p wickra-examples --bins -> clean cargo build -p wickra-node -> clean |
||
|
kingchenc
|
3f9429dd2c |
build: lift workspace MSRV further to 1.85 for criterion's clap_lex
The first MSRV bump to 1.80 fixed the rayon-core floor but ran into a
second transitive-dep floor on the same CI run:
error: failed to parse manifest at clap_lex-1.1.0/Cargo.toml
Caused by: feature `edition2024` is required
The package requires the Cargo feature called `edition2024`, but
that feature is not stabilized in this version of Cargo (1.80.1).
clap_lex 1.1.0 is pulled in by criterion (dev-dep on the wickra crate)
via clap 4.6 -> clap_builder 4.6 -> clap_lex 1.1. edition2024 was
stabilized in Rust 1.85, so lift the workspace MSRV one more step. The
1.85 floor subsumes the rayon-core 1.80 requirement; bindings/node
stays at 1.88 (napi-build) which already covers everything below it.
Also fix the fuzz job: cargo-fuzz defaulted to building for
x86_64-unknown-linux-musl, which is not installed on the GitHub-hosted
ubuntu runner. Pass --target x86_64-unknown-linux-gnu explicitly on
every cargo fuzz run invocation so it builds for the actual host
target.
|
||
|
kingchenc
|
30444ce296 |
build: lift MSRV to 1.80 workspace / 1.88 node binding
The previous MSRV pins were below what current transitive dependencies
need:
- rayon-core 1.13.0 (pulled in by the optional `parallel` feature on
wickra-core via rayon) requires rustc >= 1.80; under the old 1.75
workspace MSRV the CI MSRV job broke with "package `rayon-core
v1.13.0` cannot be built because it requires rustc 1.80 or newer".
- napi-build 2.3.2 (the build-script crate that napi-derive 2.x calls
into) requires rustc >= 1.88; under the old 1.77 node-binding MSRV
the CI MSRV-node job broke with "package `napi-build v2.3.2` cannot
be built because it requires rustc 1.88 or newer".
Pinning the deps backwards would have frozen us out of upstream
security/fix releases for both crates. Lifting the MSRV is the cleaner
path for a young 0.x library — downstream consumers on older toolchains
can stay on the already-published 0.2.0.
Updated:
- Cargo.toml workspace rust-version 1.75 -> 1.80
- bindings/node/Cargo.toml rust-version 1.77 -> 1.88
- .github/workflows/ci.yml MSRV matrix names + toolchain values + comment
- CHANGELOG.md [Unreleased] documents the bump
|
||
|
kingchenc
|
39a252ea66 |
release(0.2.0): bump version from 0.1.5 to 0.2.0
This release carries the full post-audit work — 46 new indicators
(25 → 71), an eight-family taxonomy restructure, new bindings for
RollingVWAP, the WASM streaming-update parity, the pyo3/numpy CVE
fix, the SMA/Bollinger drift bound, the O(1) LinearRegression
refactor, the UlcerIndex deque and the PSAR is_ready/reset fixes
plus a refreshed example suite and wiki. The earlier 0.1.5 number
was never published; jumping straight to 0.2.0 is the cleaner signal
for the scope of the change.
Bumped:
- Cargo.toml workspace + wickra-core workspace-dep version
- bindings/python/pyproject.toml
- bindings/node/package.json + optionalDependencies (six platform pins)
- 6 x bindings/node/npm/<target>/package.json
- Cargo.lock regenerated
- CHANGELOG.md [0.2.0] header + compare-link
- docs/wiki/Home.md published-versions table
- docs/wiki/Quickstart-{Rust,Node,WASM}.md + Warmup-Periods.md
version-pinned narrative lines
Verified locally:
- cargo fmt/clippy/test (628 passed, 0 failed)
- cargo deny check (no suppression)
- bindings/node node --test (92/92)
- bindings/python pytest (118/118)
- import wickra reports 0.2.0 with 72 indicator classes
|
||
|
kingchenc
|
11c52b8e86 |
release(0.1.5): stamp the CHANGELOG date
Replace the TBD placeholder under ## [0.1.5] with today's date so the release header is complete. The compare-link at v0.1.4...v0.1.5 is already in place and points at the right pair. |
||
|
kingchenc
|
896b71fc62 |
release(0.1.5): bump versions, finalize CHANGELOG, fail loud on missing platform binaries (R20, Z2)
Versions bumped to 0.1.5 in every authoritative location:
- workspace `Cargo.toml` (`[workspace.package].version`, the
`wickra-core` path dependency pin).
- `bindings/python/pyproject.toml`.
- `bindings/node/package.json` (main + all six `optionalDependencies`
pins).
- All six per-platform `bindings/node/npm/<target>/package.json`
templates.
CHANGELOG: the accumulated `[Unreleased]` block is promoted to
`[0.1.5] - TBD` (date left for the user to set at tag time); the new
`[Unreleased]` header sits empty above it; the compare link table is
extended with `[0.1.5]: …compare/v0.1.4...v0.1.5` and the
`[Unreleased]` link is repointed to `…compare/v0.1.5...HEAD`.
Wiki refresh for 0.1.5 (R20 + Z2):
- `Home.md` version pin table updated; the Quickstart-Node hint replaces
the "spam filter holding back Windows" caveat with "0.1.5 is the
first release in which `npm install wickra` works end-to-end on
Windows" (npm Support released the name on 2026-05-22).
- `Quickstart-Node.md`'s Windows caveat is rewritten to explain the
history (`0.1.1`–`0.1.4` of `wickra-win32-x64-msvc` are burned) and
the resolution (0.1.5+ installs cleanly).
- `Quickstart-Rust.md` version mention bumped.
- `Warmup-Periods.md` note bumped + corrected: every Node and WASM
class — single- and multi-output — now exposes `warmupPeriod()` after
R3 (this branch), not only the single-output ones.
`release.yml` `publish_dir` no longer silently swallows a
second-attempt platform-package publish failure with a `::warning::`
and `return 0`. A real failure (after the existing 30s retry) now
emits an `::error::` and fails the job. The original mask is exactly
what allowed the `wickra-win32-x64-msvc@0.1.1–0.1.4` spam-filter
rejections to land four times in a row without anyone noticing (audit
finding R20). Failing loud means the next regression of this shape is
caught at the release run, not by a Windows user trying to
`require('wickra')`.
This commit does NOT push, tag, or trigger a release — the user
publishes the 0.1.5 tag themselves once the manual npm-republish
smoke test confirms `wickra-win32-x64-msvc@0.1.5` accepts publish on
the freshly-released name.
|
||
|
kingchenc
|
183ebec7ba |
fix(core): skip non-positive HV prices and add Error::InvalidTick (R13, R14)
R13 — `HistoricalVolatility::update` previously substituted `0.0` for
the log-return whenever `prev <= 0` or `input <= 0`. The log-return is
undefined there, and silently treating bad ticks as "no movement"
underreports realised volatility on broken data feeds. The fix skips
non-positive prices entirely: `self.last` is returned, state is left
untouched, and the next real tick re-anchors against the previous
*valid* `prev_price`. This matches how every other indicator handles
invalid inputs (SMA / EMA / ROC / Bollinger).
A new test `skips_non_positive_prices` proves the invariant: after a
warmed-up indicator, two consecutive bad ticks (`-5.0` and `0.0`) must
return the baseline value, and a subsequent real positive tick must
produce the same output as a control indicator that simply never saw
the bad ticks.
R14 — `Tick::new` previously returned `Error::InvalidCandle` for
negative volume. A tick is not a candle; downstream tick-stream
pipelines should be able to match on a semantically-correct error. A
new `Error::InvalidTick { message }` variant is added; the existing
test is updated to assert against it. Python's `map_err` is extended
to forward the new variant as `PyValueError`; the Node and WASM
bindings format via `Error::to_string()` and pick the new variant up
automatically without source changes.
|
||
|
kingchenc
|
510013fc5a |
fix(sma, bollinger): periodic recompute to bound long-stream drift (R7, L2-Rust)
`Sma` and `BollingerBands` both maintained their running `sum` (and `sum_sq` for Bollinger) with a single-subtract incremental update. That is correct in exact arithmetic, but in f64 the sequence `sum -= old; sum += new` on long streams with alternating large/small magnitudes can accumulate catastrophic-cancellation error. Bollinger's existing `.max(0.0)` clamp on the computed variance was a band-aid for the same root cause — the drift had already driven the running variance below zero. The fix: every `16 · period` finite updates, reseed `sum` (and `sum_sq` for Bollinger) from the live window. Amortised cost stays at O(1) — `O(period)` work amortised over `O(period)` updates — and the reseed strategy is named after the constant `RECOMPUTE_EVERY` so the intention is clear at the call site. Behaviour is unchanged on inputs that did not drift to begin with (every existing test still passes, including `batch_equals_streaming` and the SMA proptest). Two new stress tests (`long_stream_drift_stays_bounded` in each module) feed a magnitude-alternating stream for `5 · RECOMPUTE_EVERY · period` updates and assert the reported value tracks a fresh from-scratch computation over the live window to within tight tolerance — these would have failed without the reseed on Bollinger's `sum_sq`. The misleading `sma.rs` comment that claimed drift was already bounded by recomputing the sum after each pop is rewritten to describe the actual reseed strategy (audit finding L2-Rust). |
||
|
kingchenc
|
2aef8c8db5 |
perf(linreg): incremental O(1) OLS for LinearRegression and LinRegSlope (R2)
`LinearRegression::fit` and `LinRegSlope::update` previously iterated the
full `period`-window on every tick to recompute `Σy` and `Σxy` from
scratch — O(period) per update, in violation of the `Indicator` trait's
O(1) contract. `LinRegAngle` inherits the cost transitively because it
delegates to `LinRegSlope`.
This commit slides the OLS state in closed form. The constant terms
(`Σx`, `Σxx`, the denominator `n·Σxx − (Σx)²`) were already precomputed
in `new`. The new running state is:
- `sum_y: f64` — running sum of the values currently in the window.
- `sum_xy: f64` — running Σ(x · y) where `x` is the position of each
value inside the trailing window (`0` for the oldest, `n−1` for the
newest).
On every push, when the window is already full the front value `y₀` is
popped and the indices of every remaining value shift down by 1; the
identity
new_Σxy = old_Σxy − old_Σy + y₀
closes the slide in O(1). The new value is then pushed at position `k`
(the current length before the push), contributing `k · new_value` to
`sum_xy` and `new_value` to `sum_y`. The output is the same TA-Lib OLS
formula evaluated against the incremental accumulators.
Behaviour is unchanged: same per-tick values, same warmup, same NaN
semantics. Two new tests compare the O(1) result bar-by-bar against a
fresh O(n) refit on a noisy ramp (sliding-phase dominated), a step
function (large pop/push deltas), and constants (tests floating-point
drift) — agreement is within `1e-9`.
`LinRegAngle` benefits automatically through its `LinRegSlope` field.
|
||
|
kingchenc
|
b003321562 |
test(fuzz): cover every indicator, scalar and candle inputs (R9)
The fuzz suite previously covered only `Rsi(14)` and `Ema(20)` — 2 of 71 indicators, no OHLCV coverage at all. Audit finding R9 asked for ATR/ADX/Stochastic/PSAR as a minimum; this commit goes further and brings every indicator under fuzz. - `indicator_update` (rewritten): drives every scalar-input indicator through one streaming pass + one batch call per iteration. Covers SMA, EMA, WMA, RSI, DEMA, TEMA, HMA, ROC, TRIX, SMMA, TRIMA, ZLEMA, KAMA, T3, MOM, CMO, TSI, PMO, StochRSI, DPO, PPO, Coppock, StdDev, UlcerIndex, HistoricalVolatility, LinearRegression, LinRegSlope, LinRegAngle, VHF, ZScore, MACD, BollingerBands. A `drive` helper marked `#[inline(never)]` keeps each indicator on its own panic backtrace frame. - `indicator_update_candle` (new): chunks the fuzz `f64` stream into `[open, high, low, close, volume]` tuples, builds candles via `Candle::new` (skipping ones that fail OHLCV validation — that path is fuzz-tested separately), then drives every candle-input indicator through streaming + batch. Covers ATR, NATR, TrueRange, ChaikinVolatility, Keltner, Donchian, PSAR, SuperTrend, ChandelierExit, ChandeKrollStop, ATRTrailingStop, ADX, Aroon, AroonOscillator, Vortex, MassIndex, ChoppinessIndex, CCI, WilliamsR, AwesomeOscillator, AcceleratorOscillator, UltimateOscillator, BalanceOfPower, OBV, MFI, VWAP, RollingVWAP, VWMA, ADL, VPT, CMF, ChaikinOscillator, ForceIndex, EaseOfMovement, TypicalPrice, MedianPrice, WeightedClose, Stochastic. - `fuzz/Cargo.toml` registers the new target; `fuzz/README.md` describes both expanded targets. - A `fuzz-smoke` CI job runs each of the five targets for 30 s on every push and pull-request — enough to catch a regression in the harness without slowing CI to a crawl. Long fuzz campaigns belong on dedicated infrastructure with persistent corpora. |
||
|
kingchenc
|
0995f8d66a |
fix(psar): correct is_ready convention and use NaN sentinels (R6, B-Opus-1)
`Psar::is_ready` previously returned `self.initialised`, which flips to
`true` *after* the seed candle — but the seed candle itself returns
`None`. The contract every other indicator honours is
`is_ready() == true` ↔ "the most recent update produced (or could
produce) a real value". Streaming consumers writing
`if ind.is_ready() { use(ind.update(c)?) }` would hit an unexpected
`None` on the first post-seed update.
Fix: add a `has_emitted: bool` field that flips on the first
`Some(sar)` return; `is_ready` now reads that. New test
`is_ready_only_after_first_some_value` pins the contract.
While in the same file, `reset()` is corrected to restore the compute
fields (`prev_high`, `prev_low`, `sar`, `ep`) to `f64::NAN` sentinels
instead of `0.0` (Opus bonus finding). The fields are gated by
`initialised` today, so the `0.0` sentinel never leaked into output —
but a future refactor that read them pre-init would have silently
treated `0.0` as a real price. A `debug_assert!` at the read site makes
the invariant explicit and catches a re-introduction of the bug in
debug builds.
Bit-equivalence with the previous behaviour is preserved
(`reset_allows_clean_reuse` and `batch_equals_streaming` continue to
pass unchanged).
|
||
|
kingchenc
|
a530f1b4cb |
perf(ulcer-index): track trailing max with a monotone deque (R1, B-Opus-2)
`UlcerIndex::update` previously scanned the full `period`-window every tick via `prices.iter().fold(NEG_INFINITY, f64::max)`, breaking the `Indicator` trait's O(1) contract. For long windows (e.g. period 50+ on a live tick stream) this turned a constant-time update into an O(period) one, and full-history batch replays into O(n · period). The window of raw prices is replaced with a monotonically-decreasing deque of `(index, price)` pairs. On every push, all back entries `<= input` are popped (they can never be the trailing max again, since they are dominated and at least as old). On every step, the front is popped if its index is older than `count - period + 1`. The deque's front is therefore always the trailing max in O(1). `count: u64` is the 1-based input counter that drives expiration; on `reset()` it returns to zero alongside the deque and the drawdown state. Behaviour is unchanged: same per-tick values, same warmup (`2 * period - 1`), same non-finite-input semantics. A new test `monotone_deque_matches_naive_max_on_adversarial_inputs` compares the deque output bar-by-bar against an independent O(n) trailing-max scan on inputs designed to hit every code path: strictly increasing (full tail pops), strictly decreasing (head expirations only), constants (the `<= input` pop rule keeps a single newest entry), and a sawtooth. The doc comment on `warmup_period()` is also corrected (B-Opus-2): the two windows overlap by one bar, so the formula is `2 * period - 1`, not `2 * period`. |
||
|
kingchenc
|
efcd6216c1 |
feat(bindings): expose RollingVWAP in Python, Node and WASM (R4)
The rolling-window VWAP indicator (`wickra_core::RollingVwap`) was only available in the Rust crate, even though the README's Volume-family table already advertised "VWAP (cumulative + rolling)" as a cross- language feature. Users on Python, Node or in the browser had to fall back to the cumulative `VWAP` or re-implement the rolling variant themselves. This commit closes the gap end-to-end: - Python: `wickra.RollingVWAP(period)` — same constructor / `update` / `batch` / `reset` / `is_ready` / `warmup_period` surface as `VWAP`, plus a `period` property and a typed `__repr__`. The `__init__.py` re-exports it and `__all__` lists it; the `.pyi` stub matches. - Node: `RollingVWAP(period)` — napi class with the same lifecycle, exported from `index.js` and declared in `index.d.ts`. - WASM: `RollingVWAP(period)` — wasm-bindgen class with the same `Float64Array` I/O as `VWAP`. Tests added: - Python: `test_rolling_vwap_streaming_matches_batch` — exercises `update == batch` plus the full lifecycle on the shared OHLC fixture. - Node: `RollingVWAP` row in the `candleScalar` parity table — covered by the generic streaming-vs-batch + lifecycle harness. - WASM: dedicated `wasm-bindgen-test` mirrors the Python test. The wiki page `Indicator-Vwap.md` drops the "Rust-only" caveat and gains Python / Node / WASM examples. |
||
|
kingchenc
|
3a6b5ebae3 |
feat(wasm): expose streaming update/isReady/warmupPeriod for 12 candle indicators (R3, R8)
Twelve WASM classes previously exposed only `batch()` (and not even
`reset()` for ten of them): ADX, WilliamsR, CCI, MFI, PSAR, Keltner,
Donchian, VWAP, AwesomeOscillator, Aroon, Stochastic, OBV. Browser
consumers wanting per-tick updates had to replay `batch()` on every new
candle — the opposite of the library's streaming-first promise.
Each class now exposes:
- `update(...)` — per-tick streaming update with the same column inputs
as `batch()`. Single-output indicators return `Option<f64>`. Multi-
output indicators (ADX, Keltner, Donchian, Aroon, Stochastic) return a
named JS object (`{ plusDi, minusDi, adx }`, `{ upper, middle, lower }`,
`{ up, down }`, `{ k, d }`) once warm, or `null` during warmup. This
matches the existing `SuperTrend` convention so JS code can treat all
multi-output WASM indicators uniformly.
- `reset()`, `isReady()`, `warmupPeriod()` — bring the lifecycle API to
full parity with Python and Node.
`WasmKama` also gains the previously missing `warmupPeriod()` (R8). A
single new `wasm-bindgen-test` exercises every newly wired class against
a deterministic 40-bar synthetic OHLCV stream, asserting that
streaming `update` matches `batch` value-by-value and that the lifecycle
contract behaves the same as the core indicator.
|
||
|
kingchenc
|
c99cf54a1f |
fix(security): upgrade pyo3 and numpy to 0.28, fix RUSTSEC-2025-0020
Bumps the Python binding from pyo3 0.22 / numpy 0.22 to 0.28 / 0.28, which resolves RUSTSEC-2025-0020 — a buffer overflow in `PyString::from_object` that affected every published Python wheel. Migration: - `into_pyarray_bound(py)` → `into_pyarray(py)` (numpy 0.23 dropped the `_bound` transitional suffix; the method now returns `Bound<'py, _>` directly). - `downcast::<PyDict>` → `cast::<PyDict>` (pyo3 renamed the method on `PyAnyMethods`). - Every `#[pyclass]` declares `skip_from_py_object` to opt out of the now-deprecated automatic `FromPyObject` derive for `Clone` types. Indicators are stateful — silently extracting them by value-clone is never the intended FFI semantics. - Workspace clippy gains `unused_self = "allow"` on the python crate only: Python's `__repr__` protocol forces `&self` even for parameter- less indicators where the body does not read state. - `map_err` arms collapsed into a single `PyValueError` arm (clippy::match_same_arms). `deny.toml` no longer suppresses RUSTSEC-2025-0020; `cargo deny check` is green on advisories, bans, licenses and sources without exceptions. |
||
|
kingchenc
|
2bc6cc5505 |
docs: round out the docs for Z7's example additions
* examples/README.md — replace the single-row WASM section with a build block (one-time `wasm-pack` build), a serve note, and the full five-row table (`index`, `backtest`, `live_trading`, `multi_timeframe`, `parallel_assets`). * examples/wasm/README.md — new dedicated index for the WASM demos with the build and serve commands and a description of every file including the module worker companion. * CHANGELOG.md `[Unreleased]` gains three bullets: the Python and Node `fetch_btcusdt` siblings; the four new WASM browser demos; and the three new wiki pages from Z6 (TA-Lib-Migration, Cookbook, FAQ). |
||
|
kingchenc
|
8b4a847d24 |
docs(wiki): add Cookbook, TA-Lib migration table and FAQ
Three content gaps in the wiki: there was no migration story for users porting from TA-Lib, no strategy cookbook, and no FAQ. Add all three as self-contained pages and link them from Home.md's "Wiki contents". * docs/wiki/TA-Lib-Migration.md — full one-to-one mapping table from every common talib.X(...) call to the equivalent Wickra expression, plus a "what Wickra has that TA-Lib does not" / "what TA-Lib has that Wickra does not (yet)" delta. * docs/wiki/Cookbook.md — seven concrete strategy recipes (RSI mean reversion, MACD histogram crossover, Bollinger breakout, ADX-gated trend, multi-timeframe confirmation, SuperTrend trailing stop, Chain<EMA, RSI>) with Rust or Python snippets. * docs/wiki/FAQ.md — common questions on warmup, NaN handling, thread safety, installation, performance and comparing Wickra to TA-Lib / pandas-ta / talipp / finta. Also extend the [Unreleased] CHANGELOG entry that records the examples/<lang>/ restructure with the wiki additions; Home.md gains three new bullets under "Wiki contents". |
||
|
kingchenc
|
a1c646ae7c |
examples: move the bundled BTCUSDT datasets to a top-level examples/data/
The seven BTCUSDT OHLCV datasets used to live under crates/wickra/examples/data/, which buried them inside a Rust crate even though the Node backtest example and the upcoming Rust/Node/WASM example restructure need to reach them too. Move them to the workspace-level examples/data/ so every language's examples can resolve the same path. The bench (crates/wickra/benches/indicators.rs), the example_data integration test, fetch_btcusdt.rs and the Node backtest example all take the new ../../examples/data/ path; Data-Layer.md, examples/README.md and the CHANGELOG entry are updated to match. No data file content changes. |
||
|
kingchenc
|
91f24946a6 |
docs(changelog): record the example datasets and Timeframe constructors
Add the still-unreleased Z1/Z2 work to the [Unreleased] section: the seven real-BTCUSDT example datasets plus the fetch_btcusdt example, the Timeframe::minutes/hours/days constructors, and the switch of the indicator benchmarks from a synthetic series to the checked-in BTCUSDT dataset. |
||
|
kingchenc
|
d2f99efd78 |
F13c: restructure the indicator catalogue into eight families
The original taxonomy was four classical families plus a statistics group, with the F1-F12 expansion slotted in as sub-categories. This regroups the whole 71-indicator catalogue into eight top-level families, each with at least five members: Moving Averages (12), Momentum Oscillators (13), Trend & Directional (9), Price Oscillators (5), Volatility & Bands (12), Trailing Stops (5), Volume (9), Price Statistics (7). - Wiki: docs/wiki/indicators/ reorganised into eight family folders; all 71 indicator pages moved with `git mv`. Every internal cross-link is normalised to `../<family>/Indicator-X.md`, each page's `Family` field is set to its new family, and two pre-existing `../Indicator-Chaining.md` links (should have been `../../`) are corrected. A link check confirms every relative wiki link resolves. - Indicators-Overview.md fully rewritten around the eight families; Home.md indicator reference and the README family table follow suit. - Warmup-Periods.md gains the eight F13 indicators; CHANGELOG records the 46-indicator expansion (25 -> 71) and the eight-family taxonomy. - Tests: Node indicators.test.js and Python test_new_indicators.py cover all eight new indicators (Node 91/91, Python 117/117 green). cargo fmt + clippy (core/wickra/data/wasm/node) clean; 508 core tests, 25 data tests and 74 doctests green. |
||
|
kingchenc
|
2f3b5cc3be |
F-Abschluss: wire the Python package, refresh docs and extend the test suites
Finalises the F1-F12 indicator expansion (25 -> 63 indicators). - Python `wickra/__init__.py`: import and re-export all 63 indicators, grouped by family, with a matching `__all__`. The package previously exposed only the original 25 even though the compiled module and the `.pyi` stubs already carried the rest. - Docs: `Home.md` and `README.md` indicator counts and family tables updated to 63; `Indicators-Overview.md` already restructured per family in F10-F12; `Warmup-Periods.md` gains all 38 new indicators across the single- and multi-output tables (and the stale two-arg `Psar::new` example is corrected to three args); `CHANGELOG.md` `[Unreleased]` lists every new indicator by family. - Tests: `bindings/node/__tests__/indicators.test.js` covers all 63 indicators (streaming==batch plus four new reference-value checks), 80/80 green; new `bindings/python/tests/test_new_indicators.py` covers the 38 additions (streaming==batch, shapes, reference values, lifecycle), Python suite 105/105 green. - `bindings/node/index.js` regenerated by `napi build`. cargo fmt + clippy (core/wickra/data/wasm/node) clean; 454 core tests, 25 data tests, 66 doctests, 80 Node tests and 105 Python tests green; `cargo check -p wickra-wasm --tests` green. |
||
|
kingchenc
|
94cab88278 |
E3: add community health files
The repository had no contributor-facing documentation or automation config. Add the standard set: - CHANGELOG.md (Keep a Changelog format, 0.1.0-0.1.4 plus Unreleased) - CONTRIBUTING.md (build/test steps, change standards, PolyForm-NC note) - SECURITY.md (private reporting, supported versions) - CODE_OF_CONDUCT.md (Contributor Covenant 2.1) - .github/ISSUE_TEMPLATE (bug report, feature request, config) - .github/PULL_REQUEST_TEMPLATE.md - .github/dependabot.yml (cargo, npm, pip, github-actions — the last keeps the D1 SHA pins current) - .github/CODEOWNERS |