Add b1.size() and b2.size() alongside network.size().

[krivit]

nw %n% "bipartite" and network.size(nw) - nw %n% "bipartite" are very common patterns, and having functions that extract them as a part of the API would make the client code more readable, without introducing a nontrivial maintenance burden.

One question is what these functions should do if nw is not bipartite. Here are the options as I see them:

1. Error
2. NULL or numeric(0)
3. FALSE or 0
4. network.size(nw)
5. Wrap the above, i.e., b1.size(nw) == 0, b2.size(nw) == network.size(nw).
6. User-selected (i.e., unipartite = c("Error", "NULL", "FALSE", "all"), so picked because they have distinct first letters).

Option 1 will force the clients to program defensively and avoid unexpected behaviour. Option 2 will do so to a slightly lesser extent (i.e., if the code is such that it errs on NULL) but will enable the pattern along the lines of b1.size(nw) %||% network.size(nw) or, equivalently, NVL(b1.size(nw), network.size(nw)). Option 3 will also force some degree of defensiveness (if the code errs on 0) and will enable bipartedness and bipartition size to be queried in the same statement. Option 4 is the most likely to enable subtle bugs, but it also has the property that matrix(0, b1.size(nw), b2.size(nw)) will be the sociomatrix of nw regardless of whether or not it's bipartite. Option 5 has the property that b1.size(nw) + b2.size(nw) == network.size(nw).

@CarterButts , @mbojan , @sgoodreau , @martinamorris , @drh20drh20 , @handcock , thoughts?

[mbojan]

I like (1) by far the most.

[drh20drh20]

I'm for encouraging defensive programming but not sure forcing it by throwing an error is necessary, so I lean a bit toward Option 2. But I have no strong objection to Option 1, as long as we're careful in the documentation to explain how to avoid the error. Options 3 through 5 seem slightly too prone to hard-to-diagnose coding errors.

[sgoodreau]

Defintely either 1 or 2. I lean towards 1 but not strongly.

[krivit]

For reference, Option 3 is, in some sense, the status quo ante, since because nw %n% "bipartite" is almost always FALSE for a unipartite network.

[mbojan]

To complement, some reasoning behind (1) I had:

• nw %n% a queries the attributes (returns NULL if absent). bipartite is FALSE for unipartite. b1.size(), as an intention, is not querying an attribute.
• The intention of calling b1.size() is to get partition size of a graph that the user already knows/assumes is bipartite. If it is not bipartite, it's most likely a mistake. It's like asking a wrong question.
• Isn't it easier to work with functions that always return values of the same mode, here numeric, instead of sometimes numeric, sometimes logical?
• We have is.bipartite() to assert bipartitedness. Having b1.size() to return something in order to be able to make a similar assertion does not seem sensible. I think (1) leads to clearer a code. Or is there a case for that?

Not that anything else than (1) is a deal-breaker...

[drh20drh20]

No strong opinion on my end either, and @mbojan 's comments are useful. Playing devil's advocate, I'm nervous asserting anything about users' intentions. If the user intends to use b1.size both to learn whether the network is bipartite and, if so, find the value, so be it.

OTOH, one thing I hadn't thought of previously is that ergm already throws an error when a user uses a bipartite term with a non-bipartite network, so in this sense option (1) would be internally consistent.

Not that anything else than (1) is a deal-breaker...

Nor is (1) a deal-breaker as far as I'm concerned! :)

[CarterButts]

No sure why the response I sent yesterday didn't come through, but anyway:

Hmm. CRAN has frowned for years on naming functions x.y when x is not a method and y is not a class. We have a lot of grandfathered functions like that, because no one cared when we first developed the packages, but b1.size() and b2.size() seem likely to attract criticism while also being unaesthetic. (I never did like the "b1" and "b2" nomenclature, because it's not very clear what "b" is. In this case, I think it's also pretty hard to guess what b1.size means, unless you happen to know how ERGM has been naming related terms. In the literature it is, for instance, more common to talk of "row vertices" and "column vertices.") Further, making different functions for getting the size of the two vertex classes seems a bit inelegant.

