basedpl 0.1.72__tar.gz → 0.1.73__tar.gz

{basedpl-0.1.72 → basedpl-0.1.73}/Cargo.lock

@@ -93,7 +93,7 @@ checksum = "ac07cdecf99051d9a5238b80f35af32cdeba5b336e55d957b318b50137e18da5"
 
 [[package]]
 name = "basedpl"
-version = "0.1.72"
+version = "0.1.73"
 dependencies = [
  "base64 0.23.1",
  "bytemuck",
@@ -137,7 +137,7 @@ dependencies = [
 
 [[package]]
 name = "basedpl-cli"
-version = "0.1.72"
+version = "0.1.73"
 dependencies = [
  "async-trait",
  "basedpl",
@@ -150,7 +150,7 @@ dependencies = [
 
 [[package]]
 name = "basedpl-py"
-version = "0.1.72"
+version = "0.1.73"
 dependencies = [
  "basedpl",
  "num-bigint",
@@ -165,7 +165,7 @@ dependencies = [
 
 [[package]]
 name = "basedpl-wasm"
-version = "0.1.72"
+version = "0.1.73"
 dependencies = [
  "basedpl",
  "js-sys",
@@ -1413,9 +1413,9 @@ dependencies = [
 
 [[package]]
 name = "rustymath"
-version = "0.1.46"
+version = "0.1.48"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "f160fb701304e3888885ade3929ef93b7c7d1aaab5ae61f16c0ec0e01f270cab"
+checksum = "3ed381a5dbc0b48b7077c4d510027b240e1067af82bcc5c964ade2c319839499"
 dependencies = [
  "foldhash",
  "half",
@@ -1434,9 +1434,9 @@ dependencies = [
 
 [[package]]
 name = "rustymath-buffer"
-version = "0.1.46"
+version = "0.1.48"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "1c1457056dae79ecf521f89d600f82a2a954e601ecd8d478e495b65cb6145010"
+checksum = "8614c8bc25045617899784d0fa952f3137835030bcbb9f77359e1c530fd75c4b"
 dependencies = [
  "pyo3",
  "rustymath",
@@ -1581,9 +1581,9 @@ checksum = "0c790de23124f9ab44544d7ac05d60440adc586479ce501c1d6d7da3cd8c9cf5"
 
 [[package]]
 name = "smallvec"
-version = "1.16.3"
+version = "1.16.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "5b3dc8af474f516a851ff4bd12db780f948b9250ad37211e4eec0bccea54e01b"
+checksum = "d0d5d4b1981b8bbbb7aed204cae5726d683d5d6ac7e74ec54122ea28f315e7c8"
 
 [[package]]
 name = "socket2"
@@ -1814,9 +1814,9 @@ checksum = "06abde3611657adf66d383f00b093d7faecc7fa57071cce2578660c9f1010821"
 
 [[package]]
 name = "uuid"
-version = "1.28.0"
+version = "1.29.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "7cc1186384beb7dd8eedea376413fd654937285ea6c9cfbb928dc3043ea4b606"
+checksum = "4a0e2d11620c50695fe12bbbfde96b3477fe606e7284c22d505c12ce51214514"
 dependencies = [
  "atomic",
  "getrandom",
@@ -2086,7 +2086,7 @@ checksum = "3ad82d2a33cdc9674dc7465672f271e096168fcdbe0f799d9e6db8c5892679dc"
 
 [[package]]
 name = "xtask"
-version = "0.1.72"
+version = "0.1.73"
 dependencies = [
  "anyhow",
  "rustymath",

{basedpl-0.1.72 → basedpl-0.1.73}/Cargo.toml

@@ -5,14 +5,14 @@ members = ["py"]
 join_comments = true
 
 [workspace.package]
-version = "0.1.72"
+version = "0.1.73"
 edition = "2024"
 rust-version = "1.98"
 license = "Apache-2.0"
 
 [workspace.dependencies]
-rustymath = { version = ">=0.1.44, <1", default-features = false }
-rustymath-buffer = ">=0.1.44, <1"
+rustymath = { version = ">=0.1.48, <1", default-features = false }
+rustymath-buffer = ">=0.1.48, <1"
 pyo3 = ">=0.29.2, <1"
 pyo3-build-config = ">=0.29.2, <1"
 

{basedpl-0.1.72 → basedpl-0.1.73}/DEV.md

@@ -18,7 +18,7 @@ cargo test
 pytest -q
 ```
 
-Use `cargo develop` to rebuild and install the native extension and `bpl` after Rust changes. It uses the `test` profile shared with `cargo test`. Cargo tests compile missing code but don't install it. Run plain `cargo test` while you work; use one test binary for a focused check. Run `pytest -q` at the end of a piece of work. Before you report a `pytest` failure in code you didn't touch, run `cargo develop` and rerun it. Give builds three minutes and test runs one minute; Cargo serializes builds in the same target directory.
+Use `cargo develop` to rebuild and install the native extension and `bpl` after Rust changes. It uses the `test` profile shared with `cargo test`. Cargo tests compile missing code but don't install it. Run plain `cargo test` while you work; use one test binary for a focused check. From a kernel, `fastws.cargo.run_tests(root, *args)` runs `cargo test` and returns the build's compiler messages and each test binary's results. Run `pytest -q` at the end of a piece of work. Before you report a `pytest` failure in code you didn't touch, run `cargo develop` and rerun it. Give builds three minutes and test runs one minute; Cargo serializes builds in the same target directory.
 
 Build nothing else without discussion: no scratch crates, alternate target directories, `--release`, `-p` or other-target builds. The documented build diagnostics, browser work and x86-64 inspection below are exceptions. Don't use `maturin develop`; its configuration does not reuse the normal local build.
 
@@ -26,7 +26,7 @@ When another agent's unfinished edits stop the shared tree compiling, run `cargo
 
 An already-running Python process retains its loaded extension. In a kernel, use `from basedpl.worker import fresh; fresh(code)` to check the installed `bpl` in a fresh worker instead of restarting the kernel. A BPL error raises `BplError`. `fresh(code, bpl=PATH)` runs a saved copy of `bpl`, such as the baseline described below. Check one expression and read its result before building on it. `basedpl.bpltests.check_file` and `check_page` check reference files and documentation through the worker without building Rust. With `bpl=PATH`, they check a saved copy without installing it.
 
-Measure with `BASEDPL_COSTS=1 cargo test --test speed` or `basedpl.bpltests.time_cases(cases)`. Both count costs in copies. A copy is the time to write as many floats as the data has items, each negated, into a second buffer. `rustymath::timing::COPIES` stores the copy time of each machine that runs the speed tests, by its CPU, the item's size and the number of items, at the slower end of what that copy normally takes, for copies whose source and destination fit in cache, 64 MiB together (`CACHED_BYTES`). A copy timed beside each case varied more than 3 times on CI's runner, where the functions' own times didn't, so stored times keep that noise out of every cost. A larger copy runs at the speed of memory, which a shared runner varies by up to 2 times between runs, and the cases of that size vary with it. The test measures such a copy once in each run. It also measures a cached size with no entry once, and prints a line to add to `COPIES`. The browser build has entries of its own, for its copy under the JavaScript engine. It can't read the CPU's name, and `tests/wasm-pkg.mjs` passes it the name that Node reads. Each case's line in a log ends with its time for each item, which `logged_costs` keeps in each row, and the log has a copy line for each size of data, which it reads into its result's `copies`. Budgets are single-thread measurements. `thread_scaling()` checks multithreaded speed: it times a large product, a 512×512 SVD and Hermitian eigendecomposition, a stack of QR decompositions and a large elementwise function on one thread and on the machine's cores, and fails when one speeds up less than 1.5 times. Accelerate's GESDD and SYEVD run on one thread whatever its threading setting. On macOS, where Accelerate computes the product, the SVD and the Hermitian eigendecomposition, those three cases need only the speedups in `_ACCELERATED_LEAST`. The manual `Speed` workflow runs it. `speed_costs()` reads the cases in `tests/speed.txt`. `cases=` selects expressions, `wasm=DIR` selects a browser build, `bpl=PATH` selects another native `bpl`, such as a saved copy, and `native=True` times rustymath's own linear algebra, which dev builds compile in. `logged_costs(log)` reads CI output from its text or a file. `cargo_costs(path)` runs either project's Rust speed test, and `pytest_costs(path)` runs rustymath's Python speed test.
+Measure with `BASEDPL_COSTS=1 cargo test --test speed` or `basedpl.bpltests.time_cases(cases)`. Both count costs in copies. A copy is the time to write as many floats as the data has items, each negated, into a second buffer. `rustymath::timing::COPIES` stores the copy time of each machine that runs the speed tests, by its CPU, the item's size and the number of items, at the slower end of what that copy normally takes, for copies whose source and destination fit in cache, 64 MiB together (`CACHED_BYTES`). A copy timed beside each case varied more than 3 times on CI's runner, where the functions' own times didn't, so stored times keep that noise out of every cost. A larger copy runs at the speed of memory, which a shared runner varies by up to 2 times between runs, and the cases of that size vary with it. The test measures such a copy once in each run. It also measures a cached size with no entry once, and prints a line to add to `COPIES`. The browser build has entries of its own, for its copy under the JavaScript engine. It can't read the CPU's name, and `tests/wasm-pkg.mjs` passes it the name that Node reads. Each case's line in a log ends with its time for each item, which `logged_costs` keeps in each row, and the log has a copy line for each size of data, which it reads into its result's `copies`. Budgets are single-thread measurements. `thread_scaling()` checks multithreaded speed: it times a large product, a 512×512 SVD and Hermitian eigendecomposition, a stack of QR decompositions and a large elementwise function on one thread and on the machine's cores, and fails when one speeds up less than 1.5 times. Accelerate's GESDD and SYEVD run on one thread whatever its threading setting. On macOS, where Accelerate computes the product, the SVD and the Hermitian eigendecomposition, those three cases need only the speedups in `_ACCELERATED_LEAST`. The manual `Speed` workflow runs it. `speed_costs()` reads the cases in `tests/speed.txt`. `cases=` selects expressions, `wasm=DIR` selects a browser build, `bpl=PATH` selects another native `bpl`, such as a saved copy, `native=True` times rustymath's own linear algebra, which dev builds compile in, and `prefs=` runs BPL before each section's header, such as `•prefs ["kinds":"static"]`. `logged_costs(log)` reads CI output from its text or a file. `cargo_costs(path)` runs either project's Rust speed test, and `pytest_costs(path)` runs rustymath's Python speed test.
 
 Costs in copies can't show a per-call change of a few percent, because code layout alone moves a timing by more than that. `instructions(cases)` counts instructions, which load and layout don't change. Each case is an expression, such as `k(⌈/⊢)⌸a`, run once per step inside `{case ⋄ ⍵}⍣N⊢0`. That dfn's own call adds about 1,900 instructions a step. A case that names `N` makes its own calls instead, such as `{⍵}⍣N⊢0`, which makes one dfn call a step. Such a case must make one call per step: a map such as `f¨N⍴0` calls a dfn once on all its cells, so it gives no per-call cost. It runs fresh single-threaded `bpl` processes at four values of `N`. For each pair of successive values, it divides the difference in instructions retired by the difference in `N`, which cancels startup and `setup=`, and it reports the median of those three slopes. The median drops a one-off cost that starts once `N` passes some size, because such a cost falls between only one pair. `≢•ucs N⍴"ab" "cde"` has one: it retires about 5×10⁶ more instructions from about 131,350 items on. Every value of `N` lies past the warm-up, from a rough count at 1,000 steps, because a case that allocates an array at each step retires extra instructions over its first steps while the allocator settles. Each process pays a different warm-up, up to about 5×10⁶ instructions, so successive values of `N` lie 5×10⁸ instructions apart, where that difference moves a slope by under 1%. `counts=` sets two or more values instead. It reads `/usr/bin/time -l` on macOS and `perf stat` on Linux, and `bpl=PATH` counts a saved copy. A case whose result stays pending, such as large windows or a transpose, counts making the pending copy, not the copy: `3↕v` retires about 12,000 instructions a step. `force=True` computes each step's result in full, through an indexed write, for any result of rank 1 or more: `3↕v` then counts the copy itself, about 9 million instructions a step. A join computes at once and needs no `force`.
 
@@ -34,7 +34,7 @@ Costs in copies can't show a per-call change of a few percent, because code layo
 
 `profile(case)` shows where a case's instructions go, by function, on macOS. It takes a case, and `force=`, as `instructions` does. A fresh process repeats the case on one thread while `sample` counts how often each function is at the top of the main thread's stack. A function's share of those samples, times the build's count from `instructions`, estimates its instructions per step. The estimate assumes every function retires instructions at the same rate. When a count moves, `profile_diff(case, base)` shows which functions moved it, from those estimates for both builds. A function that one build inlines and the other calls out of line appears under one build alone. Run them before reading machine code. `base` is a saved copy, and `bpl=PATH` sets the build to profile, the installed one by default.
 
-`bpl-tests NAME ARGUMENT...` runs one of these functions from the shell and prints its result: `check_file`, `check_page`, `time_cases`, `instructions`, `instruction_budgets`, `profile`, `profile_diff`, `speed_costs`, `thread_scaling`, `cargo_costs`, `pytest_costs`, `compare_costs` or `wasm_test`. Run long checks and timings this way, not in the shared kernel, which runs one cell at a time for every agent. For example, `bpl-tests time_cases '+/v' --threads 4` times `+/v` on four threads. `time_cases`, `instructions` and `speed_costs` take cases as positional arguments. When a case starts with `-`, put the cases last, after `--`, as in `bpl-tests speed_costs -- '-.×m' '+/v'`. `bpl-tests NAME -h` lists a function's arguments.
+`bpl-tests NAME ARGUMENT...` runs one of these functions from the shell and prints its result: `check_file`, `check_page`, `time_cases`, `instructions`, `instruction_budgets`, `profile`, `profile_diff`, `disasm`, `speed_costs`, `thread_scaling`, `cargo_costs`, `pytest_costs`, `compare_costs` or `wasm_test`. For example, `bpl-tests time_cases '+/v' --threads 4` times `+/v` on four threads. `time_cases`, `instructions` and `speed_costs` take cases as positional arguments. When a case starts with `-`, put the cases last, after `--`, as in `bpl-tests speed_costs -- '-.×m' '+/v'`. `bpl-tests NAME -h` lists a function's arguments. Called in a kernel, the same functions return Python objects, such as the rows that `compare_costs` reads.
 
 On each push, the `Test` workflow logs every native cost in its `test` job and every wasm cost in its `wasm` job. The speed test that writes them times the test-profile build that the budgets limit. `bpl --costs FILE` times the cases in a file in `speed.txt`'s format as the speed test does, and prints each cost with this machine's budget, without failing on a budget. The manual `Speed` workflow runs it on a `dist` build, the profile releases use, on CI's runner, beside its wasm timing. The `Release` workflow runs it on each binary it builds, on GitHub's runners. Their logs show what releases cost, for comparison with the `Test` workflow's. `logged_costs` reads all three workflows' logs. When you review a run, look for costs over their budgets and for costs that changed by more than 20% since the run before. `compare_costs(before, after)` lists both, from two runs' logs or from the rows that `speed_costs` and the other timing functions give. It measures each change on times per item where both runs give them, so a change to `COPIES` doesn't show as one. Every log names its CPU in its copy lines. Study a slowdown until you know its cause only when it appears in more than one CI run, or when two or more similar cases slow by similar amounts. Treat any other slowdown as normal variation.
 
@@ -44,23 +44,17 @@ An initial budget is twice what a first-principles analysis says the case should
 
 The speed tests and the scaling test time each failing case again after the rest, after each pause in `rustymath::timing::RETRY_PAUSES`, and fail only for a case that fails every time. Each retry prints the case's earlier and new costs, even in a passing run. `logged_costs` keeps a retried case's lowest cost. Study a case that needs a retry in most runs, as you would a slowdown.
 
-For a change meant to make something faster, or a change to code that every call goes through, time the cases it affects before and after the change. Before your first `cargo develop`, copy the installed `bpl` in the kernel with `shutil.copy(basedpl.worker.INSTALLED_BPL, '/tmp/<prefix>_bpl')`. Time that copy with `bpl='/tmp/<prefix>_bpl'`, and your build with the default. Another agent's `cargo develop` can replace the installed `bpl` at any time. The copy keeps your baseline fixed while agents build in parallel. Compare the two builds' times per item, which `time_cases` prints in picoseconds. A build from before a change to `rustymath::timing::COPIES` divides its costs by a different copy. On this Mac, a fused case over a large input can cost up to about 15% more in one process than in another, depending on whether `malloc` starts the input on a 32 KB boundary, where every one of a graph's blocks then ends. Time both builds the same way, each alone in a fresh process or at the same place in one run, and alternate them before you read a lone difference of that size as a regression. The speed test fails a case only past its budget. It misses any smaller slowdown. Other changes need only the speed test. Don't restore old code in the shared tree to get a baseline. On macOS, native timings of matrix products and decompositions mostly measure Accelerate. Rustymath's DEV.md says how to time rustymath's own kernels.
+For a change meant to make something faster, or a change to code that every call goes through, time the cases it affects before and after the change. Before your first `cargo develop`, copy the installed `bpl`. In a kernel, run `shutil.copy(basedpl.worker.INSTALLED_BPL, '/tmp/<prefix>_bpl')`. In the shell, run `cp "$(command -v bpl)" /tmp/<prefix>_bpl`: the installed `bpl` is the one on the venv's `PATH`. Time that copy with `bpl='/tmp/<prefix>_bpl'`, and your build with the default. Another agent's `cargo develop` can replace the installed `bpl` at any time. The copy keeps your baseline fixed while agents build in parallel. Compare the two builds' times per item, which `time_cases` prints in picoseconds. A build from before a change to `rustymath::timing::COPIES` divides its costs by a different copy. On this Mac, a fused case over a large input can cost up to about 15% more in one process than in another, depending on whether `malloc` starts the input on a 32 KB boundary, where every one of a graph's blocks then ends. Time both builds the same way, each alone in a fresh process or at the same place in one run, and alternate them before you read a lone difference of that size as a regression. The speed test fails a case only past its budget. It misses any smaller slowdown. Other changes need only the speed test. Don't restore old code in the shared tree to get a baseline. On macOS, native timings of matrix products and decompositions mostly measure Accelerate. Rustymath's DEV.md says how to time rustymath's own kernels.
 
-Cooperating tools share the machine's timing lock, `/tmp/aai-ws-timing.lock`. Timings take it exclusively. `cargo develop`, `cargo wait`, `cargo wasm`, the reference test, pytest, `check_file`, `check_page`, `bpl-nb` and `wasm_test` without `speed` take it shared. Rust code takes it through `rustymath::timing`. Python code takes it with `fastws.cargo.timing_lock`. Node can't lock a file. `wasm_test` and `speed_costs(wasm=DIR)` hold the lock in Python while Node runs. Other Rust tests and bare Cargo commands do not all take it. After five minutes a timing fails. A build or test run then goes ahead without the lock. After 30 seconds, an exclusive wait prints the processes with the lock file open. The list can include processes that are only waiting for the lock. Never take the lock yourself in the shared kernel process. Never coordinate timings by hand. A hold that outlasts its call blocks the timings that later calls launch. Each such call stalls every other agent's kernel calls while it waits. Native timings run on one thread and request user-interactive macOS QoS, which favours the performance cores. QoS is not CPU affinity.
+Cooperating tools share the machine's timing lock, `/tmp/aai-ws-timing.lock`. Timings take it exclusively. `cargo develop`, `cargo wait`, `cargo wasm`, the reference test, pytest, `check_file`, `check_page`, `bpl-nb` and `wasm_test` without `speed` take it shared. Rust code takes it through `rustymath::timing`. Python code takes it with `fastws.cargo.timing_lock`. Node can't lock a file. `wasm_test` and `speed_costs(wasm=DIR)` hold the lock in Python while Node runs. Other Rust tests and bare Cargo commands do not all take it. After five minutes a timing fails. A build or test run then goes ahead without the lock. After 30 seconds, an exclusive wait prints the processes with the lock file open. The list can include processes that are only waiting for the lock. Never take the lock yourself in a kernel process. Never coordinate timings by hand. A hold that outlasts its call blocks the timings that later calls launch. Native timings run on one thread and request user-interactive macOS QoS, which favours the performance cores. QoS is not CPU affinity.
 
 Run `cargo wasm` during development only for browser work. Agents use `cargo wasm --out DIR`, then run the browser tests against that build with `basedpl.bpltests.wasm_test(DIR)` for `tests/wasm.mjs` and `wasm_test(DIR, speed=True)` for `tests/wasm-speed.mjs`. That speed test fails on a wasm budget only on Linux x86-64, CI's platform. On any other host it prints every cost and marks each case still over its budget after the retries, as `bpl --costs` does. This avoids replacing a module another agent is using. For other edits under `cfg(web)` or `host_web.rs`, check compilation with `cargo cs -p basedpl-wasm --target wasm32-unknown-unknown`, which checks the browser wrapper crate together with basedpl's browser code. `cargo cs` alone compiles neither.
 
-### X86-64 machine code
+### Machine code
 
-To inspect the x86-64 code that CI and Linux run, build the library for Linux x86-64. In basedpl:
+`bpl-tests disasm PATTERN` shows the machine code of the function whose demangled name matches the regex `PATTERN`, read from the installed `bpl` with `objdump`. `--bpl PATH` reads a saved copy instead. Where several functions match, it lists their names. A function that is always inlined has no code of its own. Read its callers instead.
 
-```bash
-CARGO_INCREMENTAL=0 CC_x86_64_unknown_linux_gnu=clang cargo build --lib --release --target x86_64-unknown-linux-gnu --target-dir /tmp/aai-ws-x86 -p basedpl
-```
-
-In rustymath, use `-p rustymath`. The target is Linux because macOS builds leave out rustymath's native linear algebra kernels. That target is installed here. `-p` builds only the library, because the Python extension crates can't be built for Linux on this Mac. `CC_x86_64_unknown_linux_gnu=clang` lets Apple's `clang` assemble the x86-64 source in basedpl's `psm` dependency, because this Mac has no `x86_64-linux-gnu-gcc`. Don't move that setting into `.cargo/config.toml`. CI's Linux release builds also read that file, and their manylinux container has no `clang`. The build matches CI's `test` profile in its x86-64 flags and optimization settings. CI turns off the profile's incremental compilation with `CARGO_INCREMENTAL=0`. The command does the same, to split code into compilation units as CI does. Run it only to answer an x86-code question. It doesn't take the timing lock and can disturb timings running alongside it.
-
-Read the newest `lib<crate>-<hash>.rlib` under `/tmp/aai-ws-x86/x86_64-unknown-linux-gnu/release/deps` with `objdump -d -r --no-show-raw-insn --disassemble-symbols=NAME`. `-r` identifies called functions. `objdump` warns for each archive object without that symbol. `-C` matches demangled names but splits them at commas; for a generic name containing a comma, get its mangled name from `nm` and omit `-C`. Generic code belongs to the crate that instantiates it. Don't use `--emit asm`: the resulting codegen-unit arrangement can inline differently from the build being inspected.
+`--x86` shows the x86-64 code that CI and Linux run. It first builds basedpl's library and the rustymath library it links for Linux x86-64, into `/tmp/aai-ws-x86`, holding the timing lock shared. Where an unfinished edit stops basedpl compiling, it reads rustymath's library alone, and its output says so first. After a change, that build takes minutes. Use it only to answer an x86-code question. The target is Linux because macOS builds leave out rustymath's native linear algebra kernels. Only the libraries build, because the Python extension crates can't be built for Linux on this Mac. Their `release` profile matches CI's `test` profile in its x86-64 flags and optimization settings. The build sets `CC_x86_64_unknown_linux_gnu=clang` for itself. Don't move that setting into `.cargo/config.toml`. CI's Linux release builds also read that file, in a manylinux container that has no `clang`. Don't use `--emit asm`. A build with it splits code into other codegen units and inlines differently.
 
 ## Workspace, builds and CI
 
@@ -186,7 +180,7 @@ Float operations compute at the wider operand width. Exact operands round to the
 
 Floats use IEEE NaN, infinity and signed zero. Comparison treats NaN as unequal; match/search treat it as one value, and grade puts it last. Exact arithmetic involving division by zero can produce those float values. Floor/ceiling retain an exact operand beside infinity. Beside NaN the language leaves their result open: NaN or the other argument, varying by platform. Their folds, scans, windows, products and repeated writes give NaN or the maximum or minimum of the items that aren't NaN, never another number, by the rule in rustymath's `Folds` doc. A loop that folds by them either passes its running result as the right argument, which `rustymath::reduce::maximum` keeps beside NaN, or folds through rustymath's `Max` and `Min`, as `Dyad::extremum` does. Monadic floor/ceiling/sign turn whole finite results into exact integers, including big integers; nonfinite results remain floats. Use `Number::float(value, width)` and explicit-width array construction outside `number.rs` instead of implicit f64 conversion.
 
-Under `•prefs ["kinds":"static"]`, a result's kind follows from its arguments' kinds alone, as `meta/kinds.md` describes. `Numeric` carries `kinds` and `int`. `pervasive::map` chooses a dyadic call's kind through `joined`, which applies rustymath's `DType::common` after `Numeric::kind`. Atoms promote as arrays do. Python's API makes its scalar arguments weak through `Value::weakened`. The loops keep the failed results that `keeps` names: floats' NaNs, and the wrapped integers of objects that report `WRAPS`. The kernel tables choose float `⌊ ⌈ ×` and wrapping negation from `run.numeric()`. `Stored::build_at` keeps complex results complex. `Primitive::number` gives every pervasive result on numbers, as well as each step of the fold of numbers, and `statically` adjusts it. `Number::parse` keeps complex literals and checks integer literals against the `int` width.
+Under `•prefs ["kinds":"static"]`, a result's kind follows from its arguments' kinds alone, as `meta/kinds.md` describes. `Numeric` carries `kinds` and `int`. `pervasive::map` chooses a dyadic call's kind through `joined`, which applies rustymath's `DType::common` after `Numeric::kind`. Comparisons, `⌈ ⌊` and bitwise functions compute at their arguments' storage width instead, where their results are the same at every width (`pervasive::first_kind`). Atoms promote as arrays do. Python's API makes its scalar arguments weak through `Value::weakened`. The loops keep the failed results that `keeps` names: floats' NaNs, and the wrapped integers of objects that report `WRAPS`. The kernel tables choose float `⌊ ⌈ ×` and wrapping negation from `run.numeric()`. `Stored::build_at` keeps complex results complex. `Primitive::number` gives every pervasive result on numbers, as well as each step of the fold of numbers, and `statically` adjusts it. `Number::parse` keeps complex literals and checks integer literals against the `int` width.
 
 Settings live once for the whole process, in `settings.rs`, and are read from there, not passed through functions, except where a read is slow and on a hot path. Each setting that calls and scalar operations read is an atomic: the numeric settings, the hanzi aliases, the `batch` pref, the fusion report flag and fusion's small sizes. The display settings sit behind one lock. `•prefs` writes them, the lexer writes a source's leading `•prefs` header as it reads it, and `settings::reset` restores the defaults, as `]clear` and the test harnesses do. Nothing copies, captures or restores a setting. A pending array computes under the settings in force when it computes, and a module that `•load` runs changes the settings for the whole process. Rustymath holds the thread count, the one setting that it reads itself, and `•prefs` writes it there. Each call reads the store once where it starts: `pervasive::halves`, which every `pervasive` entry point goes through, `fusion::defers` and `defer`, `Domain::of`, the lexer and `Storage::item`'s complex items. Values derived from the settings within a call stay explicit arguments. `halves` passes 16-bit floats' widened settings to its inner call. The loop structs keep them because their closures run on rustymath's worker threads. A fused graph reads the settings once when it's built at forcing, for the same reason. `Number`'s tolerance methods and `Primitive::number` take them because they run once per item. The parser's leaves take a width marker's width, and `matches_within` takes `⍣∞`'s convergence tolerance. Imports build complex numbers with `Number::complex_in_session`: Python's `_Session.array` and the JSON protocol's `request`. JavaScript values hold no complex numbers.
 
@@ -222,7 +216,7 @@ Ordinary pervasive kernels also read pending copies through their maps. `fusion:
 
 `derivative.rs` implements `∂`. A dual is a tag, a primal and a tangent: a `transform::Carrier`, held in `Value::Carried` for a number and in `Data::Carried` for an array, whose primal and tangent can be pending. A record of linear calls is the other kind of carrier. Routing (`transform::call`) hands a call to the newest level among its arguments, as `Value::newest` finds it. It reads their outer layer, but a newer level inside an argument held in mixed storage wins, as an array of dual atoms beside an older dual shows. A call whose newest level is a `∂` call goes to `derivative::call`, which reads how to run it from the form's facts in `Primitive::info()` (`primitive::Facts`). It applies the partials table to pervasive forms and its own rule to `⌻`, and calls forms whose results carry no tangent on the primals. Structural glyphs, Under and selective assignment need no rules. Their own code moves each part of a carried array through the carrier's moves: `Carrier::view`, `Carrier::at`, `Carrier::copied`, and `transform::written` for writes, which a record answers through its ids. `Gather` copies a dual's primal and tangent together through `derivative::Join`. A glyph that copies its right argument through one plan, and a broadcast, copy a record tangent as one `Op::Copy` of the plan's `Steps` (`primitive::copied`, and `Form::Moves`'s `planned`). Its transpose reads through rustymath's `Steps::transposed`: the inverse map for a copy that reads each item at most once, and a correlation for windows that move by 1. A copy of a copy transposes in one read where the composed copy still transposes by reads (`linear::composed`). The record keeps the chain, because recognising windows needs each copy's own shape. A sum along a window's axis transposes as a sliding sum (`linear::slide`), and a spread axis as a sum along it. Windows that move by more than 1 transpose by rustymath's `signal::overlap_add`, which adds each window back where it read (`linear::strided_back`). Other copies, and copies of several sources, keep ids and scatter. `•explain` lists each scatter as an accumulation. In reverse mode, the rule for a `⌈` or `⌊` fold is a sum of the tangent times a mask of each lane's chosen item. Its transpose reads. Mix of a dual whose primal is nested mixes the primal and the tangent apart. `fold` and scans with `+`, `×`, `⌈` and `⌊`, `+.×` and outer products have rules, and kernels that read numbers directly leave active arguments to their general paths. Folds by primitives, products of primitives, `⌹`, `⊥` and stacks of matrices route through `transform::call` as operations (`primitive::Operation`), so their rules (`derivative::solve`, `decode`, `product_dual`, `determinant` and `fold_dual`) run on a `&Context` and call `Operation::call` for the products, folds and inverses that they need. Rank's routes for whole arguments send stacks that a level carries through `Pairing::Matrices`, so `⌹⍤2`, `+.×⍤2` and `-.×⍤2` take their stacked rules in one call, with the `batch` pref on or off. Attached rules, system functions, and folds and products by functions that aren't primitives route through the same `transform::call`, as `transform::Op`'s other variants. The rules for `⌹` and `-.×` keep the glyph's own result as the primal, so that a function computes the same values with or without `∂`. Their tangents and transposes multiply by `R`, the inverse that `numeric::matrix_inverse` takes from one factorization through rustymath's `Stacked::inverse`, or by exact row reduction for exact matrices. `regular_inverse` gives UNSUPPORTED where rustymath's regularity test finds the matrix singular. With only `B` active, `R` is `⌹A`, a pseudoinverse included. With one number in `x`, `f∂ x` runs `f` once with `x` seeded along it. With more, `linearized` pushes a record level just below its `∂` call's level, then runs `f` once with each part of `x` seeded with a record at that level, from `linear.rs`: a tangent whose items are never computed, which the same rules extend into a graph of linear calls. A call whose newest level is a record level records the linear map that its form's facts name (`linear::call`). `reverse` then reads the Jacobian from the record, by a transpose for each result item or a forward evaluation for each number of `x`, whichever are fewer. A function with a JVP rule that `f∂←g` attached calls the rule with `⍺` a dual of zeros whose tangent is the argument's, so in reverse mode the rule extends the record too (`derivative::attached`). A call of such a function with two arguments gives DOMAIN ERROR wherever `∂` needs a derivative through it (`derivative::two_arguments`). Code that reads a dual array's storage gets its items as dual atoms, which is correct at per-item speed. A rule packs an array that holds its level's duals, at any depth, into one dual before it splits the array (`derivative::packed`). A reader outside a call sees a value through `transform.rs`'s read point. `Value::observed`, which counts, positions, ranks, selectors, `≡` and guards' predicates use, reads a dual's primal. The integer readers of `Items` read carried items through it (`Value::observed_number`), so a count or position that `∂` carries reads its primal. It returns a `Result` whose error, `transform::Stop`, names the level that owns a batched run. A stop is `ErrorKind::Stop`, which no guard catches, even one that names it, and which a handler that catches every error lets pass (`ErrorKind::is_control`). Display reads through `Value::displayed`, because it never runs inside a batched run. `Value::computed`, which kernels use through `primitive::numeric`, gives UNSUPPORTED for a dual atom. Writes to bindings outside a `∂` call are recorded and stripped when it returns.
 
-`batch.rs` makes a map's batched call. `batch::tried`, which `each_pair` calls, begins a batched level for the run (`transform::Kind::Batched`), wraps each argument that has a frame in a `Batch` carrier at that level, calls the operand once, and ends the level. Each map first lays its arguments over its frame through its own agreement, the pairing that its calls on each cell read (`batch::Arguments::laid` and `agreement::laid_cells`). `each_pair` makes no batched call for one cell of atoms, which runs faster without one. Routing hands each call whose newest level is the run's to `batch::call`: a primitive, an operation that primitives name, such as a fold by a primitive or `+.×`, or an operation by a dfn. It leaves `⍕` and random draws to their own code. It runs any other system function once for each cell, on that cell's arguments, as the function runs once for each item of an argument that holds several, and joins the cells' results into one batch (`batch::system`, `batch::each_cell`). `batch::call` runs the call on the whole arguments by Rank's routes: `eval::whole_cells` through `batch::whole_call`, and `eval::folded_cells` for a fold. A primitive therefore batches wherever Rank runs it on whole arguments. A fold or scan that `folded_cells` doesn't cover, such as one by a dfn, runs the fold's own loop over the batch's items. Each stage is then one call, on item `j` of every cell (`Batch::at`). `fold_array` and `primitive_fold` join a result that holds stage batches into one batch (`joined`). Every fold and scan route decides its structural cases, such as a unit, empty lanes and the result's shape, through `FoldPlan`, and ends in `folded`, which alone gives the result its layout, fused folds included. A fold or scan by any function other than a primitive, over more than one lane, also tries a batched run of its own: `operators::by_lanes` moves the fold axis last and runs the derived fold over the lanes through `batch::tried`. `operators::by_triples` does the same for `f.g` where `g` isn't a primitive: one batched call of `g` on a frame of rows by contraction by columns, then the fold by `f` along the contraction, for each chunk of rows whose triples hold at most `batch::CHUNK` items (`operators::by_rows`, which products of primitives share). Each runs its usual loop from the start where its try gives `None`. A fold keeps its stops on its operand's `Definition` (`Function::remembers`). `batch::tries` holds the conditions for any try. A call that no route covers stops the run (`transform::Stop`). A call whose constants with axes, repeated over the frame, would hold more than 4 times the items of its arguments and more than `batch::CHUNK` items, 2²¹, stops the run with the cells of a chunk whose share holds at most `CHUNK` items (`oversized`, `Stop::chunk`). `tried` then runs the operand once on each chunk of that many cells (`batch::chunked`), each as a batched level on a frame of one axis, and joins the chunks' results as the run over cells assembles its cells' results. A chunk that stops for too many items again starts the chunks over with its own smaller chunk. Where one cell's share alone passes `CHUNK`, the map calls its operand once for each cell. Code that must run once for each cell asks the levels first (`Levels::effect`): output, input, `⍕` of a carried value, and the code in a system function that acts (`Effect::Acts`, through `Context::acts`), a guard or a call on prototypes that would catch an error (`Effect::Catches`), and a write to a binding outside the map's frames (`Effect::Writes`, through `Levels::record_write`). A read through `Value::observed`, as a count or a position makes, stops the run too. A guard whose predicate is a batch of the run splits the run instead (`Session::guard` through `operators::guard`). `batch::truths` gives each cell's Boolean, and each side runs once, as a guard case on its own cells (`Levels::case`), through the `Cells` that `⍚` uses. Each batched binding in the frames that the run started is read at the side's cells (`Session::restricted`, through `batch::read_cells` and `operators::cells_at`), and `Cells::assembled` joins the sides' results. During a case, the run's frame is the case's cells, a random draw draws for the case's cells, and a write to an enclosing frame stops the run. A guard of a dfn that already splits the cells in another frame stops the run as a recursive call (`Cause::Recursion`), and sides whose cells differ in layout or kind stop it as a call with no rule. Each stop carries its cause (`transform::Cause`), which says how long a dfn operand remembers it (`Cause::kept`). An effect, a write, an observing read or a recursive call lasts for every later call. A call that no route covers lasts while later calls repeat the arguments' kinds and cell shapes, and the memory guard lasts while they also repeat the frame's shape. A caught error never lasts, because whether an error arises depends on the cells' values. The dfn's `Definition` holds what it remembers (`Definition::remember`): `ALWAYS`, or a signature of the arguments (`batch::signature`), each holding the stop's cause (`batch::holding`). A later try that it covers falls back without calling the operand, with an `"an earlier stop"` event that names the cause. A stop's own `fallbacks` event names its cause (`Cause::reason`), and the glyph of a primitive whose call no rule covers (`Stop::refusing`). Code with no rule for batches that reads a batch's items gets item carriers, item i of every cell, and records an `itemwise` row, route `"batched items"`. `explain::itemwise` is the one helper for routes that handle items one at a time, and the innermost call claims its counts (`Function::reported`), as `forced` does. A kernel that then reads a number meets the stop that `Carrier::computed` gives a batch. A missed reader therefore costs speed or a fallback, never a wrong result. A batched run can also start inside a `∂` call. The run's level is newer than the `∂` tag, so the batch rules take each call first, and their calls on whole arrays reach the derivative rules. A batch's whole can then carry a dual, whose kind batch checks read through `Value::template_dtype`. Stacks of matrices whose wholes carry a dual take the derivative rules through `Pairing::Matrices` (`eval::whole_cells`), because the stacked kernels read compact storage. A `∂` call inside the run differentiates with respect to batches of atoms or of arrays. `derivative::numbers` counts a cell's numbers from the batch's template, every cell shares each direction's seed, and the Jacobian joins into one batch (`batch::joined`). A move with no plan on a dual whose primal is a batch runs on the primal and the tangent apart (`derivative::apart`). Adjoints that a transpose adds into a batch add as one sum on its whole (`batch::scatter_add`). An attached rule runs on the whole batch at its argument's `∂` tag (`batch::call`), and `batch::split_whole` and `batch::dual_of_wholes` keep the newest level outermost. A roll draws once, on its argument laid over the frame (`distribution::drawn_items`), and deals and samples draw for each cell in turn (`distribution::each_cell`), all from one stream in cell order. Where each cell draws once, seeded draws match a run cell by cell, except under a guard that splits the cells, where each side draws for its own cells in turn. A try that falls back puts back the state of each generator it drew from (`distribution::settle`). The map's result must be a batch at its level, a strand of batches whose kinds join (`joined`), or an atom or compact array with no carrier, as every cell's result. Any other result falls back. A pervasive call stops where its result's kind differs from the kind that one route gives every item (`pervasive::expected`). Each cell then keeps the kind that a run cell by cell gives it. `reference::check` runs each reference case with the `batch` pref off, then on, then on under fusion's small sizes (`fusion::Sizes::SMALL`), and compares the storage kinds of the later runs' values with the first's.
+`batch.rs` makes a map's batched call. `batch::tried`, which `each_pair` calls, begins a batched level for the run (`transform::Kind::Batched`), wraps each argument that has a frame in a `Batch` carrier at that level, calls the operand once, and ends the level. Each map first lays its arguments over its frame through its own agreement, the pairing that its calls on each cell read (`batch::Arguments::laid` and `agreement::laid_cells`). `each_pair` makes no batched call for one cell of atoms, which runs faster without one. Routing hands each call whose newest level is the run's to `batch::call`: a primitive, an operation that primitives name, such as a fold by a primitive or `+.×`, or an operation by a dfn. It leaves `⍕` and random draws to their own code. It runs any other system function once for each cell, on that cell's arguments, as the function runs once for each item of an argument that holds several, and joins the cells' results into one batch (`batch::system`, `batch::each_cell`). `batch::call` runs the call on the whole arguments by Rank's routes: `eval::whole_cells` through `batch::whole_call`, and `eval::folded_cells` for a fold. A primitive therefore batches wherever Rank runs it on whole arguments. A fold or scan that `folded_cells` doesn't cover, such as one by a dfn, runs the fold's own loop over the batch's items. Each stage is then one call, on item `j` of every cell (`Batch::at`). `fold_array` and `primitive_fold` join a result that holds stage batches into one batch (`joined`). Every fold and scan route decides its structural cases, such as a unit, empty lanes and the result's shape, through `FoldPlan`, and ends in `folded`, which alone gives the result its layout, fused folds included. A fold or scan by any function other than a primitive, over more than one lane, also tries a batched run of its own: `operators::by_lanes` moves the fold axis last and runs the derived fold over the lanes through `batch::tried`. `operators::by_triples` does the same for `f.g` where `g` isn't a primitive: one batched call of `g` on a frame of rows by contraction by columns, then the fold by `f` along the contraction, for each chunk of rows whose triples hold at most `batch::CHUNK` items (`operators::by_rows`, which products of primitives share). Each runs its usual loop from the start where its try gives `None`. A fold keeps its stops on its operand's `Definition` (`Function::remembers`). `batch::tries` holds the conditions for any try. A call that no route covers stops the run (`transform::Stop`). A call whose constants with axes, repeated over the frame, would hold more than 4 times the items of its arguments and more than `batch::CHUNK` items, 2²¹, stops the run with the cells of a chunk whose share holds at most `CHUNK` items (`oversized`, `Stop::chunk`). `tried` then runs the operand once on each chunk of that many cells (`batch::chunked`), each as a batched level on a frame of one axis, and joins the chunks' results as the run over cells assembles its cells' results. A chunk that stops for too many items again starts the chunks over with its own smaller chunk. Where one cell's share alone passes `CHUNK`, the map calls its operand once for each cell. Code that must run once for each cell asks the levels first (`Levels::effect`): output, input, `⍕` of a carried value, and the code in a system function that acts (`Effect::Acts`, through `Context::acts`), a guard or a call on prototypes that would catch an error (`Effect::Catches`), and a write to a binding outside the map's frames (`Effect::Writes`, through `Levels::record_write`). A read through `Value::observed`, as a count or a position makes, stops the run too. A guard whose predicate is a batch of the run splits the run instead (`Session::guard` through `operators::guard`). `batch::truths` gives each cell's Boolean, and each side runs once, as a guard case on its own cells (`Levels::case`), through the `Cells` that `⍚` uses. Each batched binding in the frames that the run started is read at the side's cells (`Session::restricted`, through `batch::read_cells` and `operators::cells_at`), and `Cells::assembled` joins the sides' results. During a case, the run's frame is the case's cells, a random draw draws for the case's cells, and a write to an enclosing frame stops the run. A map inside the run widens the run instead of beginning another, where the run is the innermost level (`batch::Entry::Widen`). The widening is a case with no definition, whose frame is the run's frame followed by the map's. The run's batches among the map's arguments lay over that frame (`batch::laid_over`), and a binding made before the widening lays over it when code reads it (`Session::read_binding`). A widened run that stops, or an Each whose results are arrays, falls back to calling the map's operand once for each of its cells inside the run. A guard of a dfn that already splits the cells in another frame stops the run as a recursive call (`Cause::Recursion`), and sides whose cells differ in layout or kind stop it as a call with no rule. Each stop carries its cause (`transform::Cause`), which says how long a dfn operand remembers it (`Cause::kept`). An effect, a write, an observing read or a recursive call lasts for every later call. A call that no route covers lasts while later calls repeat the arguments' kinds and cell shapes, and the memory guard lasts while they also repeat the frame's shape. A caught error never lasts, because whether an error arises depends on the cells' values. The dfn's `Definition` holds what it remembers (`Definition::remember`): `ALWAYS`, or a signature of the arguments (`batch::signature`), each holding the stop's cause (`batch::holding`). A later try that it covers falls back without calling the operand, with an `"an earlier stop"` event that names the cause. A stop's own `fallbacks` event names its cause (`Cause::reason`), and the glyph of a primitive whose call no rule covers (`Stop::refusing`). Code with no rule for batches that reads a batch's items gets item carriers, item i of every cell, and records an `itemwise` row, route `"batched items"`. `explain::itemwise` is the one helper for routes that handle items one at a time, and the innermost call claims its counts (`Function::reported`), as `forced` does. A kernel that then reads a number meets the stop that `Carrier::computed` gives a batch. A missed reader therefore costs speed or a fallback, never a wrong result. A batched run can also start inside a `∂` call. The run's level is newer than the `∂` tag, so the batch rules take each call first, and their calls on whole arrays reach the derivative rules. A batch's whole can then carry a dual, whose kind batch checks read through `Value::template_dtype`. Stacks of matrices whose wholes carry a dual take the derivative rules through `Pairing::Matrices` (`eval::whole_cells`), because the stacked kernels read compact storage. A `∂` call inside the run differentiates with respect to batches of atoms or of arrays. `derivative::numbers` counts a cell's numbers from the batch's template, every cell shares each direction's seed, and the Jacobian joins into one batch (`batch::joined`). A move with no plan on a dual whose primal is a batch runs on the primal and the tangent apart (`derivative::apart`). Adjoints that a transpose adds into a batch add as one sum on its whole (`batch::scatter_add`). An attached rule runs on the whole batch at its argument's `∂` tag (`batch::call`), and `batch::split_whole` and `batch::dual_of_wholes` keep the newest level outermost. A roll draws once, on its argument laid over the frame (`distribution::drawn_items`), and deals and samples draw for each cell in turn (`distribution::each_cell`), all from one stream in cell order. Where each cell draws once, seeded draws match a run cell by cell, except under a guard that splits the cells, where each side draws for its own cells in turn. A try that falls back puts back the state of each generator it drew from (`distribution::settle`). The map's result must be a batch at its level, a strand of batches whose kinds join (`joined`), or an atom or compact array with no carrier, as every cell's result. Any other result falls back. A pervasive call stops where its result's kind differs from the kind that one route gives every item (`pervasive::expected`). Each cell then keeps the kind that a run cell by cell gives it. `reference::check` runs each reference case with the `batch` pref off, then on, then on under fusion's small sizes (`fusion::Sizes::SMALL`), and compares the storage kinds of the later runs' values with the first's.
 
 Rustymath owns numeric folds, scans, adjacent pairs, grouped reductions and integer bounds. Basedpl selects kernels, tolerance, seeds, storage widths and exact fallbacks. Which reduction folds each primitive comes from rustymath's `facts!` table, through `pervasive::folds` and `truth_fold`, and so do the object by whose rule each takes characters and the comparison objects that `with_comparison!` makes. Folds by algebraic float operations can regroup. Contiguous subtraction/division folds use `Alternating`; quotients fall back to item-by-item folding if their products leave the normal range. Boolean scans compose truth-table maps; comparison scans compute both possible totals in bulk and use `reduce::chosen`. Seeds, axis lanes and scalar fallback preserve the language's accumulation direction. Generic reductions stay right-associated and preserve operand call order/effects. Monadic `f.g` is the exception: it memoizes each minor's expansion, and a cached minor does not repeat operand calls or their effects. Determinant/permanent fast paths use the appropriate rustymath backend.
 

{basedpl-0.1.72 → basedpl-0.1.73}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: basedpl
-Version: 0.1.72
+Version: 0.1.73
 Classifier: Programming Language :: Rust
 Classifier: Programming Language :: Python :: Implementation :: CPython
 Requires-Dist: fastcore

{basedpl-0.1.72 → basedpl-0.1.73}/nbs/evaluation.qmd

@@ -176,6 +176,7 @@ The map calls its operand once for each cell instead where the operand:
 - writes output, reads input, or formats a cell's value with `⍕`
 - calls a system function that acts: one that reads or writes files, the network, the clock or the terminal, or that makes something new on each call, such as `•nget`, `•time` or `•uuid`
 - writes to a name outside the map
+- appends to a value that differs from cell to cell, or writes into one so that it would be held in mixed storage
 - has a guard that catches an error
 - gives a result that holds arrays as items
 - calls a primitive that can't run on all the cells at once

{basedpl-0.1.72 → basedpl-0.1.73}/nbs/glyphs/brackets.qmd

@@ -29,7 +29,7 @@ x←2 4 9
 ⍴[[1]⋄[2]]       ⍝ [2 1]ₓ
 ```
 
-Around literals, `[…]ₓ` makes every number exact, at any depth. Each number must be whole. After a list that holds anything else, `ₓ` is [`⌊`](downstile.qmd).
+Around literals, `[…]ₓ` makes every number exact, at any depth. Each number must be whole. After a list that holds anything else, `ₓ` floors its numbers to exact integers, as [Superscripts and subscripts](../scripts.ipynb) describes.
 
 ```bpl
 [1 0 1]ₓ≡1ₓ 0ₓ 1ₓ  ⍝ $t

{basedpl-0.1.72 → basedpl-0.1.73}/nbs/llms.txt

@@ -22,8 +22,8 @@ Each entry below names a difference from Dyalog APL, gives a short example, and
 - [Brackets](glyphs/brackets.html.md): `[a b]` is a vector, even `[a]`. Inside brackets, spaces separate items. `;` separates items, each read as if parenthesised: `[1 2;3 4]` is `[(1 2) (3 4)]`, two items. `⋄` separates rows: `[1 2⋄3 4]` is a matrix. `"k":v` items make a record: `["a":1 "b":2]`.
 - [Characters and strings](strings.html.md): `"abc"` is a character vector. `'a'` is one character atom. A single-quoted string such as `'abc'` is an error.
 - [Indexing](indexing.html.md): `Y[I]` isn't BPL. `I⌷A` takes a cross product, while `A.[I J]` pairs its index arrays as NumPy does: with `i←⍳3`, `m.[i i]` is the diagonal. Positions count from 0. Negative positions count from the end.
-- [Numbers](numbers.html.md): bare numbers behave as in Dyalog. BPL adds exact integers, as in `3ₓ`, and exact rationals, as in `1r3`, and arithmetic on exact numbers stays exact.
-- [Superscripts and subscripts](scripts.html.md): `x²` is `x*2`, `f⁻¹` is the inverse of `f`, `v₁` is `1⌷v`, and `nₓ` is `⌊n`. Between names, `xⱼy` is `x+y×0ⱼ1`, `xₑy` is `x×10*y` and `xᵣy` is `xₓ÷yₓ`.
+- [Numbers](numbers.html.md): a bare number is a float, as Python's `1.` is, and behaves as in Dyalog. BPL adds exact integers, as in `3ₓ`, which is Python's `3`. It also adds exact rationals, as in `1r3`. Arithmetic on exact numbers stays exact.
+- [Superscripts and subscripts](scripts.html.md): `x²` is `x*2`, `f⁻¹` is the inverse of `f`, `v₁` is `1⌷v`, and `nₓ` is `⌊ₓn`. After a function, `ₓ` floors its results to exact integers: `7÷ₓ2` is `3ₓ`. Between names, `xⱼy` is `x+y×0ⱼ1`, `xₑy` is `x×10*y` and `xᵣy` is the exact quotient of `xₓ` by `yₓ`.
 - [Keyed arrays](keyed.html.md): axes can have names and keys. `T.a` reads field `a` of a record, and `⊢.a` is `{⍵.a}`. Arithmetic pairs axes by name: with `i←⍳["i":3]` and `j←⍳["j":3]`, `i+j` is a 3×3 table.
 - [Dfns](dfns.html.md): BPL has only dfns, with no tradfns and no control structures such as `:If`. A dfn returns its last statement. A predicate picks a body, as in BQN: `{⍵<0?-⍵;⍵} ¯3` is `3`. An absent `⍺` drops out of expressions, as BQN's `𝕨` does. A dfn operator's operands are `⍶` and `⍹`, not `⍺⍺` and `⍵⍵`. `⍢` calls the operator recursively. An error guard names its kinds as text, as in `"DOMAIN"::`.
 - [Assignment](assignment.html.md): `←` is local. Modified and selective updates change the nearest binding. `[a b]←Y` destructures the items of `Y` by position. A space before `←` makes the whole run the target: `[[0 2]]⌷v ←0`.

{basedpl-0.1.72 → basedpl-0.1.73}/nbs/numbers.qmd

@@ -19,7 +19,7 @@ BPL has two kinds of number. A bare number such as `0.5` is approximate: a float
 | `⍬`, `⍬ₓ`, `⍬ₕ`, `⍬ₛ`, `⍬ₚ` | The approximate, the exact, and the 16-bit, 32-bit and 64-bit [empty vector](glyphs/zilde.qmd) |
 | `[…]ₓ`, `(…)ₓ` | A list, or rows, in which every number is exact |
 | `[…]ₕ`, `[…]ₛ`, `[…]ₚ` | A list, or rows, in which every real number is a 16-bit, 32-bit or 64-bit float, and every complex number has parts of that width, or 32-bit parts after `ₕ` |
-| `xⱼy`, `xₑy`, `xᵣy` | Between two items, such as names: `x+y×0ⱼ1`, `x×10*y` and `xₓ÷yₓ`, as one term |
+| `xⱼy`, `xₑy`, `xᵣy` | Between two items, such as names: `x+y×0ⱼ1`, `x×10*y` and the exact quotient of `xₓ` by `yₓ`, as one term |
 
 A plain `e`, `j` or `r` starts a name unless the rest of a number follows it, as in `1e5`, `1r3` and `2j3`. Results display with the subscript forms, as in `1ᵣ3`, `2ⱼ3` and `1ₑ20`. A subscript form that the rest of a number doesn't follow, or one between two other items such as names, joins the items on each side into one term, as a literal is one, with the value the table gives. A literal on the left gives what the all-literal form gives: with `n←3`, `2ₑn` is `2ₑ3`.
 
@@ -96,7 +96,7 @@ m.[[1]]←1
 m                    ⍝ $f 1 $f
 ```
 
-Around literals, `[…]ₓ` and `(…)ₓ` make every number exact, at any depth. Each number must be whole. After a list or group that holds anything else, as after a name, `ₓ` is [`⌊`](glyphs/downstile.qmd), as [Superscripts and subscripts](scripts.ipynb) describes. A vector of exact integers displays as `[…]ₓ`, and rows of them as `(…)ₓ`. `⍕` writes them the same way:
+Around literals, `[…]ₓ` and `(…)ₓ` make every number exact, at any depth. Each number must be whole. After a list or group that holds anything else, as after a name, `ₓ` floors to exact integers, as [Superscripts and subscripts](scripts.ipynb) describes. A vector of exact integers displays as `[…]ₓ`, and rows of them as `(…)ₓ`. `⍕` writes them the same way:
 
 ```bpl
 [1 0 1]ₓ≡1ₓ 0ₓ 1ₓ    ⍝ $t
@@ -209,7 +209,7 @@ The [`⌈`](glyphs/upstile.qmd) and [`⌊`](glyphs/downstile.qmd) pages give the
 
 ## Static kinds
 
-Some functions choose a result's kind from their arguments' values. `√¯4` is complex because the argument is negative, `1j0` is a float because its imaginary part is zero, and an exact integer that overflows grows. Under [`•prefs`](system/prefs.qmd) `["kinds":"static"]`, a result's kind follows from the function and its arguments' kinds alone. A fused computation needs that, because it decides each result's kind before it runs. Real arguments give real results, with NaN outside a function's domain, and complex results stay complex. `⌊`, `⌈` and monadic `×` of floats give floats, and integer `÷` gives floats:
+Some functions choose a result's kind from their arguments' values. `√¯4` is complex because the argument is negative, `1j0` is a float because its imaginary part is zero, and an exact integer that overflows grows. Under [`•prefs`](system/prefs.qmd) `["kinds":"static"]`, a result's kind follows from the function and its arguments' kinds alone. A fused computation needs that, because it decides each result's kind before it runs. Real arguments give real results, with NaN outside a function's domain, and complex results stay complex. `⌊`, `⌈` and monadic `×` of floats give floats, and integer `÷` gives floats. With `ₓ` after them they give integers, as Rust's `as` converts a float: NaN gives 0, and a value past the `int` width's range gives its largest or smallest integer:
 
 ```bpl
 •prefs ["kinds":"static"]
@@ -217,6 +217,9 @@ Some functions choose a result's kind from their arguments' values. `√¯4` is
 0j1×0j1              ⍝ ¯1ⱼ0
 ⌊2.5 ∞               ⍝ 2 ∞
 7ₓ÷2ₓ                ⍝ 3.5
+⌊ₓ2.5 ¯2.5           ⍝ [2 ¯3]ₓ
+7ₓ÷ₓ2ₓ               ⍝ 3ₓ
+⌊ₓ $n ∞              ⍝ [0 9223372036854775807]ₓ
 •prefs ["kinds":"dynamic"]
 ```
 

{basedpl-0.1.72 → basedpl-0.1.73}/nbs/python.ipynb

@@ -999,7 +999,7 @@
     "\n",
     "NumPy float and complex scalars keep their explicit widths, including inside sequences. A list's items combine under BPL's usual joining rules: `[1, 2.5]` gives two floats. A dict's values each keep their own kind, as a record's fields do. In `{\"name\": \"x\", \"age\": 3, \"score\": 2.5}`, `age` stays exact beside the float `score`. Its `name` is the character atom `'x'`.\n",
     "\n",
-    "`.np` or `np.asarray(a)` always produces an ndarray. Booleans use `bool`. Integers use the width BPL stores them at: `uint8`, `int16`, `int32` or `int64`. Floats use the width BPL stores them at, `float16`, `float32` or `float64`. A NumPy `float16` or `float32` array keeps its width in BPL. Complex arrays use `complex64` or `complex128`, preserving the stored width. Fractions, large integers, nested arrays and mixed exact and approximate values use `object`. Character arrays use `U1`. The arrays inside a `.py` result, and the columns of a `.df` result, use the same dtypes."
+    "`.np` or `np.asarray(a)` always produces an ndarray. Booleans use `bool`. Integers use the width BPL stores them at, `uint8`, `int16`, `int32` or `int64`, under dynamic kinds. Under static kinds they use the width they compute at, which is at least the `int` pref, so NumPy arithmetic on them wraps where BPL's does. Floats use the width BPL stores them at, `float16`, `float32` or `float64`. A NumPy `float16` or `float32` array keeps its width in BPL. Complex arrays use `complex64` or `complex128`, preserving the stored width. Fractions, large integers, nested arrays and mixed exact and approximate values use `object`. Character arrays use `U1`. The arrays inside a `.py` result, and the columns of a `.df` result, use the same dtypes."
    ]
   },
   {

{basedpl-0.1.72 → basedpl-0.1.73}/nbs/scripts.ipynb

@@ -962,7 +962,7 @@
    "id": "a2e00b5b",
    "metadata": {},
    "source": [
-    "The subscript letters `ₓ`, `ⱼ`, `ₑ` and `ᵣ` are parts of numbers, as in `3ₓ` and `1ᵣ3`. [Numbers](numbers.qmd) covers them. Between two other items, such as names, `ⱼ`, `ₑ` and `ᵣ` join the items into one [number](numbers.qmd#writing-numbers): `xⱼy` is `x+y×0ⱼ1`. After a name, or any item but a number or a list of literals, `ₓ` is [`⌊`](glyphs/downstile.qmd):"
+    "The subscript letters `ₓ`, `ⱼ`, `ₑ` and `ᵣ` are parts of numbers, as in `3ₓ` and `1ᵣ3`. [Numbers](numbers.qmd) covers them. Between two other items, such as names, `ⱼ`, `ₑ` and `ᵣ` join the items into one [number](numbers.qmd#writing-numbers): `xⱼy` is `x+y×0ⱼ1`, and `xᵣy` is the exact quotient of `xₓ` by `yₓ`, under static kinds too. After a name, or any item but a number or a list of literals, `ₓ` floors the item's numbers to exact integers. `xₓ` is `⌊ₓx`:"
    ]
   },
   {
@@ -986,6 +986,74 @@
     "xₓ"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "f58b3b2a",
+   "metadata": {},
+   "source": [
+    "After a function, `ₓ` floors the function's results to exact integers, under either kinds. Under static kinds, which keep a failed result, it converts as Rust's `as` converts a float, into the `int` width: NaN gives `0`, and a value past the width's range, `∞` included, gives its largest or smallest integer.\n",
+    "\n",
+    "`⌊ₓ`, `⌈ₓ` and dyadic `÷ₓ`, which divides and floors as Python's `//` does, each compute their integers in one pass:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "id": "fb125557",
+   "metadata": {},
+   "outputs": [
+    {
+     "data": {
+      "text/plain": [
+       "[3 ¯4 3]ₓ"
+      ]
+     },
+     "metadata": {},
+     "output_type": "display_data"
+    }
+   ],
+   "source": [
+    "7 ¯7 7.5÷ₓ2"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "255c7890",
+   "metadata": {},
+   "source": [
+    "A float width's marker, `ₕ`, `ₛ` or `ₚ`, works the same way. After a function it makes the function's results floats of that width, and after an array it converts the array, as [`•float`](system/float.qmd) does:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "id": "04c3990d",
+   "metadata": {},
+   "outputs": [
+    {
+     "data": {
+      "text/plain": [
+       "¯3ₛ"
+      ]
+     },
+     "metadata": {},
+     "output_type": "display_data"
+    },
+    {
+     "data": {
+      "text/plain": [
+       "[3.7 ¯2.5]ₛ"
+      ]
+     },
+     "metadata": {},
+     "output_type": "display_data"
+    }
+   ],
+   "source": [
+    "-ₛ 3\n",
+    "xₛ"
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "0181955a",
@@ -998,7 +1066,7 @@
     "- `SYNTAX`: `ⱼ`, `ₑ` or `ᵣ` beside a function or a space, as in `f←- ⋄ fⱼ1`\n",
     "- `INDEX`: the position is outside the leading axis\n",
     "- `LENGTH`: the item is a unit, which has no axis to select from\n",
-    "- `DOMAIN`: `ₓ` after a function, as in `+ₓ`"
+    "- `DOMAIN`: `ₓ` on a complex number, or under dynamic kinds on an infinity or NaN, as in `1÷ₓ0`"
    ]
   },
   {

{basedpl-0.1.72 → basedpl-0.1.73}/nbs/study/01_basics.ipynb

@@ -2618,7 +2618,7 @@
     {
      "data": {
       "text/plain": [
-       "0 0 2 3 3"
+       "3 4 5 2 4"
       ]
      },
      "metadata": {},
@@ -2638,7 +2638,7 @@
     {
      "data": {
       "text/plain": [
-       "0.5811181472 0.9743433567"
+       "0.6628167745 0.8427274246"
       ]
      },
      "metadata": {},
@@ -2674,7 +2674,7 @@
     {
      "data": {
       "text/plain": [
-       "8 48 42 32 4 21 37 49 28 19 43 20 25"
+       "3 20 28 11 1 42 4 36 10 15 39 38 7"
       ]
      },
      "metadata": {},

{basedpl-0.1.72 → basedpl-0.1.73}/nbs/syntax.qmd

@@ -37,7 +37,7 @@ Numbers, `∞`, `¯∞`, `⍬`, characters, strings and the constants `$t`, `$f`
 
 `''` and `""` are the same empty character vector. A double-quoted string can span lines. Every line ending inside it reads as one newline, and its indentation stays as written.
 
-`ₓ` straight after a number, `⍬`, or a `]` or `)` that closes literals makes every number it covers exact, as in `5ₓ`, `[1 2]ₓ` and `(0 1⋄2 3)ₓ`. After anything else, as in `nₓ`, `ₓ` is [`⌊`](glyphs/downstile.qmd).
+`ₓ` straight after a number, `⍬`, or a `]` or `)` that closes literals makes every number it covers exact, as in `5ₓ`, `[1 2]ₓ` and `(0 1⋄2 3)ₓ`. After anything else, `ₓ` floors to exact integers: `nₓ` is `⌊ₓn`, and `÷ₓ` divides and floors, as [Superscripts and subscripts](scripts.ipynb) describes.
 
 After a number, `e`, `j` or `r`, or its subscript `ₑ`, `ⱼ` or `ᵣ`, continues the number only when the rest of a number follows it, as in `1e5`, `2ⱼ3` and `1r3`. Otherwise a plain letter starts a name: `2edges` is `2` beside the name `edges`. A subscript there, or between any two items, joins the items on each side into one term, as [Numbers](numbers.qmd#writing-numbers) describes: `2ₑn` is `2×10*n`.
 

{basedpl-0.1.72 → basedpl-0.1.73}/nbs/system/explain.qmd

@@ -20,10 +20,10 @@
   - `"one call"` makes one call for targets at distinct positions.
   - `"item by item"` calls the function once for each target, as a dfn does.
 - `fallbacks` has a row for each [map](../terms.qmd#term-map) that called its operand once for each cell after its [batched call](../evaluation.qmd#functions-and-effects) fell back, or without a batched call because an earlier one stopped. `items` is the number of cells, and `reason` says why:
-  - `"an effect"`: the operand writes output, reads input, formats a cell's value with `⍕`, or runs a system function that acts, such as `•nget` or `•time`. A batched call would do each of these once for all the cells. A random draw in a map inside the operand stops it too, and so does a random draw on a side of a guard on a cell's value.
-  - `"a write"`: the operand writes to a name outside the map, or a side of a guard on a cell's value writes to a name outside its dfn.
+  - `"an effect"`: the operand writes output, reads input, formats a cell's value with `⍕`, or runs a system function that acts, such as `•nget` or `•time`. A batched call would do each of these once for all the cells.
+  - `"a write"`: the operand writes to a name outside the map, or a side of a guard on a cell's value writes to a name outside its dfn, or the operand appends to a value that differs from cell to cell, or writes into one so that it would be held in mixed storage.
   - `"a cell's value"`: the operand reads a cell's value to give a count or a position, as `2×⍣⍵` does. A predicate on a cell's value doesn't stop the batched call: each side of the guard runs once, on the cells that take it, as [Evaluation](../evaluation.qmd#functions-and-effects) describes.
-  - `"no batch rule"`: the operand calls a function with no rule for batches of these arguments, such as `⍋`, or the two sides of a guard on a cell's value give results of different kinds or shapes. Where the stop comes from a primitive's call, the primitive's glyph follows, as in `"no batch rule for ⍋"`. A kernel that reads a cell's number directly gives no glyph.
+  - `"no batch rule"`: the operand calls a function with no rule for batches of these arguments, such as `∪`, or the two sides of a guard on a cell's value give results of different kinds or shapes. Where the stop comes from a primitive's call, the primitive's glyph follows, as in `"no batch rule for ∪"`. A kernel that reads a cell's number directly gives no glyph.
   - `"too many items"`: a call would repeat an array that every cell shares into far more items than its arguments hold, and the array is too large for the map to run on chunks of cells instead, as [Evaluation](../evaluation.qmd#functions-and-effects) describes.
   - `"a caught error"`: a guard would catch an error.
   - `"a recursive call"`: a guard on a cell's value runs in a recursive call of a dfn whose guard already split the cells, as in `{⍵<2?⍵;(∇⍵-1)+∇⍵-2}¨v`.
@@ -39,11 +39,14 @@
   - `"item lanes"`: a fold or scan by a function with no kernel for its arguments, such as a primitive on mixed storage or a dfn on a lane that no batched map took, called the function on each pair of items in turn.
   - `"number parts"`: monadic [`∨`](../glyphs/vee.qmd) or [`∧`](../glyphs/wedge.qmd) took the parts of integers or exact numbers one at a time, where floats and complex numbers take one pass.
   - `"nested labels"`, `"label ids"` and `"label offsets"`: a selection from a nested array labelled or placed its items one at a time, or read positions that had no plan.
+  - `"key groups"`: [Key](../glyphs/quad-equal.qmd) called its operand once for each group, where no fast combination covered it.
+  - `"batch cells"`: a batched map ran a system function, or a deal by [`¿`](../glyphs/inverted-question.qmd), once for each cell in turn.
+  - `"inverse scan"`: the inverse of a scan by a function with no kernel called the function's inverse on each pair of neighbouring items in turn.
 - `declined` has a row for each faster route that code considered and didn't take. A decline explains why a slower route ran. `route` names the route, `reason` says why code didn't take it, and `items` counts the items that its declines concerned, summed for each route and reason. The routes are:
   - `"fusion"`: a call that could have joined a fused group ran on its own, because of `"16-bit floats"`, `"no float array"`, `"an exact argument"`, `"a result at another width"`, `"keys, names or a renderer"` or `"an argument of another kind or width, or with keys"`. A pending array also ran without a group where its call reads `"a comparison computed outside the graph"`.
   - `"fused fold"`: a fold computed its argument instead of reading through its group, because `"another array holds the array"`, as a name does, because the argument is `"a copy that no call moves under"` or reads `"a comparison computed outside the graph"`, or because of `"a fold that its graph can't run"`.
   - A fast combination's name, as in `"partial grade"`, with `"arguments that don't suit it"`: the general path ran instead.
-  - `"batching"`: a map didn't try a batched call, because `"the batch pref is off"`, because of `"a label level or another batched run"` or `"named axes"`, or because of `"an argument too large to lay over the frame"` or `"an argument that isn't compact or has a named axis"`.
+  - `"batching"`: a map didn't try a batched call, because `"the batch pref is off"`, because of `"a label level, or a ∂ call inside a batched run"` or `"named axes"`, or because of `"an argument too large to lay over the frame"` or `"an argument that isn't compact or has a named axis"`.
   - `"in place"`: a kernel copied an argument's items into a buffer instead of reading them where they are, because of `"repeats of each item"`, `"a cycle that wraps"`, `"steps other than a forward run"` or `"a repeated item"`.
 
 Each of `fused`, `stored`, `forced`, `fast`, `accumulations`, `fallbacks`, `mixed`, `itemwise` and `declined` is a record of columns, as `•csv` gives a table, so `(•explain t).fast.combination` lists the combinations taken. `•prefs ["fusion":$t]` writes each forcing call and assignment as it happens. Nothing is recorded outside `•explain`.

{basedpl-0.1.72 → basedpl-0.1.73}/nbs/system/prefs.qmd

@@ -33,7 +33,7 @@ Display shows part of an array of more than `limit` items: the first and last `e
 
 `float` sets the default width of floats, in bits: the width of bare numbers in code parsed after the change, of numbers that `•csv`, `•json`, `•vfi` and `•image` read, of random numbers, and of floats that a function gives from exact arguments. Code already parsed keeps its numbers. A change partway through some code therefore applies from the next input, or from text that [`⍎`](../glyphs/hydrant.qmd) parses later. Leading `•prefs` calls on a literal record are the exception. They run before the rest of their code is parsed, as in the examples below. A script, a notebook cell, a line typed at the REPL, a module that [`•load`](load.qmd) runs and text that `⍎` runs can each set its own width this way. See [Numbers](../numbers.qmd#float-widths).
 
-`kinds` sets whether a result's kind can depend on its arguments' values. Under the default, `"dynamic"`, `√¯4` gives `0ⱼ2`, `1j0` reads as the float `1`, `⌊2.5` gives the exact integer `2`, `7ₓ÷2ₓ` gives `7ᵣ2`, and exact integers grow without limit. Under `"static"`, each result's kind follows from the function, its arguments' kinds and these settings. Real arguments give real results, with NaN outside a function's domain. Complex results stay complex. `⌊`, `⌈` and monadic `×` of floats give floats, and integer `÷` gives floats. Integers compute at the `int` width, or at a wider integer's width, and wrap where a result doesn't fit. Exact fractions stay exact. An integer beside a float takes the float's width. An atom promotes as an array does. Fused computations and a GPU need each result's kind before they run, and under static kinds more calls fuse, as the examples under `fusion` show. A literal reads under the settings in force when its code is parsed, as with `float`. See [Numbers](../numbers.qmd#static-kinds).
+`kinds` sets whether a result's kind can depend on its arguments' values. Under the default, `"dynamic"`, `√¯4` gives `0ⱼ2`, `1j0` reads as the float `1`, `⌊2.5` gives the exact integer `2`, `7ₓ÷2ₓ` gives `7ᵣ2`, and exact integers grow without limit. Under `"static"`, each result's kind follows from the function, its arguments' kinds and these settings. Real arguments give real results, with NaN outside a function's domain. Complex results stay complex. `⌊`, `⌈` and monadic `×` of floats give floats, and integer `÷` gives floats, where `⌊ₓ`, `⌈ₓ`, `×ₓ` and `÷ₓ` give integers, converting as Rust's `as` does. Integers compute at the `int` width, or at a wider integer's width, and wrap where a result doesn't fit. Exact fractions stay exact. An integer beside a float takes the float's width. An atom promotes as an array does. Fused computations and a GPU need each result's kind before they run, and under static kinds more calls fuse, as the examples under `fusion` show. A literal reads under the settings in force when its code is parsed, as with `float`. See [Numbers](../numbers.qmd#static-kinds).
 
 `threads` sets how many threads large calls split across. A call splits only when it has enough work to repay the extra threads. Float results can differ in their last bits between thread counts. The default, 0, uses the number in the `RAYON_NUM_THREADS` environment variable where it's set, and one thread for each core otherwise. 1 runs every call on the thread that evaluates the code. When several BPL processes run at once, such as a pool of Python workers, set 1 in each of them to keep them from competing for the cores. The browser build runs every call on one thread, whatever the setting.
 

{basedpl-0.1.72 → basedpl-0.1.73}/py/src/lib.rs

@@ -309,20 +309,26 @@ impl PyArray {
     /// Whether NumPy can read the items through the buffer protocol: compact storage, or a structural copy that reads compact items through an affine map.
     #[getter]
     fn exports(&self) -> PyResult<bool> { Ok(lendable(self.value()?).is_some()) }
-    /// Exports the items read-only and without a copy, so that NumPy can't change a BPL value through them. An unbuilt structural copy with an affine read, such as windows or a reversal, lends its source's items with strides, without being built.
+    /// Exports the items read-only and without a copy, so that NumPy can't change a BPL value through them. An unbuilt structural copy with an affine read, such as windows or a reversal, lends its source's items with strides, without being built. Integers that static kinds store narrower than their kind export as a copy at the kind's width (`Value::widened_for_export`), so NumPy and rustymath compute at that width.
     unsafe fn __getbuffer__(slf: Bound<'_, Self>, view: *mut ffi::Py_buffer, flags: c_int) -> PyResult<()> {
         let value = slf.borrow().value()?.clone();
+        if let Some(items) = value.widened_for_export() {
+            let dtype = items.dtype();
+            // SAFETY: `items` holds every item of `value` in row-major order, and the export holds `items`.
+            return unsafe { rustymath_buffer::lend(view, flags, slf.py(), items, |b| b.view().as_ptr(), dtype, value.shape(), None) };
+        }
         let (items, offset, strides) = lendable(&value).ok_or_else(|| PyBufferError::new_err("an array of mixed or exact items has no buffer"))?;
         let dtype = items.view().expect("lendable items are compact").dtype();
         // SAFETY: the offset and strides reach only items of `items`, as the copy's map does. An atom holds its items inline, so the pointer comes from the copy that the export holds.
         unsafe { rustymath_buffer::lend(view, flags, slf.py(), items, |v| v.view().expect("the items are compact").as_ptr().add(offset * dtype.bytes()), dtype, value.shape(), strides.as_deref()) }
     }
-    /// The items for NumPy to view writably: moved with no copy where nothing else holds them, and copied otherwise. For items it can't move, such as exact numbers, it still empties the array and returns `None`, so the caller copies them first.
+    /// The items for NumPy to view writably: moved with no copy where nothing else holds them, and copied otherwise. Integers that static kinds store narrower than their kind come widened to it (`Value::widened_for_export`). For items it can't move, such as exact numbers, it still empties the array and returns `None`, so the caller copies them first.
     fn own(&mut self) -> PyResult<Option<Owned>> {
         self.value()?;
         let value = self.inner.take().expect("checked above");
         let shape = value.shape().to_vec();
-        Ok(value.into_buffer().ok().map(|items| Owned::new(items, &shape)))
+        let items = match value.widened_for_export() { Some(items) => Some(items), None => value.into_buffer().ok() };
+        Ok(items.map(|items| Owned::new(items, &shape)))
     }
     fn __repr__(&self) -> PyResult<String> { Ok(self.value()?.to_string()) }
     fn literal(&self) -> PyResult<String> { Ok(self.value()?.literal()) }