Skip to content

Undocumented meaning of ranks and errors from quantics cross interpolation #97

@sdirnboeck

Description

@sdirnboeck

Summary

The function QuanticsTCI.quanticscrossinterpolate(...) returns extra values commonly bound as ranks and errors, but their meaning is not documented clearly enough on the Julia side.

The unclear point is not that these values exist, but what they are meant to represent semantically and how users are expected to interpret them.

Motivation

Users cannot tell whether ranks refers to final tensor-train bond dimensions, interpolation ranks, iteration history, or something else.
Users cannot tell whether errors contains per-iteration diagnostics, final convergence data, or the recommended public error quantity.
This makes it hard to write clear tutorials, package documentation, or user code that interprets these return values correctly.

Current evidence:
errors.last() is treated in the Rust tutorial code as a final interpolation error.
ranks.len() is treated in the Rust tutorial code as the number of interpolation steps.
In local experiments, ranks and errors look like short iteration histories rather than final TT bond dimensions.
The final QTT bond dimensions are obtained separately from the tensor-train representation, for example via TensorNetworks.linkdims(...).

Open questions:
A clear Julia-side explanation of what ranks contains.
A clear Julia-side explanation of what errors contains.
Whether these values are guaranteed to be per-iteration histories, and if so, which iteration or sweep they correspond to.
Whether errors.last() is the recommended public convergence quantity to compare against the requested tolerance.

Proposed approach (optional)

No response

Acceptance criteria

[ ] quanticscrossinterpolate docstring describes what ranks contains (iteration history, bond dimensions, or otherwise)
[ ] quanticscrossinterpolate docstring describes what errors contains and which entry is the recommended convergence quantity
[ ] Each return value's semantics are documented clearly enough that users can interpret them without reading Rust source code

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestproposedIssue opened, awaiting maintainer review

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions