Runtime Initialization #
Casting helpers and shape-indexed initialization plans for executable modules. Runtime initializers can materialize parameter storage on the host or directly in CUDA buffers.
Runtime Float Initializers #
Runtime initializer for a Float parameter.
The usual ObjectiveDef.initState path stores initializers as typed Lean tensors. That is the
right representation when the initial value itself is part of the Lean object being inspected.
For large Float runs, it is better to allocate runtime storage from a compact initialization scheme
and synchronize the host tensor only when parameters are explicitly read back.
The design mirrors the storage-first APIs used by mainstream runtimes:
- PyTorch exposes in-place initializers such as
torch.nn.init.uniform_,torch.nn.init.xavier_uniform_, andtorch.nn.init.kaiming_uniform_for already-allocated tensors:https://pytorch.org/docs/stable/nn.init.html. - PyTorch's meta-device /
to_emptypath separates "module structure exists" from "real storage is materialized", after which users explicitly initialize parameters:https://docs.pytorch.org/docs/main/meta.html.
TorchLean keeps the semantic parameter type (Tensor Float s) available, but this runtime path lets
CPU/CUDA execution initialize real storage directly.
- zeros : FloatInit
Fill with zeros. PyTorch analogue:
torch.nn.init.zeros_. - ones : FloatInit
Fill with ones. PyTorch analogue:
torch.nn.init.ones_. - uniform
(lo hi : Float)
(seed : ℕ := 0)
: FloatInit
Seeded uniform interpolation between
loandhi, rounded in the parameter dtype. - normal
(mean std : Float)
(seed : ℕ := 0)
: FloatInit
Normal distribution with explicit mean and standard deviation.
- xavierUniform
(fanIn fanOut : ℕ)
(seed : ℕ := 0)
: FloatInit
Xavier/Glorot uniform with explicit fan-in and fan-out.
- kaimingUniform
(fanIn : ℕ)
(seed : ℕ := 0)
: FloatInit
Kaiming/He uniform with explicit fan-in.
- flat
(values : FloatArray)
: FloatInit
Exact row-major payload. Used for imported checkpoints or generated tensors.
Instances For
Translate a proof-visible initializer scheme into its storage-first runtime form.
Instances For
A shape-indexed initialization plan.
This is the typed runtime-initialization API for modules with a known parameter shape list. It is
the initialization analogue of TorchLean.TensorPack: the type says there is exactly one
initializer for each parameter shape, in the same order. That removes the runtime failure mode
where a plain list is one element too short or too long.
The initializers themselves are runtime schemes rather than proof objects. Proofs still concern
the ordinary Tensor Float s parameter value; this plan only controls how the executable
Float runtime materializes those tensors on CPU or CUDA.
- nil : Plan []
No parameters, no initializers.
- cons
{s : Spec.Shape}
{ss : List Spec.Shape}
(init : FloatInit)
(rest : Plan ss)
: Plan (s :: ss)
Initializer for the head parameter, followed by the plan for the remaining parameters.
Instances For
Concatenate two shape-indexed initializer plans.
Instances For
Append initializers in plan order, preserving the existing array prefix.
Instances For
Forget the shape index, pushing initializers into the result in parameter order.
Instances For
The type index is not decorative: forgetting a Plan ss to an array produces exactly ss.length
initializers. This checked fact lets the runtime API avoid the usual
"initializer sequence does not match parameter list" class of bugs once a plan has been built.
Validate every initializer against its parameter shape before applying the plan.
Instances For
Recover a shape-indexed plan from a runtime-sized initializer array.
Instances For
Instances For
Infer (fanIn, fanOut) from a parameter shape using the common linear/conv convention.
For a matrix shaped [out, in], this returns (in, out). For convolution-like weights shaped
[outChannels, inChannels, k1, ..., kd], it returns:
$$ \begin{aligned} \operatorname{fanIn} &=\operatorname{inChannels}\,k_1\cdots k_d,\\ \operatorname{fanOut} &=\operatorname{outChannels}\,k_1\cdots k_d. \end{aligned} $$
This is the same fan convention documented by PyTorch's Xavier/Kaiming initialization utilities.
Instances For
Build a Xavier initializer by deriving fan-in/fan-out from a Linear/Conv-style weight shape.
Instances For
Build a Kaiming initializer by deriving fan-in from a Linear/Conv-style weight shape.
Instances For
Deterministic unit sample shared with the pure tensor initializer.
Calling the canonical sampler here keeps CPU storage-first initialization equal to the semantic tensor initializer. The CUDA path uses the same SplitMix64 key/index sequence, materialized as device values in the parameter dtype.
Instances For
Materialize an initializer as a host FloatArray.
CPU execution uses this path directly. CUDA uses it only when the initializer already is an exact flat payload; analytic initializers such as uniform/Xavier/Kaiming are created on the runtime side.
Instances For
Allocate a CUDA buffer of seeded uniform draws between lo and hi.
Element generation stays on the device. A representable span keeps the ordinary fused affine formula. If the span overflows in the destination dtype while both endpoints remain finite, interpolate the endpoints separately instead.
Instances For
Allocate a CUDA buffer for a FloatInit.
For analytic schemes (zeros, ones, uniform, xavierUniform, kaimingUniform), this avoids
building a large nested Lean tensor. For .flat, the caller already supplied the exact payload, so
we upload that payload directly.
Instances For
Materialize a runtime initializer as a normal host tensor. Used for CPU execution.
Instances For
Apply a plan after the public entrypoint has validated every initializer.
Instances For
Apply a shape-indexed initialization plan to an already-created parameter list.
The shape list appears on both sides of the type:
Torch.ParamList α ss → RuntimeInit.Plan ss → IO Unit
The complete plan is validated before any parameter is mutated, so an invalid later initializer cannot leave the module partially initialized.