Also, is there any plan to rollout Link Prediction (with neo4j) anytime soon ?

No-one is currently working on it, unfortunately.

Hi, unfortunately there isn't yet support available for link prediction directly like there is for node classification. I think there's two options:

• load all the data from Neo4j into memory as a StellarGraph: https://stellargraph.readthedocs.io/en/stable/demos/basics/loading-saving-neo4j.html (there isn't yet support for Neo4jStellarGraph -> StellarGraph either, unfortunately). This should be relatively easy, but would require having enough RAM to hold the whole graph.
• create a custom Neo4jGraphSAGELinkGenerator class. This would likely be more work. It could be done by adapting the non-Neo4j GraphSAGELinkGenerator class into a Neo4j one, similar to how the GraphSAGENodeGenerator class has been adapted into the Neo4jGraphSAGENodeGenerator class.

Does that help clarify things?

Thanks for reading the code closely. Could you say a little bit more about how you've found this discrepancy? Are you referring to the paper or do you have unexpected results?

Hi, thanks for getting in touch What version of StellarGraph are you using? You can find this on the command line with pip freeze, or in Python with: import stellargraph; print(stellargraph.__version__).

Thanks for getting in touch. Did you encounter any problems with your approach?

I suspect you've seen the demo for ClusterNodeGenerator + GCN? I believe a GAT demo would involve exactly the same code, with a change from cluster_gcn = GCN(...) to cluster_gat = GAT(...).

Hi, we're keen to help. Could you say a bit more about your problem? Are you trying to take a collection of several graphs and predict attribute(s) for each one? Have you seen the demos for graph classification?

That's not exactly what you're looking for, but fortunately classification and regression are very similar: typically one can change only the last output layer to turn a model from doing one of the tasks to the other. For example, the demos do binary classification and the last layer is:

predictions = Dense(units=1, activation="sigmoid")(x_out)

A single-dimensional regression might change this to not use any activation, like Dense(units=1)(x_out), or some other function that allows values outside 0 to 1. Similarly, for multi-dimensional output one can do the same things to replace the softmax activation normally used for multi-class classification.

How does that sound?

This theoretically ends up being faster because installing a docker image is much faster than installing the python packages again, maybe.

This theoretically ends up being faster because installing a docker image is much faster than installing the python packages again, maybe.

See: #772

I think this is an attempt to address the overhead noticed in #793/#724.

See: #772

I think this is an attempt to address the overhead noticed in #793/#724.

See: #1007

See: #1007

No worries! I'm going to reopen this issue, to remind us updating the notebook to work properly. (You do not need to do anything. 😄 )

Ah no, the node types (in a StellarGraph sense) of a and foo would be the same in that example. For instance, a knowledge graph might be built like:

edges = pd.DataFrame(
    [("a", "has_type", "foo"), ...], 
    columns=["source", "type", "target"]
)
StellarGraph(edges=edges, edge_type_column="type")

That is, both a and foo would be represented in the same way in the graph, even if they have very different meanings. That meaning would hopefully be captured by any algorithms used. For instance, if one was computing node embeddings with DistMult or ComplEx, the embeddings for a and foo would likely be different, because they have such different semantic meaning.

Does that help clarify?

Hi @AstralisRL, unfortunately there's no specific date as no-one is actively working on this. There's a draft pull request #1581, but I'm not personally able to push it to completion at the moment.

As you've noted HinSAGE is more flexible because it allows multiple node types, but you're correct that only one node type can be chosen as the head node type for a given (node classification) task. The (features of) nodes of other types are only used as input to the model by aggregating neighbourhoods of the nodes of the chosen head node type.

As such, it's generally not necessary or appropriate to switch to do the same change for HinSAGE. However, I could imagine some cases where the node type is better modeled as a one-hot encoded node feature than as separate types, with all nodes of the same type.

Does that make sense?

Ah, good catch!

Hi, thanks for getting in touch.

RGCN allows multiple edge types (that is, links or relationships), but only one node type (that is, entity, vertex). It is designed for knowledge graphs, which StellarGraph models as many nodes of a single type with all the actual information encoded in the edges. For instance, instead of node a having "type" foo, there might instead be a foo node, and an edge a -has_type-> foo.

Does that make sense?

