Make NS coefficients parameter 2D in Python API

[vcherepanov-nv]

Description

Make passing coefficient to Newton-Schulz more consistent with the one in EmergingOptimizers

Fixes # (issue)

Type of change

• Documentation change (change only to the documentation, either a fix or a new content)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Infra/Build change
• Code refactoring

Changes

• Pass NS coefficients as a list of tuples instead of a flat list

Checklist:

• I have read and followed the contributing guidelines
• The functionality is complete
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[greptile-apps]

Greptile Summary

This PR refactors the Newton-Schulz coefficient API to use a list of (a, b, c) 3-tuples instead of a flat list[float], making it consistent with the EmergingOptimizers interface. The C++ backend still receives a flat list — flattening is now done inside newton_schulz() after per-tuple validation.

• Breaking change not flagged: coefficients in newton_schulz() changed from Optional[List[float]] to Optional[Sequence[tuple[float, float, float]]]. Callers passing a flat list will get a runtime ValueError; the PR description leaves the "Breaking change" checkbox unchecked.

Confidence Score: 4/5

Safe to merge once the breaking-change nature is acknowledged and communicated to users.

The refactoring logic is internally consistent and correct — the C++ backend path is unchanged. The single P1 concern is that the public coefficients parameter type is changed in a backwards-incompatible way without a deprecation notice or acknowledgement in the PR checklist.

transformer_engine/pytorch/newton_schulz.py — the newton_schulz() signature is the public API surface that breaks existing callers.

Important Files Changed

Filename	Overview
transformer_engine/pytorch/newton_schulz.py	Refactors coefficient representation from a flat List[float] to list[CoeffT] (list of 3-tuples); flattening is now deferred to just before the C++ call. Logic is correct but the change is a breaking API modification for callers passing custom flat coefficient lists.
tests/pytorch/distributed/run_newton_schulz.py	Updates newton_schulz_reference signature and loop unpacking to match the new 2D tuple coefficient format; clean and consistent with the main module change.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Caller: newton_schulz(x, ctx, num_iterations, coefficients)"]
    B{coefficients is None?}
    C["get_coefficients(num_iterations) - returns list of CoeffT tuples"]
    D{len == num_iterations?}
    E["ValueError: wrong length"]
    F["Flatten: validate each tuple len==3, extend flat_coefficients"]
    G["tex.newton_schulz - C++ backend receives flat list, unchanged"]

    A --> B
    B -- Yes --> C --> D
    B -- No --> D
    D -- No --> E
    D -- Yes --> F --> G

Loading

_{Reviews (1): Last reviewed commit: "Make NS coefficients parameter 2D in Pyt..." | Re-trigger Greptile}

[ptrendx]

/te-ci pytorch L1