Evaluate at the basis's own precision, and check the node differences

[michakraus]

Four items left open as non-blocking in the #24 review. Two are real defects, two are cosmetic. Pkg.test() goes from 2903 assertions to 3519, all green, and no existing assertion moves.

Evaluation ran at the argument's precision, not the basis's

A basis of extended precision reported a precision it did not carry:

b = Legendre(BigFloat, 6)
b[0.3, 5] == b[BigFloat(0.3), 5]        # false before, true now

Legendre widened only the trailing √(2j+1) factor, so Bonnet's recurrence itself ran in Float64 — the returned BigFloat was correct to 1.3e-16 relative and no further. This is the same class of bug as the Lagrange buffers fixed in 0.3.0, which allocated in Float64 regardless of T.

Bernstein and Chebyshev did not widen at all and returned a Float64 outright, although their derivative evaluators already promoted the argument — so a basis and its own derivative disagreed about their element type.

All six evaluators now convert the argument first. The conversion lives in the closures rather than in getindex, because basis(b)[j](x) == b[x,j] is documented and basis hands those closures out.

The promotion only ever widens, so an argument more precise than the basis is untouched and every value at matching precision is unchanged — which is why no existing assertion moves. Lagrange needed no change; it promotes elementwise against its own nodes.

The conversion has to precede the shift

The first pass at this put the conversion in the wrong place: it widened 2y-1 rather than y, so the shift onto [-1,1] still ran at the argument's precision and the widening only recorded its rounding in more digits. That reaches the three evaluators listed above as already correct — Legendre's derivative and both of Chebyshev's — which promoted, but promoted the shifted value.

What made it easy to miss is that 2y-1 is exact in Float64 for y ≥ 0.25 by Sterbenz, so every point the tests sampled (0.3, 0.75, 1.0) agreed regardless. At 0.1 it rounds, and the frozen-in error is 5.6e-17:

setprecision(BigFloat, 256) do
    b = Legendre(BigFloat, 6)
    b[0.1, 5] == b[BigFloat(0.1), 5]    # false with the conversion after the shift
end

basis_tests.jl now samples 0.1 alongside the points above a quarter, and asserts the widening direction on the derivatives as well as the bases, so the ordering cannot be lost again.

Lagrange accepted degenerate node sets

allunique compares with isequal, which asks a different question from the one the denominators need answered:

allunique([0.0, -0.0])      # true — yet 0.0 - (-0.0) is 0.0
Lagrange([0.0, -0.0])       # accepted, denominators Inf
Lagrange([0.0, NaN, 1.0])   # accepted, every value NaN

The constructor already forms the product of differences that each denominator inverts, so that product is now what has to come out usable. Repeated nodes throw as before, repeated NaN still throws, and -0.0 is still a good node among distinct ones.

The three ways it can fail are told apart, because a degenerate product does not on its own say which one occurred. Distinct, finite nodes give exactly the same product when their differences are not representable — packed into a narrow range it underflows, spread over a wide one it overflows — and calling that a repeated node sends the reader after something that is not there:

Lagrange([0.0, 1e160, 2e160, 3e160])
# ArgumentError: the nodes of a Lagrange basis are distinct and finite, but the product
# of the differences from node 1 is -Inf in Float64, so the denominator it gives is not
# usable; rescale the nodes or widen the element type

Both of those used to construct silently, with every denominator 0 or Inf. The nodes are asked about before the product, so a repeated node is still reported as one even when the surviving differences overflow around it.

Cosmetic

• docs/Project.toml drops its [sources] block; the docs workflow already develops the package from the checkout, and [sources] needs Pkg ≥ 1.11 while this package supports Julia 1.10. 09eaa20 removed the root one for the same reason.
• The five @elapsed guards gain a comment saying they are liveness checks against a return to exponential evaluation, not benchmarks, and that the slack is deliberate.

Test plan

• Pkg.test() — 3519 pass (2903 before).
• julia --project=docs docs/make.jl — clean, all doctests pass, including the new element-type and node-rejection examples.
• Verified the precision fix changes what it should: the old Legendre{BigFloat} path is off by 1.3e-16 relative against a BigFloat reference, the new one agrees bitwise, at 0.1 as well as above a quarter.
• No inference or allocation regression from the promotion: the closures do not capture T as a field, and @inferred succeeds for all five bases and their derivatives.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.91%. Comparing base (9911a63) to head (f2a555d).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #25      +/-   ##
==========================================
+ Coverage   98.89%   98.91%   +0.02%     
==========================================
  Files           7        7              
  Lines         271      276       +5     
==========================================
+ Hits          268      273       +5     
  Misses          3        3              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This PR tightens numerical correctness by ensuring basis-function evaluation is performed at the appropriate arithmetic precision and by rejecting degenerate Lagrange node sets that lead to invalid denominators, with corresponding documentation, tests, and release metadata updates.

Changes:

• Promote evaluation inputs so basis evaluations run in the wider of the basis element type and argument type (aligning basis and derivative element types / precision).
• Strengthen Lagrange node validation by rejecting node sets whose difference products are zero or non-finite (e.g., 0.0 vs -0.0, NaN, Inf).
• Update tests/docs/changelog and bump version to 0.3.1.

Reviewed changes

Copilot reviewed 15 out of 16 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
test/legendre_tests.jl	Clarifies performance guard intent (liveness vs benchmark) for Legendre evaluation.
test/lagrange_tests.jl	Adds regression tests for degenerate / non-finite node rejection and signed-zero behavior.
test/chebyshev_tests.jl	Clarifies performance guard intent (liveness vs benchmark) for Chebyshev evaluation.
test/bernstein_tests.jl	Documents elapsed-time guard as a liveness check with deliberate slack.
test/basis_tests.jl	Adds assertions that evaluation/derivatives promote to the wider precision and that basis(b)[j](x) matches b[x,j].
src/legendre.jl	Promotes argument type used in Legendre recurrence evaluation within stored basis closures.
src/lagrange.jl	Replaces allunique check with product-of-differences validation (zero/non-finite) for node safety.
src/chebyshev.jl	Promotes argument type used in Chebyshev recurrence evaluation within stored basis closures.
src/bernstein.jl	Promotes argument type for Bernstein basis evaluation and derivative evaluation for type consistency.
src/basis.jl	Introduces _evaltype helper (promotion rule) and documents evaluation-precision behavior.
Project.toml	Bumps package version to 0.3.1.
docs/src/usage.md	Documents evaluation precision behavior with doctested examples.
docs/src/lagrange.md	Documents and demonstrates degenerate-node rejection (-0.0, NaN/Inf).
docs/src/chebyshev.md	Notes evaluation arithmetic behavior relative to element type and point type.
docs/Project.toml	Removes [sources] block to avoid requiring newer Pkg features for docs.
CHANGELOG.md	Adds 0.3.1 release notes describing precision promotion + Lagrange node validation changes.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.