@classytic/stage 0.2.0 → 0.4.0

package/dist/physics/electrostatics/index.d.mts

@@ -0,0 +1,169 @@
+declare namespace coulomb_d_exports {
+  export { COULOMB_CONSTANT, Contribution, ELEMENTARY_CHARGE, EPSILON_0, MIN_SEPARATION_M, PointCharge, Resultant, Vec, angleDeg, contributionsAt, coulombForce, fieldAt, forceOn, magnitude, nullPointOnAxis, potentialAt, resolve, resultant, uniformFieldVPerM, validateCharges };
+}
+/**
+ * @classytic/stage/field/electrostatics — Coulomb's law with real constants, and superposition done as a VECTOR sum you can show your work
+ * for.
+ *
+ * ── Why this is not `@classytic/stage/field` ────────────────────────────────────────────────────
+ * That kernel already superposes point charges, and it is the right thing for what it does: it
+ * draws field lines. It works in normalised teaching units (`k = 1`) and adds a softening term to
+ * r² so a line traced INTO a charge does not divide by zero and blow the drawing up.
+ *
+ * Both of those choices are correct for drawing and fatal for answering. A student asked for the
+ * field 2 cm from a 5 nC charge needs 1.12 × 10⁵ N C⁻¹, and a kernel with `k = 1` cannot produce a
+ * number with units at all. The softening term is worse than useless here: it silently returns a
+ * finite, wrong answer at small separations rather than telling anyone the question was malformed.
+ *
+ * So this file computes and that one draws, and neither should grow the other's job.
+ *
+ * ── Why it returns contributions, not just a total ──────────────────────────────────────────────
+ * The exam skill is not evaluating kq/r². It is the bookkeeping: work out each charge's
+ * contribution, resolve each into components, add the components separately, then recombine into a
+ * magnitude and a direction. Students lose marks in the middle of that, not at the ends, and a
+ * function that returns only the resultant cannot show them where.
+ *
+ * So `contributionsAt` hands back every intermediate a marker would want to see, and `resultant`
+ * does the recombination. The lab draws those; the tests check them.
+ *
+ * ── The trap this file exists to make visible ───────────────────────────────────────────────────
+ * Field and force superpose as VECTORS. Potential superposes as a SCALAR. Two equal and opposite
+ * charges viewed from a point equidistant from both give a potential of exactly zero and a field
+ * that is emphatically not zero, and every year students report one when asked for the other.
+ * `potentialAt` is here specifically so a lesson can put the two side by side.
+ */
+interface Vec {
+  x: number;
+  y: number;
+}
+/** 1/(4πε₀), in N m² C⁻². The 9 × 10⁹ every textbook rounds it to. */
+declare const COULOMB_CONSTANT = 8987551787.368176;
+/** Permittivity of free space, in F m⁻¹. */
+declare const EPSILON_0 = 8.8541878128e-12;
+/** Elementary charge, in coulombs. */
+declare const ELEMENTARY_CHARGE = 1.602176634e-19;
+/**
+ * A point charge. Charge in MICROCOULOMBS and position in METRES, because that is how every
+ * question is written and converting at the boundary is better than converting in six places.
+ */
+interface PointCharge {
+  id: string;
+  /** Charge in microcoulombs. Signed. */
+  microCoulomb: number;
+  /** Position in metres. */
+  at: Vec;
+  label?: string;
+}
+/** One charge's share of the field or force at a point, with everything a marker would check. */
+interface Contribution {
+  from: string;
+  /** Separation from that charge to the point, in metres. */
+  distanceM: number;
+  /** Magnitude of this contribution alone. N C⁻¹ for a field, N for a force. */
+  magnitude: number;
+  /** The same contribution as components. */
+  vector: Vec;
+  /** Direction in degrees, measured anticlockwise from the +x axis. */
+  angleDeg: number;
+  /** True when the contribution points AWAY from the source charge, which is what a + charge does. */
+  outward: boolean;
+}
+interface Resultant {
+  vector: Vec;
+  magnitude: number;
+  /** Degrees anticlockwise from the +x axis, in (-180, 180]. */
+  angleDeg: number;
+}
+/**
+ * How close a field point may sit to a charge before the question is judged malformed.
+ *
+ * A millimetre, which is far below any separation a question uses and far above the rounding of a
+ * position typed in centimetres. THROWING here rather than softening is the whole point: at a point
+ * charge the field is genuinely undefined, and returning a large finite number would let a lesson
+ * ask a question that has no answer and get one anyway.
+ */
+declare const MIN_SEPARATION_M = 0.001;
+declare function validateCharges(charges: readonly PointCharge[]): readonly PointCharge[];
+/**
+ * Magnitude and direction of a 2D vector.
+ *
+ * Both delegate to `compose` in `physics/vectors.ts`, which is where this
+ * package already resolves and recombines components. Writing the hypot and
+ * the atan2 again here would be a third copy of the same two lines, and the
+ * degrees convention would then be free to drift between them.
+ */
+declare const magnitude: (v: Vec) => number;
+/** Degrees anticlockwise from the +x axis. Returns 0 for a zero vector rather than NaN. */
+declare const angleDeg: (v: Vec) => number;
+/**
+ * Resolve a magnitude and direction into components, the step students are
+ * asked to show.
+ *
+ * Delegates to `resolve` in `physics/vectors.ts`, which additionally snaps a
+ * component that is zero-but-for-rounding relative to the magnitude. A field at
+ * exactly 90 degrees should report an x-component of 0, not 6e-17 times the
+ * field strength, and that is a judgement about scale which belongs in one
+ * place rather than in every domain that resolves a vector.
+ */
+declare const resolve: (mag: number, degrees: number) => Vec;
+/** Add components separately, then recombine. The whole method, in one function. */
+/**
+ * Superpose 2D vectors by adding their components.
+ *
+ * Delegates to `resultant` in `physics/dynamics/forces.ts`. Adding two columns
+ * of numbers is not electrostatics, and a field superposition and a force
+ * superposition that disagreed about the angle convention would be a genuinely
+ * confusing bug to chase. The only thing kept here is the RETURN SHAPE: this
+ * layer hands back the vector itself, which a field diagram needs in order to
+ * draw the arrow, where a force table only ever wanted the magnitude.
+ */
+declare function resultant(vectors: readonly Vec[]): Resultant;
+/**
+ * Every charge's separate contribution to the electric field at a point, in N C⁻¹.
+ *
+ * A positive charge contributes a vector pointing AWAY from itself; a negative one points back
+ * toward itself. That sign handling is the single most common slip, so `outward` is reported
+ * explicitly rather than left for a reader to infer from the components.
+ */
+declare function contributionsAt(charges: readonly PointCharge[], point: Vec): Contribution[];
+/** The resultant electric field at a point, in N C⁻¹. */
+declare function fieldAt(charges: readonly PointCharge[], point: Vec): Resultant;
+/**
+ * The force on a test charge placed at a point, in newtons.
+ *
+ * F = qE, so a negative test charge feels a force ANTIPARALLEL to the field. Worth its own function
+ * rather than asking every caller to multiply, because that sign is the second most common slip
+ * after the one in `contributionsAt`.
+ */
+declare function forceOn(charges: readonly PointCharge[], point: Vec, testMicroCoulomb: number): Resultant;
+/** The force one point charge exerts on another, straight from Coulomb's law. */
+declare function coulombForce(a: PointCharge, b: PointCharge): number;
+/**
+ * The electric potential at a point, in volts.
+ *
+ * Added as a plain SUM of signed terms, with no components and no angles, because potential is a
+ * scalar. Putting it beside `fieldAt` in the same file is deliberate: the two differ in exactly the
+ * way students get wrong, and a lesson that shows a point where V = 0 while E is large teaches the
+ * distinction in one screen.
+ */
+declare function potentialAt(charges: readonly PointCharge[], point: Vec): number;
+/**
+ * Where on the line joining two charges the resultant field is zero.
+ *
+ * Returns a distance measured from the FIRST charge, along the line toward the second, in metres.
+ * A negative answer means the point lies on the far side of the first charge, which is the correct
+ * and frequently surprising result for two unlike charges.
+ *
+ *     |q₁| / x²  =  |q₂| / (d − x)²      so with  r = √(|q₂|/|q₁|):
+ *
+ *     like charges     the null sits BETWEEN them:        x = d / (1 + r)
+ *     unlike charges   it sits OUTSIDE, beyond the smaller magnitude:  x = d / (1 − r)
+ *
+ * Two unlike charges of EQUAL magnitude have no null point anywhere: r = 1 and the second formula
+ * divides by zero, which is the algebra telling the truth rather than failing. That returns null.
+ */
+declare function nullPointOnAxis(microCoulombA: number, microCoulombB: number, separationM: number): number | null;
+/** The uniform field between parallel plates, in V m⁻¹, which is the same unit as N C⁻¹. */
+declare function uniformFieldVPerM(plateVolts: number, separationM: number): number;
+//#endregion
+export { COULOMB_CONSTANT, Contribution, ELEMENTARY_CHARGE, EPSILON_0, MIN_SEPARATION_M, PointCharge, Resultant, Vec, angleDeg, contributionsAt, coulombForce, coulomb_d_exports, fieldAt, forceOn, magnitude, nullPointOnAxis, potentialAt, resolve, resultant, uniformFieldVPerM, validateCharges };

