w class specific deprecations

[sjsrey]

This is a subset of #484 to track a subset of changes

W

• [x] to/from_file should stay
• [x] to_wsp() stays, build from_wsp() #496
• [x] to/from_networkx() stays
• [x] make _build_sparse() public as to_sparse, add a from_sparse, and keep .sparse #497
• [x] keep n_components, all the math/stats on the graph
• [ ] rename islands to isolates to match networkx
• [ ] deprecate id2i, from_shapefile, __set/get_id_order, id_order, id_order set, neighbor_offsets,
• [ ] turn get/set_transform() and transform itself into a single transform method that returns a copy() (at new geograph module)
• [ ] re-write iter to remove _id_order and instead just use dictionary iteration
• [x] keep remap_ids
• [x] keep asymmetry
• [ ] keep symmetrize, but fix the docstring
• [ ] deprecate full, move to to/from_dense and a .dense attribute
• [ ] deprecate set_shapefile()
• [ ] merge plot with splot's weights plotter... keep W.plot()'s flexibility, but adapt to splot's performance

[ljwolf]

For now, we need to keep the id_order call in to_adjlist(), until we have a clear association between the "name" of an observation and its location in sparse. This is why I think it may be better to try to build a new W class from the ground/WSP up.

Take, for example, the following tricky case:

>>> from libpysal.weights import lat2W
>>> w = lat2W(4,4, id_type="string")

The order of observations in w.neighbors.keys() is totally up to the contiguity builder now, as is order of links in w.neighbors.values(). There is no sorting, which would happen in previous versions of Python:

>>> w.neighbors
{'id0': ['id4', 'id1'],
 'id4': ['id0', 'id8', 'id5'],
 'id1': ['id0', 'id5', 'id2'],
 'id5': ['id1', 'id4', 'id9', 'id6'],
 'id2': ['id1', 'id6', 'id3'],
 'id6': ['id2', 'id5', 'id10', 'id7'],
 'id3': ['id2', 'id7'],
 'id7': ['id3', 'id6', 'id11'],
 'id8': ['id4', 'id12', 'id9'],
 'id9': ['id5', 'id8', 'id13', 'id10'],
 'id10': ['id6', 'id9', 'id14', 'id11'],
 'id11': ['id7', 'id10', 'id15'],
 'id12': ['id8', 'id13'],
 'id13': ['id9', 'id12', 'id14'],
 'id14': ['id10', 'id13', 'id15'],
 'id15': ['id11', 'id14']}

Our w.id_order, however, still describes the sorted ids:

>>> w.id_order
['id0', 'id1', 'id2', 'id3', 'id4', 'id5', 'id6', 'id7', 
 'id8', 'id9', 'id10', 'id11', 'id12', 'id13', 'id14', 'id15']

So, w.neighbors.keys() may not be equal to w.id_order when we sort w.id_order. We build .sparse from id2i, which I think corresponds to id_order not .neighbors.keys().

In this event, what does the second row of w.sparse look like? Does it correspond to the observation named id4? or to id1?

>>> w.sparse[1].nonzero()
(array([0, 0, 0], dtype=int32), array([0, 2, 5], dtype=int32))

It corresponds to id1, not id4.

[knaaptime]

if we decide to move forward with #513, I think it also incorporates most of the items on this list

[ljwolf]

@martinfleis and I had a chat about this today, too, and think that #513 is the right way to go. Are there blockers or anything we can do to push on that?