hypercube-cascade 1.0.0__tar.gz → 1.0.2__tar.gz

{hypercube_cascade-1.0.0 → hypercube_cascade-1.0.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: hypercube-cascade
-Version: 1.0.0
+Version: 1.0.2
 Summary: Python bindings for HypercubeCascade: frozen etalon transit + frozen reservoir orbit + HypercubeCNN on end state
 License-Expression: Apache-2.0
 Classifier: Development Status :: 5 - Production/Stable
@@ -25,34 +25,44 @@ Provides-Extra: test
 Requires-Dist: pytest>=7.0; extra == "test"
 Description-Content-Type: text/markdown
 
-# HypercubeCascade
-
-**HypercubeCascade** is for high-dimensional data that has no natural clock —
-spectra, sensor frames, packed images, stills. Those are the same kinds of
-static fields people usually feed a spatial CNN, an MLP, or a similar
-feed-forward stack. HypercubeCascade puts **two frozen hypercube
-preprocessors in series** in front of the CNN: first an **etalon transit**
-(the [HypercubeEtalon](https://github.com/dliptak001/HypercubeEtalon)
-mechanism — a deterministic wave swept across every vertex/antipode cavity of
-the cube), then a short **reservoir orbit** (the
-[HypercubeWTF](https://github.com/dliptak001/HypercubeWTF) mechanism — a
-frozen recurrent core driven by re-addressing the same field for T synthetic
-passes). A small
-[HypercubeCNN](https://github.com/dliptak001/HypercubeCNN) head trains on the
-**end state only**. The CNN never sees the original field — it sees what the
-transit and the orbit leave behind.
-
-That is the product idea: take a static field, pass it through two different
-frozen nonlinearities, and train a spatial readout on what remains. The aim is
-a preprocessor effective enough that the readout can be a single convolutional
-layer with a single channel and no pooling.
-
-This package is the **Python** surface for that product
+# Hypercube Cascade
+
+This package is the **Python** surface for HypercubeCascade
 (`import hypercube_cascade`).
 Full API reference: **[docs/Python_SDK.md](https://github.com/dliptak001/HypercubeCascade/blob/main/docs/Python_SDK.md)**.
 C++ integration guide: **[docs/CPP_SDK.md](https://github.com/dliptak001/HypercubeCascade/blob/main/docs/CPP_SDK.md)**.
 Project home: **[github.com/dliptak001/HypercubeCascade](https://github.com/dliptak001/HypercubeCascade)**.
 
+HypercubeCascade processes spatial data of the kind presented to a CNN.
+It is built from four core classes.
+
+The **Cascade** class wraps the other three and manages training and
+prediction.
+
+The other three form a pipeline: etalon → reservoir → readout.
+
+The **Exciter** class is a preprocessing stage that consumes input
+patterns, mixes them nonlinearly, and returns a field with the same
+dimensions as the input.
+
+The **Reservoir** class is a second preprocessing stage that consumes
+that field, drives a short synthetic orbit on a frozen hypercube
+reservoir, and returns a field with the same dimensions.
+
+The **Readout** class is a small HypercubeCNN that classifies or
+regresses that field.
+
+This is reservoir computing, but not only reservoir computing.
+
+The point of this experiment is to see if two preprocessing stages in
+front of HypercubeCNN outperform HypercubeCNN by itself, and
+outperform either stage alone. HypercubeEtalon is the etalon alone.
+HypercubeWTF is the reservoir alone. Cascade runs them in series.
+The aim is a hypercube preprocessor effective enough that the readout
+can be a single layer with a single convolutional channel and no
+pooling. Then training is fast, the memory footprint is small, and
+little to no architectural engineering is required for the CNN.
+
 ---
 
 <p align="center">
@@ -82,97 +92,137 @@ as a first-class computational substrate.
 
 - **A topology you don’t store** — the graph is specified: connectivity is
   implicit in the vertex indices; with a seed and a few config scalars the whole
-  preprocessor reconstructs mathematically.
+  reservoir reconstructs mathematically.
 - **Perfect homogeneity** — every vertex has the same degree and the same local
   world, so local dynamics mean the same thing everywhere — no structural
   favorites baked in by a random graph.
 - **Cheap navigation** — each neighbor is a few bit operations on the vertex
   index, not a pointer chase through a stored edge list, so walks stay
   arithmetic and cache-friendly.
-- **Topology-native pairing** — the readout consumes the preprocessor output
-  with zero geometric distortion, and the learned kernels exploit the same
-  locality that generated the dynamics. The data never leaves the hypercube it
-  was born on.
+- **Topology-native pairing** — the readout consumes the reservoir’s output with
+  zero geometric distortion, and the learned kernels exploit the same locality
+  that generated the dynamics. The data never leaves the hypercube it was born
+  on.
 
 Each product in the family is a different architecture on that same foundation.
 
 ---
 
-## What is HypercubeCascade?
+## The Cascade
 
-[HypercubeEtalon](https://github.com/dliptak001/HypercubeEtalon) preprocesses a
-static field with **one etalon transit**.
-[HypercubeWTF](https://github.com/dliptak001/HypercubeWTF) preprocesses a
-static field with **one reservoir orbit**. HypercubeCascade is **both of them,
-in series, on one cube**: the transit output, times a gain, becomes the orbit
-drive, and the orbit's end state, times a second gain, is what the CNN head
-trains on.
+HypercubeEtalon and HypercubeWTF are two examples of how
+solutions can be built on that substrate. Cascade is both of them, in
+series, on one cube.
 
-In classical reservoir computing (and in both single-stage siblings):
+There is one cube dimension. The Exciter, the Reservoir, and the
+Readout all use it.
 
-- Preprocessor weights are **frozen**
-- Only a **readout** is trained
-- Nonlinear dynamics expand and mix the drive into a rich state
+An etalon, here, is a vertex and its antipode treated as a reflective
+cavity. The Exciter walks every such cavity and writes one output
+sample per start. That walk is the etalon transit. The write-up is
+[HypercubeEtalon](https://github.com/dliptak001/HypercubeEtalon).
 
-Whether the two-stage pipeline has **real product value** is still an open
-question. Early studies suggest the second stage adds filtering on top of what
-the first stage already adds (see
-[Early observations](#early-observations-exploratory)).
+The Reservoir is the HypercubeWTF encoder: frozen recurrent weights,
+a delay line, and a short synthetic orbit. Geometry stays put; the
+registration of the field moves. The write-up is
+[HypercubeWTF](https://github.com/dliptak001/HypercubeWTF).
 
----
+The cascade itself goes something like this.
 
-## Pipeline
-
-```text
-x  (your length-N field — already on the cube, no natural time)
-    │
-    ▼
- frozen etalon transit (one wave over every cavity)
-    │
-    ▼
- × interstage_scale → frozen reservoir orbit (T re-addressed passes)
-    │
-    ▼
- end-of-orbit state × readout_scale → HypercubeCNN → logits / values
-```
+    Copy the input field. Never write the caller's buffer.
+
+    Run one etalon transit. The cube is the same size it started as.
+
+    Multiply that field by the interstage gain.
+
+    Reload the reservoir's frozen start.
+
+    LOOP:
+
+        Remap the scaled field by xor with the pass index.
+
+        Inject that remapping. Step the reservoir.
+
+    GOTO LOOP
+
+    After T passes, the reservoir's live output is the feature field.
+    That is what the Readout sees.
+
+The single-stage write-ups live with the siblings. This repository is
+the two-stage host.
+
+---
 
-- Cube size from **dim** (N = 2<sup>dim</sup>; dim 5…12). One dim serves all
-  three stages.
-- Only the readout trains.
-- Everyday loop in this package:
-  `collect_batch` → `train` → `predict` / `predict_class`,
-  or one-shot `fit` (collect + train).
+## White noise filter
 
-Unlike HypercubeESN’s Python API, there is no stream of small samples over real
-time and no next-step `fit` on a 1D signal. Each sample is one full field; the
-“time” is the short synthetic orbit; the CNN only ever sees the state at the end.
+The Cascade preprocessor behaves as a near unity passthrough at low
+to no white noise levels, and offers meaningful filtering effect
+at moderate to high noise levels. The write-up is
+[`examples/mnist/WhiteNoiseFilter.md`](https://github.com/dliptak001/HypercubeCascade/blob/main/examples/mnist/WhiteNoiseFilter.md).
 
-Full method list and knobs:
-**[docs/Python_SDK.md](https://github.com/dliptak001/HypercubeCascade/blob/main/docs/Python_SDK.md)**.
+![MNIST test noise: cascade vs etalon transit vs Bypass](https://raw.githubusercontent.com/dliptak001/HypercubeCascade/main/examples/mnist/cascade_mnist_noise_comp.png)
 
 ---
 
-## Early observations (exploratory)
-
-On the MNIST white-noise study (train clean, test with Gaussian field noise),
-the cascade behaves as a near-unity passthrough on clean fields and pulls
-ahead of both the etalon-only path and the pack-only bypass from σ = 0.3
-upward. On a Raman baseline-extraction regression it matches the etalon-only
-sibling to within ~1% RMSE while training with a visibly more stable epoch
-profile. The write-ups have the details and how we ran them:
-
-| Document | Question |
-|----------|----------|
-| [WhiteNoiseFilter.md](https://github.com/dliptak001/HypercubeCascade/blob/main/examples/mnist/WhiteNoiseFilter.md) | Noisy test fields: do two stages help vs one stage vs pack-only → CNN? |
-| [RamanBaselineExtraction/README.md](https://github.com/dliptak001/HypercubeCascade/blob/main/examples/RamanBaselineExtraction/README.md) | Baseline regression: cascade vs etalon-only, overlays and training profiles |
-
-The MNIST study uses small cubes because they are handy to pack and run, not
-because we are chasing digit accuracy. A more rigorous study is still needed
-before treating any of those results as settled. You can reproduce the same
-ideas from Python with this package (pack fields yourself, then collect,
-train, and predict). The original write-ups and C++ demos that produced the
-numbers live under
-[`examples/`](https://github.com/dliptak001/HypercubeCascade/tree/main/examples).
+## Raman baseline extraction (a vibrational spectroscopy application)
+
+The first real-world test is Raman spectra: recover the slow
+fluorescence background under sharp molecular peaks without
+lifting the baseline into the bands or cutting trenches beneath
+them. Polynomials, asymmetric least squares, and ordinary
+convolutional nets tend to follow the empty stretches well and then
+fail where it matters, under peaks and peak clusters. Analysts have
+worked around that for decades with spectrum-specific cleanup,
+because no method identifies and extracts a true baseline across a
+broad range of peak intensities and baseline characteristics
+without occasional, and often frequent, human intervention.
+
+The Cascade appears to have solved that problem (albeit on synthetic
+data only so far).
+
+Trained for 60 epochs on the LCOHard set — 10,000 synthetic LiCoO₂
+(lithium cobalt oxide) spectra — it scores a validation RMSE of
+4.82 counts on 2,000 held-out spectra whose baselines span
+hundreds of counts.
+
+Below are four held-out validation spectra: grey is the raw
+spectrum, red the true baseline, blue the extract. For all four
+shown here, and for each of the remaining 1996 validation spectra
+not shown, baseline identification is, **WITHOUT EXCEPTION**,
+quite remarkable.
+
+And it does this with the thin readout the project aims for: one
+HypercubeCNN layer, one convolutional channel, no pooling.
+
+In our judgment this at least matches the best of the established
+techniques on spectra like these, and very likely beats them.
+
+![Held-out validation extract, spectra 581 through 584](https://raw.githubusercontent.com/dliptak001/HypercubeCascade/main/examples/RamanBaselineExtraction/extracted_baselines_cascade.png)
+
+### Etalon sets the bar. Cascade raises it (well, maybe).
+
+The etalon-only sibling
+([HypercubeEtalon](https://github.com/dliptak001/HypercubeEtalon))
+is this Cascade with the reservoir removed, and on its own it
+already does everything described above. With the very same
+Exciter and readout configuration, its overlays are
+indistinguishable from the ones shown.
+
+Real spectra, however, are not nearly this clean. Low laser power,
+short integration times, and weak scatterers all put noise on the
+spectrum, and that is where a baseline extractor has to earn its
+keep.
+
+That is what the Cascade's second stage, the Reservoir, is for. On
+the strength of the MNIST white-noise study
+([`examples/mnist/WhiteNoiseFilter.md`](https://github.com/dliptak001/HypercubeCascade/blob/main/examples/mnist/WhiteNoiseFilter.md)),
+the Cascade is expected to outperform the Etalon alone in that
+noise.
+
+That is the next experiment.
+
+Side-by-side overlays and both training profiles are in
+[`examples/RamanBaselineExtraction/`](https://github.com/dliptak001/HypercubeCascade/blob/main/examples/RamanBaselineExtraction/README.md).
 
 ---
 

{hypercube_cascade-1.0.0 → hypercube_cascade-1.0.2}/README.md

@@ -1,31 +1,41 @@
-# HypercubeCascade
-
-**HypercubeCascade** is for high-dimensional data that has no natural clock —
-spectra, sensor frames, packed images, stills. Those are the same kinds of
-static fields people usually feed a spatial CNN, an MLP, or a similar
-feed-forward stack. HypercubeCascade puts **two frozen hypercube
-preprocessors in series** in front of the CNN: first an **etalon transit**
-(the [HypercubeEtalon](https://github.com/dliptak001/HypercubeEtalon)
-mechanism — a deterministic wave swept across every vertex/antipode cavity of
-the cube), then a short **reservoir orbit** (the
-[HypercubeWTF](https://github.com/dliptak001/HypercubeWTF) mechanism — a
-frozen recurrent core driven by re-addressing the same field for T synthetic
-passes). A small
-[HypercubeCNN](https://github.com/dliptak001/HypercubeCNN) head trains on the
-**end state only**. The CNN never sees the original field — it sees what the
-transit and the orbit leave behind.
-
-That is the product idea: take a static field, pass it through two different
-frozen nonlinearities, and train a spatial readout on what remains. The aim is
-a preprocessor effective enough that the readout can be a single convolutional
-layer with a single channel and no pooling.
-
-This package is the **Python** surface for that product
+# Hypercube Cascade
+
+This package is the **Python** surface for HypercubeCascade
 (`import hypercube_cascade`).
 Full API reference: **[docs/Python_SDK.md](https://github.com/dliptak001/HypercubeCascade/blob/main/docs/Python_SDK.md)**.
 C++ integration guide: **[docs/CPP_SDK.md](https://github.com/dliptak001/HypercubeCascade/blob/main/docs/CPP_SDK.md)**.
 Project home: **[github.com/dliptak001/HypercubeCascade](https://github.com/dliptak001/HypercubeCascade)**.
 
+HypercubeCascade processes spatial data of the kind presented to a CNN.
+It is built from four core classes.
+
+The **Cascade** class wraps the other three and manages training and
+prediction.
+
+The other three form a pipeline: etalon → reservoir → readout.
+
+The **Exciter** class is a preprocessing stage that consumes input
+patterns, mixes them nonlinearly, and returns a field with the same
+dimensions as the input.
+
+The **Reservoir** class is a second preprocessing stage that consumes
+that field, drives a short synthetic orbit on a frozen hypercube
+reservoir, and returns a field with the same dimensions.
+
+The **Readout** class is a small HypercubeCNN that classifies or
+regresses that field.
+
+This is reservoir computing, but not only reservoir computing.
+
+The point of this experiment is to see if two preprocessing stages in
+front of HypercubeCNN outperform HypercubeCNN by itself, and
+outperform either stage alone. HypercubeEtalon is the etalon alone.
+HypercubeWTF is the reservoir alone. Cascade runs them in series.
+The aim is a hypercube preprocessor effective enough that the readout
+can be a single layer with a single convolutional channel and no
+pooling. Then training is fast, the memory footprint is small, and
+little to no architectural engineering is required for the CNN.
+
 ---
 
 <p align="center">
@@ -55,97 +65,137 @@ as a first-class computational substrate.
 
 - **A topology you don’t store** — the graph is specified: connectivity is
   implicit in the vertex indices; with a seed and a few config scalars the whole
-  preprocessor reconstructs mathematically.
+  reservoir reconstructs mathematically.
 - **Perfect homogeneity** — every vertex has the same degree and the same local
   world, so local dynamics mean the same thing everywhere — no structural
   favorites baked in by a random graph.
 - **Cheap navigation** — each neighbor is a few bit operations on the vertex
   index, not a pointer chase through a stored edge list, so walks stay
   arithmetic and cache-friendly.
-- **Topology-native pairing** — the readout consumes the preprocessor output
-  with zero geometric distortion, and the learned kernels exploit the same
-  locality that generated the dynamics. The data never leaves the hypercube it
-  was born on.
+- **Topology-native pairing** — the readout consumes the reservoir’s output with
+  zero geometric distortion, and the learned kernels exploit the same locality
+  that generated the dynamics. The data never leaves the hypercube it was born
+  on.
 
 Each product in the family is a different architecture on that same foundation.
 
 ---
 
-## What is HypercubeCascade?
+## The Cascade
 
-[HypercubeEtalon](https://github.com/dliptak001/HypercubeEtalon) preprocesses a
-static field with **one etalon transit**.
-[HypercubeWTF](https://github.com/dliptak001/HypercubeWTF) preprocesses a
-static field with **one reservoir orbit**. HypercubeCascade is **both of them,
-in series, on one cube**: the transit output, times a gain, becomes the orbit
-drive, and the orbit's end state, times a second gain, is what the CNN head
-trains on.
+HypercubeEtalon and HypercubeWTF are two examples of how
+solutions can be built on that substrate. Cascade is both of them, in
+series, on one cube.
 
-In classical reservoir computing (and in both single-stage siblings):
+There is one cube dimension. The Exciter, the Reservoir, and the
+Readout all use it.
 
-- Preprocessor weights are **frozen**
-- Only a **readout** is trained
-- Nonlinear dynamics expand and mix the drive into a rich state
+An etalon, here, is a vertex and its antipode treated as a reflective
+cavity. The Exciter walks every such cavity and writes one output
+sample per start. That walk is the etalon transit. The write-up is
+[HypercubeEtalon](https://github.com/dliptak001/HypercubeEtalon).
 
-Whether the two-stage pipeline has **real product value** is still an open
-question. Early studies suggest the second stage adds filtering on top of what
-the first stage already adds (see
-[Early observations](#early-observations-exploratory)).
+The Reservoir is the HypercubeWTF encoder: frozen recurrent weights,
+a delay line, and a short synthetic orbit. Geometry stays put; the
+registration of the field moves. The write-up is
+[HypercubeWTF](https://github.com/dliptak001/HypercubeWTF).
 
----
+The cascade itself goes something like this.
 
-## Pipeline
-
-```text
-x  (your length-N field — already on the cube, no natural time)
-    │
-    ▼
- frozen etalon transit (one wave over every cavity)
-    │
-    ▼
- × interstage_scale → frozen reservoir orbit (T re-addressed passes)
-    │
-    ▼
- end-of-orbit state × readout_scale → HypercubeCNN → logits / values
-```
+    Copy the input field. Never write the caller's buffer.
+
+    Run one etalon transit. The cube is the same size it started as.
+
+    Multiply that field by the interstage gain.
+
+    Reload the reservoir's frozen start.
+
+    LOOP:
+
+        Remap the scaled field by xor with the pass index.
+
+        Inject that remapping. Step the reservoir.
+
+    GOTO LOOP
+
+    After T passes, the reservoir's live output is the feature field.
+    That is what the Readout sees.
+
+The single-stage write-ups live with the siblings. This repository is
+the two-stage host.
+
+---
 
-- Cube size from **dim** (N = 2<sup>dim</sup>; dim 5…12). One dim serves all
-  three stages.
-- Only the readout trains.
-- Everyday loop in this package:
-  `collect_batch` → `train` → `predict` / `predict_class`,
-  or one-shot `fit` (collect + train).
+## White noise filter
 
-Unlike HypercubeESN’s Python API, there is no stream of small samples over real
-time and no next-step `fit` on a 1D signal. Each sample is one full field; the
-“time” is the short synthetic orbit; the CNN only ever sees the state at the end.
+The Cascade preprocessor behaves as a near unity passthrough at low
+to no white noise levels, and offers meaningful filtering effect
+at moderate to high noise levels. The write-up is
+[`examples/mnist/WhiteNoiseFilter.md`](https://github.com/dliptak001/HypercubeCascade/blob/main/examples/mnist/WhiteNoiseFilter.md).
 
-Full method list and knobs:
-**[docs/Python_SDK.md](https://github.com/dliptak001/HypercubeCascade/blob/main/docs/Python_SDK.md)**.
+![MNIST test noise: cascade vs etalon transit vs Bypass](https://raw.githubusercontent.com/dliptak001/HypercubeCascade/main/examples/mnist/cascade_mnist_noise_comp.png)
 
 ---
 
-## Early observations (exploratory)
-
-On the MNIST white-noise study (train clean, test with Gaussian field noise),
-the cascade behaves as a near-unity passthrough on clean fields and pulls
-ahead of both the etalon-only path and the pack-only bypass from σ = 0.3
-upward. On a Raman baseline-extraction regression it matches the etalon-only
-sibling to within ~1% RMSE while training with a visibly more stable epoch
-profile. The write-ups have the details and how we ran them:
-
-| Document | Question |
-|----------|----------|
-| [WhiteNoiseFilter.md](https://github.com/dliptak001/HypercubeCascade/blob/main/examples/mnist/WhiteNoiseFilter.md) | Noisy test fields: do two stages help vs one stage vs pack-only → CNN? |
-| [RamanBaselineExtraction/README.md](https://github.com/dliptak001/HypercubeCascade/blob/main/examples/RamanBaselineExtraction/README.md) | Baseline regression: cascade vs etalon-only, overlays and training profiles |
-
-The MNIST study uses small cubes because they are handy to pack and run, not
-because we are chasing digit accuracy. A more rigorous study is still needed
-before treating any of those results as settled. You can reproduce the same
-ideas from Python with this package (pack fields yourself, then collect,
-train, and predict). The original write-ups and C++ demos that produced the
-numbers live under
-[`examples/`](https://github.com/dliptak001/HypercubeCascade/tree/main/examples).
+## Raman baseline extraction (a vibrational spectroscopy application)
+
+The first real-world test is Raman spectra: recover the slow
+fluorescence background under sharp molecular peaks without
+lifting the baseline into the bands or cutting trenches beneath
+them. Polynomials, asymmetric least squares, and ordinary
+convolutional nets tend to follow the empty stretches well and then
+fail where it matters, under peaks and peak clusters. Analysts have
+worked around that for decades with spectrum-specific cleanup,
+because no method identifies and extracts a true baseline across a
+broad range of peak intensities and baseline characteristics
+without occasional, and often frequent, human intervention.
+
+The Cascade appears to have solved that problem (albeit on synthetic
+data only so far).
+
+Trained for 60 epochs on the LCOHard set — 10,000 synthetic LiCoO₂
+(lithium cobalt oxide) spectra — it scores a validation RMSE of
+4.82 counts on 2,000 held-out spectra whose baselines span
+hundreds of counts.
+
+Below are four held-out validation spectra: grey is the raw
+spectrum, red the true baseline, blue the extract. For all four
+shown here, and for each of the remaining 1996 validation spectra
+not shown, baseline identification is, **WITHOUT EXCEPTION**,
+quite remarkable.
+
+And it does this with the thin readout the project aims for: one
+HypercubeCNN layer, one convolutional channel, no pooling.
+
+In our judgment this at least matches the best of the established
+techniques on spectra like these, and very likely beats them.
+
+![Held-out validation extract, spectra 581 through 584](https://raw.githubusercontent.com/dliptak001/HypercubeCascade/main/examples/RamanBaselineExtraction/extracted_baselines_cascade.png)
+
+### Etalon sets the bar. Cascade raises it (well, maybe).
+
+The etalon-only sibling
+([HypercubeEtalon](https://github.com/dliptak001/HypercubeEtalon))
+is this Cascade with the reservoir removed, and on its own it
+already does everything described above. With the very same
+Exciter and readout configuration, its overlays are
+indistinguishable from the ones shown.
+
+Real spectra, however, are not nearly this clean. Low laser power,
+short integration times, and weak scatterers all put noise on the
+spectrum, and that is where a baseline extractor has to earn its
+keep.
+
+That is what the Cascade's second stage, the Reservoir, is for. On
+the strength of the MNIST white-noise study
+([`examples/mnist/WhiteNoiseFilter.md`](https://github.com/dliptak001/HypercubeCascade/blob/main/examples/mnist/WhiteNoiseFilter.md)),
+the Cascade is expected to outperform the Etalon alone in that
+noise.
+
+That is the next experiment.
+
+Side-by-side overlays and both training profiles are in
+[`examples/RamanBaselineExtraction/`](https://github.com/dliptak001/HypercubeCascade/blob/main/examples/RamanBaselineExtraction/README.md).
 
 ---
 

{hypercube_cascade-1.0.0 → hypercube_cascade-1.0.2}/hypercube_cascade/_version.py

@@ -2,4 +2,4 @@
 # - pyproject.toml reads this via scikit-build-core dynamic metadata
 # - hypercube_cascade.__version__ imports it
 # - bindings.cpp gets the same string at compile time via CMake
-__version__ = "1.0.0"
+__version__ = "1.0.2"