package/dist/physics/electrostatics/index.mjs

@@ -0,0 +1,249 @@
+import { __exportAll } from "../../_virtual/_rolldown/runtime.mjs";
+import { compose, resolve as resolve$1 } from "../vectors.mjs";
+import { resultant as resultant$1 } from "../dynamics/forces.mjs";
+
+//#region src/physics/electrostatics/coulomb.ts
+/**
+* @classytic/stage/field/electrostatics — Coulomb's law with real constants, and superposition done as a VECTOR sum you can show your work
+* for.
+*
+* ── Why this is not `@classytic/stage/field` ────────────────────────────────────────────────────
+* That kernel already superposes point charges, and it is the right thing for what it does: it
+* draws field lines. It works in normalised teaching units (`k = 1`) and adds a softening term to
+* r² so a line traced INTO a charge does not divide by zero and blow the drawing up.
+*
+* Both of those choices are correct for drawing and fatal for answering. A student asked for the
+* field 2 cm from a 5 nC charge needs 1.12 × 10⁵ N C⁻¹, and a kernel with `k = 1` cannot produce a
+* number with units at all. The softening term is worse than useless here: it silently returns a
+* finite, wrong answer at small separations rather than telling anyone the question was malformed.
+*
+* So this file computes and that one draws, and neither should grow the other's job.
+*
+* ── Why it returns contributions, not just a total ──────────────────────────────────────────────
+* The exam skill is not evaluating kq/r². It is the bookkeeping: work out each charge's
+* contribution, resolve each into components, add the components separately, then recombine into a
+* magnitude and a direction. Students lose marks in the middle of that, not at the ends, and a
+* function that returns only the resultant cannot show them where.
+*
+* So `contributionsAt` hands back every intermediate a marker would want to see, and `resultant`
+* does the recombination. The lab draws those; the tests check them.
+*
+* ── The trap this file exists to make visible ───────────────────────────────────────────────────
+* Field and force superpose as VECTORS. Potential superposes as a SCALAR. Two equal and opposite
+* charges viewed from a point equidistant from both give a potential of exactly zero and a field
+* that is emphatically not zero, and every year students report one when asked for the other.
+* `potentialAt` is here specifically so a lesson can put the two side by side.
+*/
+/** A plain 2-D vector. Deliberately local: this file must not depend on any rendering package. */
+var coulomb_exports = /* @__PURE__ */ __exportAll({
+	COULOMB_CONSTANT: () => COULOMB_CONSTANT,
+	ELEMENTARY_CHARGE: () => ELEMENTARY_CHARGE,
+	EPSILON_0: () => EPSILON_0,
+	MIN_SEPARATION_M: () => MIN_SEPARATION_M,
+	angleDeg: () => angleDeg,
+	contributionsAt: () => contributionsAt,
+	coulombForce: () => coulombForce,
+	fieldAt: () => fieldAt,
+	forceOn: () => forceOn,
+	magnitude: () => magnitude,
+	nullPointOnAxis: () => nullPointOnAxis,
+	potentialAt: () => potentialAt,
+	resolve: () => resolve,
+	resultant: () => resultant,
+	uniformFieldVPerM: () => uniformFieldVPerM,
+	validateCharges: () => validateCharges
+});
+/** 1/(4πε₀), in N m² C⁻². The 9 × 10⁹ every textbook rounds it to. */
+const COULOMB_CONSTANT = 8987551787.368176;
+/** Permittivity of free space, in F m⁻¹. */
+const EPSILON_0 = 88541878128e-22;
+/** Elementary charge, in coulombs. */
+const ELEMENTARY_CHARGE = 1602176634e-28;
+const finite = (value, what) => {
+	if (!Number.isFinite(value)) throw new RangeError(`${what} must be a finite number`);
+	return value;
+};
+/**
+* How close a field point may sit to a charge before the question is judged malformed.
+*
+* A millimetre, which is far below any separation a question uses and far above the rounding of a
+* position typed in centimetres. THROWING here rather than softening is the whole point: at a point
+* charge the field is genuinely undefined, and returning a large finite number would let a lesson
+* ask a question that has no answer and get one anyway.
+*/
+const MIN_SEPARATION_M = .001;
+function validateCharges(charges) {
+	const seen = /* @__PURE__ */ new Set();
+	for (const c of charges) {
+		if (seen.has(c.id)) throw new RangeError(`duplicate charge id ${c.id}`);
+		seen.add(c.id);
+		finite(c.microCoulomb, `charge ${c.id}`);
+		finite(c.at.x, `charge ${c.id} x`);
+		finite(c.at.y, `charge ${c.id} y`);
+	}
+	return charges;
+}
+/**
+* Magnitude and direction of a 2D vector.
+*
+* Both delegate to `compose` in `physics/vectors.ts`, which is where this
+* package already resolves and recombines components. Writing the hypot and
+* the atan2 again here would be a third copy of the same two lines, and the
+* degrees convention would then be free to drift between them.
+*/
+const magnitude = (v) => compose(v.x, v.y).magnitude;
+/** Degrees anticlockwise from the +x axis. Returns 0 for a zero vector rather than NaN. */
+const angleDeg = (v) => v.x === 0 && v.y === 0 ? 0 : compose(v.x, v.y).angleDeg;
+/**
+* Resolve a magnitude and direction into components, the step students are
+* asked to show.
+*
+* Delegates to `resolve` in `physics/vectors.ts`, which additionally snaps a
+* component that is zero-but-for-rounding relative to the magnitude. A field at
+* exactly 90 degrees should report an x-component of 0, not 6e-17 times the
+* field strength, and that is a judgement about scale which belongs in one
+* place rather than in every domain that resolves a vector.
+*/
+const resolve = (mag, degrees) => resolve$1(finite(mag, "magnitude"), finite(degrees, "angle"));
+/** Add components separately, then recombine. The whole method, in one function. */
+/**
+* Superpose 2D vectors by adding their components.
+*
+* Delegates to `resultant` in `physics/dynamics/forces.ts`. Adding two columns
+* of numbers is not electrostatics, and a field superposition and a force
+* superposition that disagreed about the angle convention would be a genuinely
+* confusing bug to chase. The only thing kept here is the RETURN SHAPE: this
+* layer hands back the vector itself, which a field diagram needs in order to
+* draw the arrow, where a force table only ever wanted the magnitude.
+*/
+function resultant(vectors) {
+	const summed = resultant$1(vectors.map((v, i) => ({
+		label: `v${i}`,
+		x: v.x,
+		y: v.y
+	})));
+	return {
+		vector: {
+			x: summed.x,
+			y: summed.y
+		},
+		magnitude: summed.magnitude,
+		angleDeg: summed.angleDeg
+	};
+}
+/**
+* Every charge's separate contribution to the electric field at a point, in N C⁻¹.
+*
+* A positive charge contributes a vector pointing AWAY from itself; a negative one points back
+* toward itself. That sign handling is the single most common slip, so `outward` is reported
+* explicitly rather than left for a reader to infer from the components.
+*/
+function contributionsAt(charges, point) {
+	validateCharges(charges);
+	finite(point.x, "point x");
+	finite(point.y, "point y");
+	return charges.map((charge) => {
+		const dx = point.x - charge.at.x;
+		const dy = point.y - charge.at.y;
+		const distanceM = Math.hypot(dx, dy);
+		if (distanceM < .001) throw new RangeError(`the field point sits on charge ${charge.id}; the field there is undefined, not large`);
+		const signed = COULOMB_CONSTANT * (charge.microCoulomb * 1e-6) / (distanceM * distanceM);
+		const vector = {
+			x: signed * dx / distanceM,
+			y: signed * dy / distanceM
+		};
+		return {
+			from: charge.id,
+			distanceM,
+			magnitude: Math.abs(signed),
+			vector,
+			angleDeg: angleDeg(vector),
+			outward: charge.microCoulomb > 0
+		};
+	});
+}
+/** The resultant electric field at a point, in N C⁻¹. */
+function fieldAt(charges, point) {
+	return resultant(contributionsAt(charges, point).map((c) => c.vector));
+}
+/**
+* The force on a test charge placed at a point, in newtons.
+*
+* F = qE, so a negative test charge feels a force ANTIPARALLEL to the field. Worth its own function
+* rather than asking every caller to multiply, because that sign is the second most common slip
+* after the one in `contributionsAt`.
+*/
+function forceOn(charges, point, testMicroCoulomb) {
+	const field = fieldAt(charges, point);
+	const q = finite(testMicroCoulomb, "test charge") * 1e-6;
+	const vector = {
+		x: field.vector.x * q,
+		y: field.vector.y * q
+	};
+	return {
+		vector,
+		magnitude: magnitude(vector),
+		angleDeg: angleDeg(vector)
+	};
+}
+/** The force one point charge exerts on another, straight from Coulomb's law. */
+function coulombForce(a, b) {
+	const dx = b.at.x - a.at.x;
+	const dy = b.at.y - a.at.y;
+	const r = Math.hypot(dx, dy);
+	if (r < .001) throw new RangeError("the two charges are at the same point");
+	return COULOMB_CONSTANT * Math.abs(a.microCoulomb * 1e-6) * Math.abs(b.microCoulomb * 1e-6) / (r * r);
+}
+/**
+* The electric potential at a point, in volts.
+*
+* Added as a plain SUM of signed terms, with no components and no angles, because potential is a
+* scalar. Putting it beside `fieldAt` in the same file is deliberate: the two differ in exactly the
+* way students get wrong, and a lesson that shows a point where V = 0 while E is large teaches the
+* distinction in one screen.
+*/
+function potentialAt(charges, point) {
+	validateCharges(charges);
+	let volts = 0;
+	for (const charge of charges) {
+		const distanceM = Math.hypot(point.x - charge.at.x, point.y - charge.at.y);
+		if (distanceM < .001) throw new RangeError(`the point sits on charge ${charge.id}; the potential there is undefined`);
+		volts += COULOMB_CONSTANT * charge.microCoulomb * 1e-6 / distanceM;
+	}
+	return volts;
+}
+/**
+* Where on the line joining two charges the resultant field is zero.
+*
+* Returns a distance measured from the FIRST charge, along the line toward the second, in metres.
+* A negative answer means the point lies on the far side of the first charge, which is the correct
+* and frequently surprising result for two unlike charges.
+*
+*     |q₁| / x²  =  |q₂| / (d − x)²      so with  r = √(|q₂|/|q₁|):
+*
+*     like charges     the null sits BETWEEN them:        x = d / (1 + r)
+*     unlike charges   it sits OUTSIDE, beyond the smaller magnitude:  x = d / (1 − r)
+*
+* Two unlike charges of EQUAL magnitude have no null point anywhere: r = 1 and the second formula
+* divides by zero, which is the algebra telling the truth rather than failing. That returns null.
+*/
+function nullPointOnAxis(microCoulombA, microCoulombB, separationM) {
+	const qa = Math.abs(finite(microCoulombA, "first charge"));
+	const qb = Math.abs(finite(microCoulombB, "second charge"));
+	const d = finite(separationM, "separation");
+	if (d <= 0) throw new RangeError("separation must be positive");
+	if (qa === 0 || qb === 0) return null;
+	const ratio = Math.sqrt(qb / qa);
+	if (microCoulombA * microCoulombB > 0) return d / (1 + ratio);
+	if (Math.abs(ratio - 1) < 1e-12) return null;
+	return d / (1 - ratio);
+}
+/** The uniform field between parallel plates, in V m⁻¹, which is the same unit as N C⁻¹. */
+function uniformFieldVPerM(plateVolts, separationM) {
+	const d = finite(separationM, "plate separation");
+	if (d <= 0) throw new RangeError("plate separation must be positive");
+	return finite(plateVolts, "plate p.d.") / d;
+}
+
+//#endregion
+export { COULOMB_CONSTANT, ELEMENTARY_CHARGE, EPSILON_0, MIN_SEPARATION_M, angleDeg, contributionsAt, coulombForce, coulomb_exports, fieldAt, forceOn, magnitude, nullPointOnAxis, potentialAt, resolve, resultant, uniformFieldVPerM, validateCharges };