Thanks for the pull request and thanks for waiting. This looks good, although I'm following up with the authors of this implementation to see if there's some historical reason for this approach.

Unfortunately no, strings and other sequences have to be converted into into numeric feature vectors before constructing the StellarGraph at the moment.

Ah, it looks like this notebook is out of date because it isn't being tested properly on CI (#818). The .random attribute was removed from UnsupervisedSampler. A better approach would be to do use the random module directly instead of unsupervised_samples.random, for example:

import random

negative_target_index = random.choices(
    node_data.index.tolist(), k=1
)

If one wants reproducibility, one can use random.seed to set the seed, e.g.:

import random
random.seed(0)

Do you mind giving me some idea of how to fit the graph with GraphSAGE? Thank you a lot!

Attri2Vec link prediction works by computing an embedding vector for each node (this is why it's using Attri2Vec Node Generator) and then passing pairs of those vectors through a classifier. GraphSAGE link prediction works with pairs of nodes from the start (using GraphSAGE Link Generator).

In your code, you've swapped Attri2VecNodeGenerator to GraphSAGELinkGenerator but used the same node_ids in the call to flow, which is probably just a sequence of individual node identifiers. You'll instead need to pass something like in_sample_edges to flow, where each element is a pair of node identifiers, representing the end points of each edge.

There's a demo of link prediction with GraphSAGE: https://stellargraph.readthedocs.io/en/stable/demos/link-prediction/graphsage-link-prediction.html

Hi, the GCN algorithm used for graph classification requires feature vectors associated with each node. For example, if the nodes represent bank account, the features might include the date it was opened and the balance.

You can load features using the node_features=... parameter to from_networkx, see https://stellargraph.readthedocs.io/en/stable/demos/basics/loading-networkx.html and https://stellargraph.readthedocs.io/en/stable/api.html#stellargraph.StellarGraph.from_networkx .

The output above has 768 features for edges between submission-authors and submissions and 768 features for edges between comment-authors and submissions, and these are the main features I am interested in using to predict my dependent variables

Ah, I think HinSAGE may not be appropriate for your task, as it doesn't currently support edge features (#1329). As such, I'd encourage either changing the graph so that the edges are replaced with nodes that contain the features, or use DGL unfortunately.

So I updated the num_samples to [5, 7, 11] without any problems, but setting layer_sizes to [29, 31, 37] threw an error as out dimensions must be divisible by 2. Setting layer_sizes to [14, 18, 22] then gave me Input to reshape is a tensor with 9216 values, but the requested shape has 13440, which is off by a factor of 1.458. So closer for sure!

Ah sorry, I forgot about the divisible by two requirement.

13440 = 2⁷ × 3 × 5 × 7, which I suspect is 32 (batch size) * 12 (feature size) * 5 (layer 1 sampling) * 7 (layer two sampling). This doesn't exactly explain why it's failing, though, nor does it match with your second comment about the adjustment (although I don't quite understand the exact adjustments you made there, did you move to [14, 32, 22] and [14, 18, 32], or [8, 32, 22] and [8, 18, 32]?).

In any case, 14 = 2 * 7 and 18 = 2 * 3 * 3 and those factors appear elsewhere, so a better choice may be [26, 34, 38] (= 2 × [13, 17, 19]) to again have more distinct prime factors.

I often work with graphs in the millions, but this is a project in which my labeled dataset is quite limited. I'm wondering if this has to do with some of my labels potentially being isolate nodes that have no neighbors? I figured HinSAGE would be robust to that and just not pass any data back to the isolate if it had no neighbors. Maybe I'm wrong, though.

It should be robust, and isolated nodes should have 0s passed back.

UPDATE: I opened my issue in a new one (#1802) given that my issue only has one generator and so it may be different (and may not be a bug).

Thanks, I replied there 👍

Hi @AlexMRuch, thanks for filing an issue with such detail, and for trying to reverse engineer the algorithm to work around the poor error messages (if you're curious about the details here, https://stellargraph.readthedocs.io/en/stable/hinsage.html provides a dense summary). The reshaping errors are certainly strange if you're consistently using the same graphs and generators throughout! Unfortunately, I can't really work out what's going on here at the moment. I have two ideas for trying to narrow this down:

• The output of the info method is often a helpful summary, e.g. print(hetero_graph_sampled.info())
• Using more prime factors may make the connections between the various sizes more obvious. For example, num_samples = [5, 7, 11] (note, not starting with 2 or 3, to avoid overlap with the features of size 12) and layer_sizes = [29, 31, 37]. The prime factors of the sizes in the error message will then link back to those numbers, and inform us at what stage things are happening. At the moment, almost everything is a power of two, so it's hard to be sure which power comes from where.

(Ignoring the reshaping errors, another thing to note is that SAGE-style algorithms such as HinSAGE typically work best with rich node feature vectors, and it looks like two of the nodes have no features and the other has only 2.)

Hi, thanks for asking some questions.

I am wondering if I can use StellarGraph to perform node attributes prediction instead of node classification?

Unless I misunderstand you, StellarGraph definitely can perform prediction of node attributes. In fact, node classification is an example of doing this: it is predicting a class attribute for nodes. If you want to perform regression, this can be achieved by changing the final layers of the model. For instance, a classification prediction model might have a final layer like:

predictions = layers.Dense(units=..., activation="softmax")(x_out) # multiple classes, from https://stellargraph.readthedocs.io/en/stable/demos/node-classification/gcn-node-classification.html#2.-Creating-the-GCN-layers

predictions = layers.Dense(units=1, activation="sigmoid")(x_out) # binary classification

For regression, one can simply change the activation to avoid rescaling/constraining the output value. For instance:

predictions = layers.Dense(units=1)(x_out)

Does that help answer that question?

And also, is it possible that X (node attributes matrix) is 3-D instead of 2-D? For example: we want to use word embedding as the node attributes instead of bag of words representation. If using bag of words, X is [num of nodes, num of words in the vocab]. If using word embedding, X will be similar to sequence models input, which is [num of nodes, max sequence length, num of word embedding dimension].

It's definitely possible to have 3D node attributes, however this is only useful for the GCN-LSTM model for multivariate time-series prediction. If you're not doing time-series prediction, then you'll need to aggregate the features for each node in X to make it 2D. The simplest way to do this is to just concatenate them all into one long vector for each node. That is, make X be 2D with shape [num of nodes, max sequence length * num of word embedding dimension]. This is possible in NumPy with something like X.reshape((number_of_nodes, -1)).

You can also do other aggregations, but concatenating will preserve all of the information.

What do you think?

Hi, this sounds like an inductive node classification task, where you've got labelled examples across multiple graphs, and then want to train on a new graph. The GraphSAGE and Cluster-GCN algorithms should support this, by combining all of the labelled graphs for training/validation/evaluation into one large StellarGraph (as you've noted with #1359), and then training on that. Prediction on new graphs should involve creating a StellarGraph for each new graph and running the trained model over it.

The relevant demos for this are:

• https://stellargraph.readthedocs.io/en/stable/demos/node-classification/cluster-gcn-node-classification.html
• https://stellargraph.readthedocs.io/en/stable/demos/node-classification/graphsage-inductive-node-classification.html

The GCN-LSTM time series model is designed for a single graph where the node features vary over time, and allows for forecasting future values of those node features. This doesn't quite sound like what you've got here, unless I'm misunderstanding your description.

Does that help?

Hi, thanks for asking a question.

It sounds like there's two things here:

• The GML format might be most easily loaded via NetworkX: https://stellargraph.readthedocs.io/en/stable/demos/basics/loading-networkx.html
• Loading data for graph classification requires loading each graph into a StellarGraph independently; based on what you've said, the basic structure might be something like:

  import glob
  import networkx as nx
  import stellargraph as sg
  
  files = glob.glob("*.gml") # all the .gml files
  graphs = [
      StellarGraph.from_networkx(
          nx.read_gml(name),
          node_features="feature_attribute_name"
      )
      for name in files
  ]
  

  (This is just an example, and will likely need changes to how the features are loaded depending on how they're stored, and so on.) The graphs list can then be used in the PaddedGraphGenerator generator to perform graph classification.

Does that help?

Hi, thanks for asking a question.

I think this can be handled in two ways, depend on what sort of data you have available:

• unsupervised embedding to compute a vector for each node, and then doing standard vector comparisons (for example, L2 or cosine distance between them). This will likely be the best choice if you just have a graph without any ground-truth labels for the similarity of nodes. There's numerous demos of this at: https://stellargraph.readthedocs.io/en/stable/demos/embeddings/index.html
• supervised link prediction, where the task is predicting the similarity of the two nodes at either end of each link (for example, predicting for similar nodes A and B might yield a value of 0.9, while for dissimilar nodes A and C might yield a value of 0.1). This will likely be the best choice if you do have ground-truth labels for the similarity of nodes. There's numerous demos of this at: https://stellargraph.readthedocs.io/en/stable/demos/link-prediction/index.html

(This are actually fairly similar, and are two different ways of phrasing a similar problem. For example, the demo of link prediction with Node2Vec first does unsupervised embedding to compute vectors, and then trains a classifier on pairs of the resulting vectors to do the final link prediction element.)

I hope that helps!

A link prediction task is often used to predict link existence. Many of the other examples in https://stellargraph.readthedocs.io/en/stable/demos/link-prediction/index.html do this.

Instead of adding all of the didn't watch edges, the typical way to do this is to just select some for training and evaluation but keep them out of the graph. This can be done via random negative sampling.

https://web.archive.org/web/20200715071324/https://community.stellargraph.io/t/hinsage-link-prediction-and-imbalanced-classification/136 contains a lot of discussion about HinSAGE link prediction that may be relevant to you. (My comments with train_test_split in them may be the most useful.)

Can i "signal" HinSAGE the types of links to predict?

HinSAGE link prediction requires specifying the "head node types", which are the node types of the source and destination, which is "user" and "movie" in this case. This means that it'll only do predictions for edges between those types, and so only use the "user"/"user" edges for informing the model.

Does this help?

Hm, how are you building the union graph? And could you be more specific about what you mean by large memory usage?

Our benchmarking suggests that a graph with > 200k nodes and almost 12m edges can be constructed in seconds (on our machines), using less than 2GB of memory (see the two "reddit" rows in https://stellargraph.readthedocs.io/en/stable/demos/zzz-internal-developers/graph-resource-usage.html#Pretty-results ).

I think the best way to pass each graph into Cluster-GCN would be writing a custom subclass of ClusterNodeGenerator that overrides with the appropriate behaviour. Unfortunately I do not have the time to help much with this right now.

Describe the bug

Good: https://github.com/stellargraph/stellargraph/actions/runs/219162133 Bad: https://github.com/stellargraph/stellargraph/actions/runs/220206436

Diff between dependency versions:

@@ -62,3 +62,3 @@
 nest-asyncio==1.4.0
-networkx==2.4
+networkx==2.5
 notebook==6.1.3

To Reproduce

Steps to reproduce the behavior:

1. Install networkx==2.5 and run the interpretability notebooks

Observed behavior

---------------------------------------------------------------------------
Exception encountered at "In [33]":
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-33-204a1f97f5ae> in <module>
     44     vmin=np.min(colors) - 0.5,
     45     vmax=np.max(colors) + 0.5,
---> 46     node_shape="o",
     47 )
     48 nc = nx.draw_networkx_nodes(

TypeError: draw_networkx_nodes() got an unexpected keyword argument 'with_labels'

Expected behavior

The notebooks should run.

Environment

Operating system: CI

Python version: 3.6

Package versions: StellarGraph ec132647e5cf43ff683e3f2e72e18ac6daa98202

Additional context

N/A

I think this should be possible. It could even be done outside the library and passed into the HinSAGE class via the aggregator argument. One way to do this would be to copy the MeanHinAggregator code and make appropriate changes (this may be quite fiddly, though):

https://github.com/stellargraph/stellargraph/blob/ec132647e5cf43ff683e3f2e72e18ac6daa98202/stellargraph/layer/hinsage.py#L41-L216

Thanks for filing an issue. I'm not in a position to dig into the details right now, but we really appreciate that you've done so. If you feel like it, we'd be more than happy to merge a pull request with a fix, otherwise, I will try to look at this in future, but i can't guarantee when!

Hi, thanks for filing an issue, but I'm a little confused! Are you suggesting the demo could be changed to make it easier to copy paste the code to run DGI with HinSAGE?

As you note, the correct thing to do is to only pass in nodes of the type head_node_type. This can be done with, for instance, G.nodes(node_type="bar") instead of G.nodes().

2020.0.0 has been released (https://github.com/technige/py2neo/releases/tag/2020.0.0), so this is now failing on develop.

This is a test for #1784, which sees some issues that may be connected to scipy==1.4.1.

This didn't seem to be the cause of #1784, closing.

Describe the bug

Hi! Thank you for this great library. I'm trying to install Stellargraph on Ubuntu 18.04. However, after I successfully installed Stellargraph via conda (follow this instruction), when I try to import Stellargraph, this problem happened:

ImportError: cannot import name 'rng_integers' from 'scipy._lib._util' (/home/zihan/anaconda3/envs/TF2/lib/python3.7/site-packages/scipy/_lib/_util.py)

To avoid the possible problem coming from scipy, I reinstalled it, and made sure it successfully installed in this environment:

conda list -n TF2

scipy                     1.4.1                    pypi_0    pypi
stellargraph              1.2.1                      py_0    stellargraph
tensorflow                2.2.0           mkl_py37h6e9ce2d_0  

Hence I'm quite confused with why this problem happens. Could you please help me with this issue? Thank you a lot in advance!

Environment

Operating system: Ubuntu 18.04

Python version: 3.7.7

Package versions: stellargraph==1.2.1, tensorflow==2.2.0

More detailed error description:

---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-11-855dad28d1e4> in <module>
----> 1 import stellargraph as sg
      2 #from stellargraph.data import EdgeSplitter
      3 #from stellargraph.mapper import FullBatchLinkGenerator
      4 #from stellargraph.layer import GCN, LinkEmbedding
      5 # import scipy

~/anaconda3/envs/TF2/lib/python3.7/site-packages/stellargraph/__init__.py in <module>
     37 
     38 # Import modules
---> 39 from stellargraph import (
     40     data,
     41     calibration,

~/anaconda3/envs/TF2/lib/python3.7/site-packages/stellargraph/data/__init__.py in <module>
     21 
     22 # Expose the stellargraph.data classes:
---> 23 from .explorer import *
     24 from .edge_splitter import *
     25 from .node_splitter import *

~/anaconda3/envs/TF2/lib/python3.7/site-packages/stellargraph/data/explorer.py in <module>
     29 import warnings
     30 from collections import defaultdict, deque
---> 31 from scipy import stats
     32 from scipy.special import softmax
     33 

~/anaconda3/envs/TF2/lib/python3.7/site-packages/scipy/stats/__init__.py in <module>
    386 
    387 """
--> 388 from .stats import *
    389 from .distributions import *
    390 from .morestats import *

~/anaconda3/envs/TF2/lib/python3.7/site-packages/scipy/stats/stats.py in <module>
    174 from scipy.spatial.distance import cdist
    175 from scipy.ndimage import measurements
--> 176 from scipy._lib._util import (_lazywhere, check_random_state, MapWrapper,
    177                               rng_integers)
    178 import scipy.special as special

ImportError: cannot import name 'rng_integers' from 'scipy._lib._util' (/home/zihan/anaconda3/envs/TF2/lib/python3.7/site-packages/scipy/_lib/_util.py)

That's great that it now works. Thanks for filing an issue, and good luck! I'll close this issue now, but let us know if there's anything more.

It looks like the Ubuntu pip (on all Python versions) and Conda (Python 3.8) testing passed, using Scipy 1.4.1. For example, line 748 of https://github.com/stellargraph/stellargraph/pull/1785/checks?check_run_id=964620995 is scipy: 1.4.1-py37h0b6359f_0. (Windows failed, but I think that was due to a different problem.)

As an additional check, I've switched Conda testing to use Python 3.7 in that PR. That also passed.

Thus, my remaining thought is that somehow scipy is failing to install properly in your environment. Could you try just importing it in without going via StellarGraph? For example: python -c 'from scipy import stats', using the appropriate python command/binary for your Conda Python environment.

That's very strange! It looks like a scipy submodule is failing to import another scipy internal submodule. This suggests to me that the problem isn't directly related to StellarGraph, but is instead a corrupted installation of scipy. StellarGraph runs successfully on my macOS machine with scipy 1.4.1 (installed with pip), and on Ubuntu CI with scipy 1.5.2 (pip) and scipy 1.5.0 (conda).

To help narrow down potential issues here, I've opened https://github.com/stellargraph/stellargraph/pull/1785, which pins the version of scipy to 1.4.1 exactly, and thus will run through the full test suite and all of the demo notebooks with that version. Once CI has finished on it, hopefully we'll have more insight into the issue.

This is a test for #1784, which sees some issues that may be connected to scipy==1.4.1.

There's several sources of a randomness in a deep learning model, with train/test split being just one. For instance, the initial values of the trainable parameters. Most sources of randomness can be controlled via tensorflow.set_seed and stellargraph.random.set_seed. They should allow making the model outputs far more reproducible.

A choropleth trace supports specifying locations as high-level string names/IDs, via the locations and locationmode keys. A choroplethmapbox trace seems to not support this, and thus requires specifying any geometries as a manual GeoJSON file. It would be nice if choroplethmapbox supported the same automatic "inference" of appropriate geometries too.

Related issues:

• #3988 mentions the possibility of this, but it seems there's no progress:

  locationmode. The current behavior would correspond to locationmode: 'geojson-id'. Some users might expect to identify GeoJSON features using their properties.name (this would correspond to e.g. locationmode: 'geojson-prop-name'. Moreover, we could also support the locationmode values found in geo traces: 'ISO-3', 'USA-states', 'country names'

• #4154 was, I think, about generalising the GeoJSON support in choroplethmapbox, but not adding the no-GeoJSON mode as here

• #4267 was the opposite, I think: adding support for GeoJSON to choropleth

Thanks for the review.

Status: this depends on #1779 so that the test of saving and loading the (sparse) model can work (with TF 2.3), and that seems to be waiting on TF 2.3 being available in conda (https://github.com/stellargraph/stellargraph/pull/1779#issuecomment-664747491).

This is blocked by TF 2.3.0 being available on Conda.

This replaces the TestGATsparse function with a class, that has the correct subclass behaviour to pick up the tests from the Test_GAT subclass. This requires adjusting some tests, but otherwise the code seems to work.

Fixes: #1780

Describe the bug

GAT tries to uise subclassing to share tests between dense and sparse models, but accidentally defines a function instead of a subclass:

https://github.com/stellargraph/stellargraph/blob/ec132647e5cf43ff683e3f2e72e18ac6daa98202/tests/layer/test_graph_attention.py#L625-L627

To Reproduce

1. Look at test_graph_attention.py

Observed behavior

The sparse tests define a new function that is ignored.

Expected behavior

The sparse tests should declare a subclass, like class TestGATsparse(Test_GAT):

Environment

Operating system: all

Python version: all

Package versions: StellarGraph ec132647e5cf43ff683e3f2e72e18ac6daa98202

Additional context

N/A

TensorFlow 2.3.0 was released over the last day. This release includes the fix for https://github.com/tensorflow/tensorflow/issues/38465 (which we filed a duplicate of at https://github.com/tensorflow/tensorflow/issues/40373) which is the underlying issue behind #1251.

As such, we can remove the xfail markings from tests involving the saving of full-batch models like APPNP, GCN and RGCN.

I reran the https://colab.research.google.com/gist/huonw/4ac8796f598bc742b476fd8e36a1f866/gcn-link-prediction.ipynb notebook and it seemed to work (other than the change from model.compiled_metrics._loss to model.compiled_metrics._loss_container). The cell that tests various ways to specify binary crossentropy now has output:

'bce' binary_accuracy
'binary_crossentropy' binary_accuracy
<function binary_crossentropy at 0x7f94729b1950> binary_accuracy
<tensorflow.python.keras.losses.BinaryCrossentropy object at 0x7f94629c13c8> binary_accuracy
<function binary_crossentropy at 0x7f94729b1950> binary_accuracy

And the accuracy and validation accuracy metrics now look correct too 👍

Ah, good trick. I applied it on Colab: https://colab.research.google.com/gist/huonw/4ac8796f598bc742b476fd8e36a1f866/gcn-link-prediction.ipynb . It didn't work.

Discussion (numbers [n] refer to the cell execution count on the rendered form):

1. I applied the patch with curl ... | patch [2]
2. I confirmed the patch was applied with grep [3]
3. I ran the example from #41361 with many ways to specify the loss [4]. For example, "bce" and referring to the keras.losses.binary_crossentropy function directly (the example was extended to include printing the loss value used). Output here for convenience:

   'bce' binary_accuracy
   'binary_crossentropy' categorical_accuracy
   <function binary_crossentropy at 0x7ff1b8db0950> categorical_accuracy
   <tensorflow.python.keras.losses.BinaryCrossentropy object at 0x7ff1a8dc1208> binary_accuracy
   <function binary_crossentropy at 0x7ff1b8db0950> categorical_accuracy
   

   Note that only loss="bce" and loss=tf.keras.losses.BinaryCrossentropy() work, loss="binary_crossentropy" and the two forms of loss=tf.keras.losses.binary_crossentropy do not.
4. I ran rest of the notebook from https://github.com/stellargraph/stellargraph/issues/1766 without changes to build and compile a Keras model [5]-[19] (using loss=tf.keras.losses.binary_crossentropy, as in the original)
5. I inspected the Keras model to confirm that it's using the MetricsContainer class with the loss parameter to its constructor and the _loss attribute [20], [21]
6. I evaluated and trained the model (also without changes from the original notebook), observing that the accuracy was the incorrect 0 value [22]-[25]

Given my other comment above, maybe this should be using the compiled/normalized self.compiled_loss value(s) rather than the generic loss one that can be in 'any' form? I don't know what a LossesContainer contains in particular, but I'm comparing to the TF 2.1 code, where there didn't need to be a special case for string forms like "bce":

https://github.com/tensorflow/tensorflow/blob/3ffdb91f122f556a74a6e1efd2469bfe1063cb5c/tensorflow/python/keras/engine/training_utils.py#L1114-L1121

Great, thanks! I'd be happy to say that this PR resolves the issue from our side then.

Unfortunately, I am not in a position to build TensorFlow from source, so unless there's an easy way for me to install a package from CI, I can't confirm on our real code myself. However, this issue was flagged in public code: in particular, https://github.com/stellargraph/stellargraph/issues/1766 found Jupyter notebook where the model reported accuracy metrics of 0 with TF 2.2 (but not TF 2.1). This can be run locally using something like:

1. Download the notebook from https://stellargraph.readthedocs.io/en/v1.2.1/demos/link-prediction/gcn-link-prediction.ipynb
2. Install necessary libraries pip install stellargraph[demos]==1.2.1
3. Run the notebook and see whether the fit call reports an accuracy of constant zero (bad) or decreasing non-zero (good)

This is a bit fiddly, so I'm not expecting you to do so. 😄

You're entirely correct that the text and code are inconsistent here.

It looks like this was correct and consistent in the original form of the notebook (added in 7d14eb28ab3254aae2c8c64e70a9fc2357bb83af) https://github.com/stellargraph/stellargraph/blob/7d14eb28ab3254aae2c8c64e70a9fc2357bb83af/demos/node-classification/stellargraph-node2vec-node-classification.ipynb but was changed in https://github.com/stellargraph/stellargraph/commit/7a6742213e0e8765bc6b712f9783a13a80199abb with apparently no explanation.

There's a few options:

1. update the text to match the code (that is, "We use 10% of the data for training and the remaining 90% for testing as a hold out test set"). For example: https://stellargraph.readthedocs.io/en/stable/demos/node-classification/keras-node2vec-node-classification.html#Data-Splitting does 10-90 'properly'
2. update the code to match the text (that is, what you state). For example: https://stellargraph.readthedocs.io/en/stable/demos/node-classification/node2vec-weighted-node-classification.html#Comparing-the-accuracy-of-node-classification-for-weighted-(weight-==1)-and-unweighted-random-walks.
3. switch both to something completely different. For example: https://stellargraph.readthedocs.io/en/stable/demos/node-classification/attri2vec-node-classification.html#Data-Splitting does a 20-80 split

I'm inclined towards 2; potentially including updating those other examples that do splits other than 75-25 because I suspect at least the notebook from one steals the 10-90 split from the new weird notebook.

I'm happy to open a PR for this sometime later today or tomorrow, unless someone else gets to it first.

Looks like it, but there is a reduced test case in #41361 that I cut down from our real code and so is the "true" measure of success. Does that test case match the behaviour of 2.1 with this PR?