[ENH] recover renumbering from from_cudf_edgelist

[lmeyerov]

Describe the solution you'd like

from_cudf_edgelist needs a way to recover the mapping when renumber=True, such as part of the return or as an attribute of the graph. Or, if already doable, the docs for from_cudf_edgelist and cugraph need to clarify.

Additional context

add_edge_list, which returns the mapping, throws a near-term deprecation warning in favor of from_cudf_edgelist, yet without a way to recover mappings, it is not a usable replacement when renumber=True. (from_cudf_edgelist does not appear to preserve edge order, so cannot infer, either.)

This is in 0.13, so may already be too late for to 0.14...

[afender]

Hi, thanks for your input!

from_cudf_edgelist needs a way to recover the mapping when renumber=True

Typically, after 0.13, users do not need to be aware of renumbering or maps. cuGraph takes care of all the mapping so that features accept and return results with users' identifiers. Our vision is that renumbered representations are internal matters that should not need to be explicitly exposed by default. If you think you found a bug, please let us know what workflow is causing issues or what analytics caused ID mismatches.

if already doable [...]

As an attribute of the internal structure, advanced users can still access it : graph.edgelist.renumber_map

without a way to recover mappings, it is not a usable replacement when renumber=True

One may call the separate renumbering function prior to calling from_cudf_edgelist while setting auto renumbering to False there. It seems to me that this pipeline is equivalent to pre-0.12 usage.

[lmeyerov]

Thanks, +1 for separating user-level IDs from internal for the typical case :)

Will keep an eye open if we hit this again with 0.14+ APIs!