It's almost too bad that NROW/nrow and NCOL/ncol are not generic, because one could then overload them for network objects, using the "row vertex/column vertex" convention. That would provide a "two function solution," while still following established R (and graph theoretic!) traditions. I suppose one could make functions nrowv and ncolv or something, though those names are ugly. (Is nvrow/nvcol better? Not sure.) On the bright side, they'd at least echo R practice, avoid the "dot" issue, and would be very compact.

Another option would be to add arguments to network.size, allowing one to specify that one wants the row or column sets. network.size does have an ellipsis, so it can be extended without breaking existing code. It would be cumbersome to use, but readable.

Anyway, if the network is not bipartite, the question of how many row/column vertices there are is not naturally defined. If all vertices were row (or column) vertices, then properly the graph should be forced to be empty (because none are allowed to talk to each other). But it makes no sense to return 0 for both, since vertices exist. One can abuse concepts a bit and say that, in this case, every vertex plays a role as a row vertex and as a column vertex (if you like, an "SVD view"), and then in this case there are ties because the row-version of a vertex is tied to its neighbors' column copies. In that case you would return the network size for both queries.

The above suggests that there's no good answer, so throwing an error is an option. We could also look for precedent. Going back to nrow, if I use nrow(z) where z doesn't have rows, it returns NULL (sans error). So if we had nvrow and nvcol, and we wanted them to act in like fashion, returning NULL when passed a non-bipartite graph would be a parallelism. I can't think of any case where either would break anything, since (1) no existing code uses this functionality, and (2) if you query explicitly bipartite things on a non-bipartite graph, that's your problem.

So, TL;DR:

(1) I don't think the proposed function names are a good idea, but one could either import the functionality into e.g. network.size() or use nomenclature that emulates existing functions; (2) since there's no very logical response to this query on a one-mode network, I lean towards returning NULL or an error in that case; (3) all such changes must be implemented carefully, with a view to being future proof (because you cannot change low-level code without consequences!), but it would otherwise be a new add that wouldn't break existing code.

[krivit]

It's almost too bad that NROW/nrow and NCOL/ncol are not generic, because one could then overload them for network objects, using the "row vertex/column vertex" convention. That would provide a "two function solution," while still following established R (and graph theoretic!) traditions. I suppose one could make functions nrowv and ncolv or something, though those names are ugly. (Is nvrow/nvcol better? Not sure.) On the bright side, they'd at least echo R practice, avoid the "dot" issue, and would be very compact.

dim() is the generic, and NROW/nrow and NCOL/ncol simply call it and extract the corresponding dimension.

We could easily implement a dim() method for network objects, but that would suggest that we should take Option 4 for unipartite networks, since we are now returning the dimension of the hypothetical sociomatrix.

[mbojan]

Reference to / inspiration from the adjacency matrix sounds tempting. For me though nrow() and ncol() seem too opinionated. Alas, how do we know if b1 are rows and b2 are columns or the other way around? I imagine checking the documentation too often.

I'm not a great fan of the b[12] convention, but it sunk to the packages already (ergm terms and so on). Looking forward, it would be nice to go into a direction that will be easier to generalize towards multimodal / k-partite graphs maybe? partition_size(net, k) or something like that?

[krivit]

The opinionation in question is expressed in two contradictory ways:

1. as.matrix(nw, matrix.type = "adjacency"), returns a nw%v%"bipartite" by network.size(nw) - nw%v%"bipartite" matrix.
2. nw[i,j] expects j > nw%v%"bipartite".

So, we already break the symmetry between b1 and b2. However, the fact that nw[i,j] != as.matrix(nw, matrix.type = "adjacency")[i,j] does raise the question of how nrow() and ncol() should be defined. In terms of usefulness, the first definition is probably greater, since we already have network.size(nw) as the accessor for the total dimension.