Problem with the output of Uniform Spanning Tree object

guilgautier / DPPy

Python toolbox for sampling Determinantal Point Processes

https://dppy.readthedocs.io

MIT License

219 stars 52 forks source link

Problem with the output of Uniform Spanning Tree object #24

Closed SlimKammoun closed 5 years ago

SlimKammoun commented 5 years ago

I have a small problem with the output of "Uniform Spanning Tree" I am using python 3.7.0

capture d ecran de 2018-10-08 18-24-30

Naereen commented 5 years ago

Hi @kammmoun! Can you specify what you mean by "problem": what did you expect? Is it because the histogram is shrinked vertically?

Naereen commented 5 years ago

@guilgautier I think the problem comes from this line: density=1 https://github.com/guilgautier/DPPy/blob/1bb98980cc4afb1035118c9673bb044547793e30/dppy/beta_ensembles.py#L437 density=1 has a weird behavior, maybe @kammmoun you can try to remove this density=1 and tell us if the plots are still like this? (cf. the documentation of matplotlib.pyplot.hist)

SlimKammoun commented 5 years ago

Thank you for responding. I think it is not a graphical problem To be precise I am running notebooks/DPPy/notebooks/exotic_dpps. The sum in " dict_count_sampled_st" is clearly not equal to 10000.

capture d ecran de 2018-10-16 09-55-59

It may be just a probleme in networkx (I am using version 2.2)

Naereen commented 5 years ago

:+1: Hi @kammmoun OK, I'll check this notebook and let you know as soon as possible.

Naereen commented 5 years ago

I was able to reproduce your result.
However I don't know the source of the problem. It might be networkx, but it's not a version problem as I have the latest.
It's weird that the histogram is built manually, I don't know why.
And I don't think it's an issue that the values in the dict sum or not to 10000.

I guess from my part I did as much as I could, sorry… @guilgautier will help you more when he'll be available. Thanks for your interest and reply anyway!

guilgautier commented 5 years ago

Hi @kammmoun and @Naereen!

I'm back on track and I've just started looking at this issue Everything worked out well on my own configuration The first clue might be the version of the networkx package where the ordering of the weights/nodes is not the same, see the graph display. This leads to a "permuted" incidence matrix, from which the kernel is built.

G-colab Python 3.6, networkx 2.2 |vs| my config Python 3.5, networkx 2.1

Let me dig a bit further

guilgautier commented 5 years ago

Hi guys,

The message associated to my attempt to fix this issue automatically closed it, sorry for that.

@kammmoun and/or @Naereen could you run the notebook and let me know if its ok now ? To me this is due to the newest networkx version, since the the edges of undirected graphs are not ordered in the same way as before.

With the following

edges = [(3,0), (1,2), (4,3)]
g.add_edges_from(edges)
g.edges

Before, you always had

EdgeView([(0, 3), (1, 2), (3, 4)])

Now it gives

EdgeView([(3, 0), (3, 4), (1, 2)])

Naereen commented 5 years ago

Hi @guilgautier, sorry I won't have time until a few days, I'm really busy… I think @kammmoun can try to help you there.

SlimKammoun commented 5 years ago

Hi @guilgautier & @Naereen Thank you very much for your help. Problem solved capture d ecran de 2018-10-24 18-24-35