Skip to content

Test the from_networkx int32 widening and correct its coverage claim - #618

Open
eriknw wants to merge 1 commit into
36-monoid-builtin-binaryop-guardfrom
37-networkx-int32-widen-pin
Open

Test the from_networkx int32 widening and correct its coverage claim#618
eriknw wants to merge 1 commit into
36-monoid-builtin-binaryop-guardfrom
37-networkx-int32-widen-pin

Conversation

@eriknw

@eriknw eriknw commented Aug 5, 2026

Copy link
Copy Markdown
Member

Stacked on #617. Overnight review of the late CI-stabilization commits found that the int32-to-int64 widening in from_networkx (added in #600's 18a5ad22) is reachable on every platform, not only win64 with numpy < 2 as its pragma: no cover claimed: np.int32 scalar edge weights infer an int32 array from the edge sequence anywhere.

The widening is deliberate and kept: from_coo widens int32 inferred from sequence input to int64 on every platform (values_to_numpy_buffer), and from_networkx builds its values from a Python sequence, so identical weights now produce the same dtype through either constructor:

import numpy as np, networkx as nx, graphblas as gb
G = nx.DiGraph()
G.add_weighted_edges_from([(0, 1, np.int32(2)), (1, 0, np.int32(3))])
gb.io.from_networkx(G).dtype                                # INT64 (was INT32 via scipy)
gb.Matrix.from_coo([0, 1], [1, 0], [np.int32(2), np.int32(3)]).dtype  # INT64, and always was

This PR drops the false pragma, restates the comment in terms of the real contract, and pins the behavior with tests: int32 weights widen and agree with from_coo, explicit dtype= is preserved exactly, and int16 stays INT16 through both constructors.

Release-note item: the from_networkx result dtype for int32-weighted graphs changes from INT32 to INT64 (2x value storage). If instead the old INT32 result is wanted, the widening condition is one line, but then from_networkx and from_coo disagree for identical weights.

@eriknw
eriknw force-pushed the 37-networkx-int32-widen-pin branch from ea9890e to e21ed55 Compare August 5, 2026 17:44
@eriknw
eriknw force-pushed the 37-networkx-int32-widen-pin branch from e21ed55 to b320caa Compare August 5, 2026 18:03
@eriknw
eriknw force-pushed the 37-networkx-int32-widen-pin branch 2 times, most recently from 62b13c7 to 9efbea8 Compare August 6, 2026 07:59
@eriknw
eriknw force-pushed the 37-networkx-int32-widen-pin branch from 9efbea8 to b747942 Compare August 6, 2026 15:39
@eriknw
eriknw force-pushed the 37-networkx-int32-widen-pin branch 2 times, most recently from 402b89a to ba98df4 Compare August 6, 2026 20:36
@eriknw
eriknw force-pushed the 37-networkx-int32-widen-pin branch from ba98df4 to a557f7e Compare August 6, 2026 20:41
@eriknw
eriknw force-pushed the 37-networkx-int32-widen-pin branch from a557f7e to 50ef9e9 Compare August 7, 2026 02:49
The widening added while stabilizing CI was marked "pragma: no cover
(win64 numpy < 2)", but the branch is reachable on every platform:
np.int32 scalar edge weights infer an int32 array from the edge sequence
anywhere, not only where python ints do. The pragma therefore hid live
code from coverage, and the comment implied the change was platform-local
when it is user-visible everywhere: int32-weighted graphs that previously
round-tripped through scipy as INT32 now come back INT64.

The widening itself is kept, deliberately. from_coo widens an int32 dtype
inferred from sequence input to int64 on every platform
(values_to_numpy_buffer), and from_networkx builds its values from a
Python sequence, so identical weights now produce the same dtype through
either constructor. Gating the widening to win64 instead would have
re-introduced a from_coo/from_networkx disagreement everywhere else.

Drop the pragma, restate the comment in terms of the real contract, and
pin the behavior: np.int32 weights widen to INT64 and agree with from_coo,
an explicit dtype= is preserved exactly, and np.int16 stays INT16 through
both constructors. Release-note item: the from_networkx result dtype for
int32-weighted graphs changes from INT32 to INT64.
@eriknw
eriknw force-pushed the 37-networkx-int32-widen-pin branch from 50ef9e9 to f5f70f7 Compare August 7, 2026 05:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant