scientific-computing-system 2.2.4__tar.gz → 2.2.6__tar.gz

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/CHANGELOG.md

@@ -5,6 +5,31 @@ All notable changes to **scientific-computing-system** will be documented in thi
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [v2.2.6] - 2026-10-13
+
+### Housekeeping — second-round neighbour sweep
+
+- `transpose` shares the ragged-input contract the rest of the matrix API has
+  held since 2.2.5. It indexed only the leading row's width, so a short row
+  lost entries silently (`[[1.0],[2.0,3.0]]` became `[[1.0, 2.0]]`): the
+  result described a matrix nobody supplied. It now fails closed through the
+  same `_require_rectangular` check `mat_mul` and Cholesky use.
+- Geometric PMF boundary pinned: `geometric_pmf(0, p)` is 0 (no trial counted
+  1-based), and extreme `(k, p)` stays finite.
+- `poisson_pmf(0, 0)` is 1 and the log-space PMFs were probed at their
+  previously-crashing inputs; no remaining overflow class found in the
+  probability module.
+
+## [v2.2.5] - 2026-10-12
+
+### Housekeeping — audit hardening
+
+- Closes the findings of the full-repository audit: patched the concrete
+  defects (correctness, fail-closed behaviour, platform independence),
+  wired every standalone guard into CI, removed dead or duplicated code
+  paths, and pinned every doc claim to a test so it cannot silently
+  drift again. Regression tests fail without the corresponding fix.
+
 ## [Unreleased]
 
 ### Distribution status of 2.2.2 — read this before assuming npm has it

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/CITATION.cff

@@ -5,7 +5,7 @@ title: "scientific-computing-system"
 # Keep `version` in lockstep with pyproject.toml [project].version and
 # src/cds/_version.py. scripts/check_version_discipline.py and
 # scripts/check_version_lockstep.py enforce this.
-version: 2.2.4
+version: 2.2.6
 authors:
   - name: "Furox-Art"
     email: "furkanarkn1451@gmail.com"
@@ -50,5 +50,5 @@ preferred-citation:
   authors:
     - name: "Furox-Art"
   year: 2026
-  version: 2.2.4
+  version: 2.2.6
   url: "https://github.com/Furox-Art/scientific-computing-system"

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: scientific-computing-system
-Version: 2.2.4
+Version: 2.2.6
 Summary: A pure-Python computational science platform for numerical methods, modeling, validation, uncertainty, scientific workflows, dimensional analysis, and optional research-data backends. Zero runtime dependencies.
 Project-URL: Homepage, https://github.com/Furox-Art/scientific-computing-system
 Project-URL: Repository, https://github.com/Furox-Art/scientific-computing-system

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/benchmarks/run_benchmarks.py

@@ -18,7 +18,6 @@ report stays deterministic.
 
 import json
 import math
-import multiprocessing
 import subprocess
 import time
 import timeit
@@ -199,12 +198,12 @@ def bench_montecarlo() -> OrderedDict[str, str]:
 
     start = time.perf_counter()
     result = estimate_pi(samples, seed=42)
-    t_parallel = time.perf_counter() - start
+    elapsed = time.perf_counter() - start
 
     return OrderedDict(
         [
-            ("Parallel Pi (100k samples)", f"{t_parallel:.4f}s"),
-            ("CPU Cores Saturated", str(multiprocessing.cpu_count())),
+            ("Pi (100k samples)", f"{elapsed:.4f}s"),
+            ("Sampling mode", "single in-process random.Random stream"),
             ("Estimate error vs π", f"{abs(result.estimate - math.pi):.5f}"),
         ]
     )

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/codemeta.json

@@ -2,7 +2,7 @@
   "@context": "https://doi.org/10.5063/schema/codemeta-2.0",
   "@type": "SoftwareSourceCode",
   "name": "scientific-computing-system",
-  "version": "2.2.4",
+  "version": "2.2.6",
   "description": "Pure-Python computational science platform for numerical methods, modeling, validation, uncertainty, and scientific workflows. Zero runtime dependencies. This is the front door; scientific-computing-system-2.0 is the NumPy build of the same work.",
   "license": "https://spdx.org/licenses/MIT",
   "codeRepository": "https://github.com/Furox-Art/scientific-computing-system",

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/docs/benchmarks.md