package/dist/physics/energy/centre-of-mass.d.mts

@@ -0,0 +1,115 @@
+import { Worked } from "../../core/worked.mjs";
+import { Sweep } from "../integral-sweep.mjs";
+
+//#region src/physics/energy/centre-of-mass.d.ts
+/**
+ * The general statement: work against gravity is `mg` times the rise of the centre of mass.
+ *
+ * Everything else in this file is this function with the two heights worked out for a particular
+ * shape. Having it exist separately is the point, because it is what a learner should reach for when
+ * they meet a shape nobody has tabulated.
+ */
+declare function centreOfMassLift(mass: number, fromHeight: number, toHeight: number, g?: number, sf?: number): {
+  readonly rise: number;
+  readonly value: number;
+  readonly worked: Worked;
+};
+/**
+ * Standing a uniform block on a different face: the brick question.
+ *
+ * A uniform body's centre of mass sits at the middle, so lying on a face it is half the THICKNESS
+ * above the table, and stood on end it is half the LENGTH. The rise is half the difference, and the
+ * other two dimensions never enter, which surprises people who were carefully multiplying all three.
+ */
+declare function standBlockOnEnd(mass: number, lyingDimension: number, standingDimension: number, g?: number, sf?: number): {
+  readonly rise: number;
+  readonly value: number;
+  readonly worked: Worked;
+};
+/**
+ * Tipping a hinged rod (or a hinged plank) through an angle from the vertical.
+ *
+ * The centre of mass of a uniform rod is at its midpoint, so it traces a circle of radius `l/2`, and
+ * the rise is `(l/2)(1 − cos θ)`: the pendulum geometry again, with the length halved because the
+ * mass is spread rather than hanging at the end. That reuse is worth naming out loud, because a
+ * learner who sees the same `(1 − cos θ)` in a swing and in a toppling rod has genuinely learned the
+ * geometry rather than two formulas.
+ */
+declare function tiltRod(mass: number, length: number, angleFromVerticalDeg: number, g?: number, sf?: number): {
+  readonly rise: number;
+  readonly value: number;
+  readonly worked: Worked;
+};
+interface StackResult {
+  readonly value: number;
+  /** How far each brick had to rise, in order. The first is always zero. */
+  readonly rises: readonly number[];
+  /** `n(n − 1)/2`, which is also the number of PAIRS of bricks. */
+  readonly triangleNumber: number;
+  readonly worked: Worked;
+}
+/**
+ * Building a column out of `count` identical bricks that all start lying on the ground.
+ *
+ * DERIVED, NOT QUOTED. The textbook prints `W = ⁿC₂ mgh` and a binomial coefficient appearing in a
+ * mechanics problem looks like a conjuring trick. It is not: the bottom brick does not move, the
+ * next rises `h`, the next `2h`, and adding `0 + 1 + 2 + ... + (n−1)` gives `n(n−1)/2`, which is the
+ * triangle number and which happens to equal `ⁿC₂`. The coefficient is a coincidence of arithmetic,
+ * not a combinatorial insight, and saying so is more honest than letting it look profound.
+ *
+ * `height` is the thickness of one brick, which is how far each brick sits above the one below it.
+ */
+declare function stackColumn(count: number, massEach: number, height: number, g?: number, sf?: number): StackResult;
+/**
+ * Hauling a chain up a well, with a load on the end.
+ *
+ * Two contributions and they rise by different amounts, which is the entire question. The load on
+ * the end travels the full depth. The chain's centre of mass starts halfway down and finishes at the
+ * top, so it rises only HALF the depth. Treating the chain as though all of it climbed the full
+ * depth doubles its share, and the resulting answer is wrong by an amount that depends on how heavy
+ * the chain is relative to the load, which is why it can pass unnoticed.
+ */
+declare function chainLift(depth: number, chainMassPerMetre: number, loadMass: number, g?: number, sf?: number): {
+  readonly chainWork: number;
+  readonly loadWork: number;
+  readonly value: number;
+  readonly chainMass: number;
+  readonly worked: Worked;
+};
+interface DrainResult {
+  readonly mass: number;
+  /** The distance the centre of mass of the liquid actually rose. */
+  readonly meanLift: number;
+  readonly value: number;
+  /** What you would have got by using the full height for every drop: the classic wrong answer. */
+  readonly naiveValue: number;
+  /** The integral, layer by layer, ready to animate. */
+  readonly sweep: Sweep;
+  readonly worked: Worked;
+}
+/**
+ * Pumping every drop of liquid out over the rim of an upright container.
+ *
+ * The layer at height `y` has to rise `(H − y)`, so the work is `∫ ρgA(H − y) dy` over whatever is
+ * actually in there. The integral is performed symbolically by the shared integrator, so the sweep
+ * this returns can be animated as layers leaving one at a time while the running total fills, and
+ * the number on the meter is the real antiderivative rather than a sum of rectangles.
+ *
+ * `fillFraction` is how full it is, measured from the BOTTOM. The mean lift comes out as
+ * `H(1 − f/2)`, which is worth reading twice: a FULL tank has the lowest mean lift of all, `H/2`,
+ * because most of its water is near the bottom where there is a lot of water and the top layers cost
+ * almost nothing. A quarter-full tank lifts its water `7H/8` on average, because all of it is at the
+ * bottom and all of it has nearly the whole height to travel. The emptier the tank, the harder each
+ * kilogram is to get out.
+ */
+declare function columnDrain(height: number, crossSection: number, fillFraction?: number, density?: number, g?: number, sf?: number): DrainResult;
+/**
+ * The mean lift alone, for feeding into {@link pumpPower}.
+ *
+ * A well being pumped dry is the `fillFraction = 1` case, where the mean lift is half the depth. It
+ * is its own named function because that is the number a power question needs and because writing
+ * `depth / 2` inline in a pump calculation is how the reasoning gets lost.
+ */
+declare const meanLiftToRim: (height: number, fillFraction?: number) => number;
+//#endregion
+export { DrainResult, StackResult, centreOfMassLift, chainLift, columnDrain, meanLiftToRim, stackColumn, standBlockOnEnd, tiltRod };