Repository navigation
Conversation
eriknw
force-pushed
the
46-networkx-udt-dtype
branch
from
October 19, 2026 07:55
2a5ae73 to
54905a2
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 43-networkx-to-networkx-nodes #647 +/- ##
=================================================================
- Coverage 98.78% 98.69% -0.10%
=================================================================
Files 105 105
Lines 30393 30406 +13
Branches 3540 3542 +2
=================================================================
- Hits 30025 30008 -17
- Misses 243 258 +15
- Partials 125 140 +15 🚀 New features to boost your workflow:
|
eriknw
force-pushed
the
46-networkx-udt-dtype
branch
3 times, most recently
from
October 21, 2026 08:38
4511725 to
ba7bc56
Compare
eriknw
force-pushed
the
46-networkx-udt-dtype
branch
from
October 28, 2026 04:29
ba7bc56 to
55b90f0
Compare
eriknw
force-pushed
the
46-networkx-udt-dtype
branch
from
October 28, 2026 13:21
55b90f0 to
8d3488d
Compare
from_networkx passed dtype= to np.array over the sequence of weights. For a UDT, numpy read that sequence as the fields or elements of one value of the type, so the result depended on how many weights there were: FP64[2] with two edges, or INT64[3] with three, came back as an FP64 or INT64 matrix without a word, a record type raised "could not assign tuple of length 3 to structure with 2 fields", and other counts raised a numpy IndexError or a broadcast error. The scipy route this path replaced had the same fault (FP64[2] with one undirected edge gave FP64 there). A weight is one number, so a UDT has nothing to hold it as. Raise a ValueError naming the type before any conversion, and document dtype= as a built-in bool, int, float or complex type. The structural path no longer needs its own guard against non-numeric dtypes. The test covers a record type and two array types, with and without weight, for one to three edges; on the parent 4 of its 18 cases built a matrix, 4 raised IndexError and 10 raised ValueError with an unrelated message. Built-in dtypes are unaffected: 124 conversions compared with the parent are identical.
eriknw
force-pushed
the
46-networkx-udt-dtype
branch
from
October 29, 2026 02:01
8d3488d to
39ce7be
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With a UDT
dtype=, numpy read the weights as the fields or elements of oneUDT value, so the result depended on the number of weights: FP64[2] with two
edges, or INT64[3] with three, came back as an FP64 or INT64 matrix without any
error, and other counts raised unrelated numpy errors. It now raises
ValueError: dtype must be a built-in bool, int, float or complex type, not the UDT ..., and the docstring says so. The structural path's own UDT guard, added by the PRbelow, goes away: this check covers it. Built-in dtypes are unchanged.