@@ -59,7 +59,9 @@ number from this page.**
   of why O(1) sampling is the right design, not as a benchmark result.
 - **"CPU Cores Saturated" is a core count, not a saturation measurement.** It
   reports `multiprocessing.cpu_count()`. Nothing here verifies that every core
-  stayed busy or that the workload actually scaled.
+  stayed busy or that the workload actually scaled. The Monte Carlo table no
+  longer carries that row: `estimate_pi` samples on one in-process stream, so
+  a core count would be meaningless there.
 - **The generated section headers describe algorithms, not outcomes.** Strings
   like "Algorithmic Intelligence", "Approaching C-Speed" and "Hardware
   Saturation" come from the generator, not from the data. The first table's
@@ -109,10 +111,22 @@ This report measures both raw speed and algorithmic scaling. Pure Python is slow
 
 | Metric | Value |
 |--------|-------|
-| Parallel Pi (100k samples) | 0.0388s |
-| CPU Cores Saturated | 4 |
+| Pi (100k samples) | 0.0388s |
 | Estimate error vs π | 0.00791 |
 
+The timing above is the committed pre-change measurement and is kept
+unchanged rather than re-measured, because re-running the generator would
+overwrite the hand-written analysis on this page. `estimate_pi` no longer fans
+its samples out to a process pool: on the pooled path, Windows `spawn` cost
+≈1.4 s of interpreter start-up and module re-import per default call against
+≈0.014 s of actual sampling — about 100× the work it was meant to accelerate.
+The estimator now draws its whole sample from one `random.Random(seed)`
+stream in a single in-process pass, which also makes a *seeded* call
+machine-independent (the old chunk boundaries were derived from
+`cpu_count()`, so the result differed between hosts). The row the generator
+emits is now `Sampling mode | single in-process random.Random stream` in
+place of `CPU Cores Saturated`.
+
 #### Quantum sampling (estimated)
 
 | Metric | Value |

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/docs/getting-started.md

@@ -69,6 +69,28 @@ cds hypothesis "what causes the Hubble tension?" --domain cosmology
 cds modules
 ```
 
+#### Exit codes
+
+`cds` exits with one of four documented statuses. They are named constants in
+`cds.cli._exit_codes`, re-exported from `cds.cli`, so a wrapper can compare
+statuses instead of comparing against bare integers.
+
+| Code | Name | Meaning |
+|------|------|---------|
+| `0` | `EXIT_OK` | The command completed and produced its output. Also returned by `--help`. |
+| `1` | `EXIT_ERROR` | The command was understood but could not be carried out: malformed values, an out-of-domain parameter, or a missing local resource such as the dashboard script. |
+| `2` | `EXIT_USAGE` | The command line was rejected by `argparse` — an unknown subcommand, a missing required argument, a bad `choices=` value, an unparseable number. (This is `argparse`'s own usage-error code.) |
+| `3` | `EXIT_MISSING_DEPENDENCY` | The command needs an optional extra that is not installed: `[plot]`/matplotlib for `plot --file`, `streamlit` for `dashboard`. The remedy is an install, not a corrected invocation. |
+
+```python
+from cds.cli import EXIT_ERROR, EXIT_MISSING_DEPENDENCY, describe, main
+
+describe(1)  # 'command was understood but could not be carried out'
+main(["stats", "1,x,3"])  # 1  — bad values
+main(["sample", "no-such-dist"])  # 2  — argparse rejected it
+main(["dashboard"])  # 3  — streamlit absent
+```
+
 ### Python API
 
 ```python

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/docs/index.md

@@ -135,6 +135,25 @@ public feature modules. This table summarises them and the
 | `cds.nlp` | Educational NLP from scratch (BPE, embeddings, attention, MiniGPT) |
 | `cds.cli` | The `cds` console script (pure-stdlib `argparse`) |
 
+## Import behaviour
+
+Every module in the table is reachable as `cds.<name>`:
+
+```python
+import cds
+
+cds.pde  # attribute access works
+cds.interpolate  # so does this
+from cds.pde import solve_heat  # and the direct import
+```
+
+`cds.pde` and `cds.interpolate` are **lazily** imported by the package root
+(PEP 562 module `__getattr__`). Accessing `cds.pde` imports the subpackage on
+first touch and caches it, so `cds.pde` and `import cds.pde` yield the very
+same module object while never putting a PDE solver on the import path of code
+that does not use one. Everything else in the table is imported eagerly by
+`cds/__init__.py`.
+
 ## Quick Navigation
 
 - [Getting Started](getting-started.md)

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/docs/tour_of_numerical_methods.md

@@ -64,7 +64,7 @@ n= 10,000  π≈3.1372  err=-4.39e-03  σ=1.65e-02
 n=100,000  π≈3.1292  err=-1.24e-02  σ=5.22e-03
 ```
 
-**The lesson.** Halving the standard error takes a **4×** larger sample, slow convergence. But notice the *standard error* tracks the actual error, and crucially the same recipe works in 100 dimensions where grid rules would need $100^{N}$ points. Monte Carlo trades speed for **generality**. CDS also parallelizes the sampling across CPU cores ([`montecarlo/methods.py`](https://github.com/Furox-Art/scientific-computing-system/blob/main/src/cds/montecarlo/methods.py)).
+**The lesson.** Halving the standard error takes a **4×** larger sample, slow convergence. But notice the *standard error* tracks the actual error, and crucially the same recipe works in 100 dimensions where grid rules would need $100^{N}$ points. Monte Carlo trades speed for **generality**. `estimate_pi` draws its whole sample from one `random.Random(seed)` stream in a single in-process pass ([`montecarlo/methods.py`](https://github.com/Furox-Art/scientific-computing-system/blob/main/src/cds/montecarlo/methods.py)), so a seeded call returns the same number on every machine and core count instead of a pool-schedule-dependent one.
 
 ---
 

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/package.json

@@ -1,6 +1,6 @@
 {
   "name": "scientific-computing-system",
-  "version": "2.2.4",
+  "version": "2.2.6",
   "description": "Scientific Computing System launcher - a thin Node wrapper that forwards to the pure-Python `cds` CLI. This npm package ships NO Python code: it requires the Python distribution to be installed (`pip install scientific-computing-system`), otherwise `scs` exits non-zero with an actionable message.",
   "main": "index.js",
   "bin": {

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/pyproject.toml

@@ -2,7 +2,7 @@
 # Distribution name. Formerly published as "cognitive-discovery-system";
 # the import name stays `cds`. Keep the old PyPI project alive as an alias.
 name = "scientific-computing-system"
-version = "2.2.4"
+version = "2.2.6"
 description = "A pure-Python computational science platform for numerical methods, modeling, validation, uncertainty, scientific workflows, dimensional analysis, and optional research-data backends. Zero runtime dependencies."
 readme = "README.md"
 license = "MIT"

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/src/cds/__init__.py

@@ -29,6 +29,11 @@ Usage:
     from cds.hypothesis import generate_hypotheses
 """
 
+from __future__ import annotations
+
+import importlib
+from types import ModuleType
+
 # Convenient top-level re-exports for common scientific tools
 # Core modules
 # Scientific computing modules
@@ -111,6 +116,7 @@ __all__ = [
     "graph",
     "hypothesis",
     "infotheory",
+    "interpolate",
     "knowledge",
     "math_utils",
     "ml",
@@ -119,6 +125,7 @@ __all__ = [
     "nlp",
     "numerical_integration",
     "optimization",
+    "pde",
     "plot",
     "probability",
     "provenance",
@@ -134,3 +141,30 @@ __all__ = [
     "wavelets",
     "workflow",
 ]
+
+
+# Subpackages published as ``cds.<name>`` but not part of the eager import
+# block above. ``cds.pde`` and ``cds.interpolate`` ship as their own
+# subpackages, so ``import cds.pde`` and ``from cds.pde import solve_heat``
+# always worked — but the flat package layout meant ``import cds`` alone never
+# bound the attribute, and ``cds.pde`` raised ``AttributeError`` even though
+# docs/index.md and docs/api.md both advertise it as public surface.
+#
+# The PEP 562 module ``__getattr__`` closes the gap without moving the two
+# solvers onto the import path of every ``cds`` user. The imported module is
+# cached in ``globals()`` so the lookup happens exactly once.
+_LAZY_SUBPACKAGES = frozenset({"interpolate", "pde"})
+
+
+def __getattr__(name: str) -> ModuleType:
+    """Lazily import a documented ``cds`` subpackage on first attribute access."""
+    if name in _LAZY_SUBPACKAGES:
+        module = importlib.import_module(f"cds.{name}")
+        globals()[name] = module
+        return module
+    raise AttributeError(f"module {__name__!r} has no attribute {name!r}")
+
+
+def __dir__() -> list[str]:
+    """Expose the lazily-imported subpackages to ``dir(cds)``."""
+    return sorted(set(globals()) | _LAZY_SUBPACKAGES)

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/src/cds/_version.py

@@ -5,5 +5,5 @@ from __future__ import annotations
 
 __all__ = ["__version__", "version", "__version_tuple__", "version_tuple"]
 
-__version__ = version = "2.2.4"
+__version__ = version = "2.2.6"
 __version_tuple__ = version_tuple = (2, 2, 0)

{scientific_computing_system-2.2.4 → scientific_computing_system-2.2.6}/src/cds/cli/__init__.py

@@ -12,6 +12,7 @@ The package is split for maintainability:
 - :mod:`cds.cli._handlers` — one function per computational subcommand
 - :mod:`cds.cli._system_info` — current architecture and module catalog
 - :mod:`cds.cli._parser` — argument-parser wiring
+- :mod:`cds.cli._exit_codes` — the named exit-code contract
 
 The entry point :func:`main` accepts an optional ``argv`` so tests can drive a
 specific command without spawning a subprocess, and returns the integer exit
@@ -23,6 +24,15 @@ from __future__ import annotations
 import sys
 from collections.abc import Sequence
 
+from cds.cli._exit_codes import (
+    EXIT_CODES,
+    EXIT_ERROR,
+    EXIT_MISSING_DEPENDENCY,
+    EXIT_OK,
+    EXIT_USAGE,
+    describe,
+    is_handler_code,
+)
 from cds.cli._handlers import (
     _cmd_benchmark,
     _cmd_calc,
@@ -78,6 +88,15 @@ __all__ = [
     "_cmd_sample",
     "_cmd_stats",
     "_cmd_version",
+    # The documented exit-code contract, re-exported so a caller can map a
+    # status without reaching into a private module.
+    "EXIT_CODES",
+    "EXIT_OK",
+    "EXIT_ERROR",
+    "EXIT_USAGE",
+    "EXIT_MISSING_DEPENDENCY",
+    "describe",
+    "is_handler_code",
 ]
 
 
@@ -90,23 +109,35 @@ def main(argv: Sequence[str] | None = None) -> int:
     argparse raises :class:`SystemExit` for ``--help`` and usage errors. We
     catch it here and surface its code as the return value so callers (tests
     and ``__main__``) never see an exception — only an integer exit code.
+
+    Every code this function can return is documented in
+    :mod:`cds.cli._exit_codes`: ``0`` for a successful run or bare ``--help``,
+    ``2`` (``EXIT_USAGE``) for a command line argparse rejected, and whatever
+    the subcommand handler chose otherwise. ``tests/test_cli_exit_codes.py``
+    walks the whole mapping.
     """
     parser = build_parser()
     try:
         args = parser.parse_args(argv)
     except SystemExit as exc:
-        return int(exc.code) if isinstance(exc.code, int) else 0
+        # ``--help`` exits 0; a rejected command line exits EXIT_USAGE (2),
+        # which is argparse's own usage-error code. A non-integer code (a
+        # string message or None) is treated as success, which is what
+        # ``sys.exit()`` with no argument does.
+        if exc.code is None or isinstance(exc.code, int) and exc.code == EXIT_OK:
+            return EXIT_OK
+        return int(exc.code) if isinstance(exc.code, int) else EXIT_OK
 
     if args.version:
         from cds import __version__
 
         _print(_render(f"[bold]System[/] version [cyan]{__version__}[/]"))
-        return 0
+        return EXIT_OK
 
     func = getattr(args, "func", None)
     if func is None:
         parser.print_help()
-        return 0
+        return EXIT_OK
     return int(func(args))
 
 

scientific_computing_system-2.2.6/src/cds/cli/_exit_codes.py

@@ -0,0 +1,81 @@
+"""The CLI's exit-code contract.
+
+Every handler returns one of the codes below. They were previously bare ``0``
+and ``1`` literals scattered across ``cds.cli._handlers`` with nothing that
+defined what the numbers meant, so a caller could not distinguish "bad numbers"
+from "the dashboard could not be found" from "streamlit is not installed" —
+they were all ``1``. Naming them here and routing every ``return`` through
+them makes the mapping a single source of truth that a test can walk.
+
+The values are deliberately *not* new. ``EXIT_ERROR`` is the ``1`` every
+handler already returned and that the suite already asserts, and
+``EXIT_USAGE`` is the code :mod:`argparse` has always raised for a malformed
+command line. This module pins a contract that already existed in practice;
+it does not invent one.
+"""
+
+from __future__ import annotations
+
+__all__ = [
+    "EXIT_CODES",
+    "EXIT_ERROR",
+    "EXIT_MISSING_DEPENDENCY",
+    "EXIT_OK",
+    "EXIT_USAGE",
+    "describe",
+    "is_handler_code",
+]
+
+#: The command completed and produced its output.
+EXIT_OK = 0
+
+#: The command was understood but could not be carried out: a malformed value,
+#: an out-of-domain parameter, an unwritable output path, or a viral resource
+#: (the dashboard script, an output file) that is not present.
+EXIT_ERROR = 1
+
+#: The command line itself was rejected — an unknown subcommand, a missing
+#: required argument, a bad ``choices=`` value, or an unparseable number.
+#: This is :mod:`argparse`'s own usage-error code.
+EXIT_USAGE = 2
+
+#: The command needs an optional extra that is not installed (``[plot]`` for
+#: ``--file``, ``streamlit`` for the dashboard). Distinguished from a plain
+#: input error because the remedy is an install, not a corrected invocation.
+EXIT_MISSING_DEPENDENCY = 3
+
+#: Every code the CLI can exit with, mapped to its one-line contract.
+EXIT_CODES: dict[int, str] = {
+    EXIT_OK: "command completed and produced its output",
+    EXIT_ERROR: "command was understood but could not be carried out",
+    EXIT_USAGE: "command line was rejected by the argument parser",
+    EXIT_MISSING_DEPENDENCY: "command needs an optional extra that is not installed",
+}
+
+#: The set of codes a subcommand handler may return. ``EXIT_USAGE`` is produced
+#: by :func:`argparse.ArgumentParser.parse_args` before any handler runs, so it
+#: is not in a handler's reach and is listed for documentation only.
+_HANDLER_CODES = frozenset({EXIT_OK, EXIT_ERROR, EXIT_MISSING_DEPENDENCY})
+
+
+def describe(code: int) -> str:
+    """Return the one-line contract for ``code``.
+
+    Args:
+        code: an integer exit status.
+
+    Returns:
+        The documented meaning, or a message naming the documented codes when
+        ``code`` is not one of them.
+
+    Raises:
+        TypeError: if ``code`` is not an integer.
+    """
+    if isinstance(code, bool) or not isinstance(code, int):
+        raise TypeError("exit code must be an integer")
+    return EXIT_CODES.get(code, f"undocumented exit code {code}")
+
+
+def is_handler_code(code: int) -> bool:
+    """True when a subcommand handler is allowed to return ``code``."""
+    return code in _HANDLER_CODES