Maximum Degree Range Doesn't Update on Subfilter

Bug #725688 reported by Elijah Meeks on 2011-02-26
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Gephi
Fix Released
High
Mathieu Bastian

Bug Description

When using the Degree Range filters, if you have a subfilter that increases the maximum degree range of the nodes displayed, then those nodes will disappear because they fall outside the old maximum range.

While it may be that someone wants to see all nodes that fall into a specific numeric range of degree, I intuitively want the top of that range to be a Max Value that updates to the Current Max Value.

Do you have a use case when node degrees are increased? It sounds a bit weird because filters only cut the graph.

tags: added: filter
Changed in gephi:
milestone: none → 0.7beta
Elijah Meeks (emeeks-stanford) wrote :

I noticed that this takes two distinct forms. In one case, I'm required to simply click on the main filter (Degree Range) and it re-initializes and shows everything up to the max degree. In other cases, I'm forced to manually drag the degree range slider to the maximum amount.

As to use cases, I run into this all the time, though I may be creating and analyzing graphs in a non-standard way. I'm attaching some screenshots to illustrate what's going on. I have a graph of Wikipedia edits wherein the contributors, edits and webpages are all nodes. All edits and web pages have a unixtime timestamp for their creation date or occurrence date but the contributors all exist the entire time (for this example, this just means that they all have the earliest unixtime timestamp). So I want to look at the graph with only the pages that are in existence and any contributors that are editing those pages. As such, screenshot 1 shows a Degree Range filter set to a minimum of 1 and with the maximum unchanged.

http://dhs.stanford.edu/dh/degree_issue1.PNG

Pages are in blue, contributors in orange and edits in pink. If I then adjust the parameters of the unixtime range to include more edits, then I counter-intuitively lose my most connected nodes:

http://dhs.stanford.edu/dh/degree_issue2.PNG

This is because suddenly the nodes have more connections than the current settings for the Degree Range parent filter. The situation is exacerbated when I increase the unixtime range even further.

http://dhs.stanford.edu/dh/degree_issue3.PNG

Notice that a new Wikipedia page has been created (in red). Please also note that I'm not updating the sizes, which are based on degree of connectedness of the entire graph and not its currently displayed extant. Now, here's the weird thing. As I said earlier, sometimes this problem goes away when I just click on the Degree Range parent filter. In this case, this was exactly what happened. Just by clicking on "Degree Range" in the Queries box, I get this:

http://dhs.stanford.edu/dh/degree_issue4.PNG

Other times, I distinctly remember being forced to manually increase the range (this may be the case with the subfilter as a Partition filter, I'll try to test this some time later). Now, obviously, I can always click on Degree Range to reinitialize the filter (or manually increase the range), but this is so terribly tedious and doesn't let me quickly and effectively filter a graph with a complex subfilter. As I said, perhaps this is non-standard, but I use these kinds of graphs all the time (where I run a filter that shows me only a connected part of the graph and I want the disconnected or lowly-connected parts to disappear).

Ok I see.

More simply, here is a way to isolate the bug:

1. Open a network
2. Create an INTERSECTION filter containing a Degree Range and an Indegree Range filter.
3. Adjust the range of one, then the other.
4. Apply Filter
5. Click on a sub-filter, then the other, then the first one.

The filtered graph is changing at each click because the range of the selected filter is refreshed at this exact moment.

Changed in gephi:
status: New → Confirmed
importance: Undecided → High

Fixed in rev 2164.

That was actually two different bugs. The bug described by Elijah is an improvement how we update ranges when the min/max changes. If the upper bound is set the maximum value and the max is increased, the upper bound is now updated also to stick to the max. Though it's not an obvious behaviour, it seems to be the most intuitive. Idem for the lower bound. This improvement concerns sub-queries.

The case described seems like the bug I just fixed in the range slider, but to be confirmed.

Changed in gephi:
status: Confirmed → Fix Committed
assignee: nobody → Mathieu Bastian (mathieu.bastian)

Thanks for the complete bug report by the way guys, it helped a lot to understand the issue!

The DegreeRange filter does not update itself properly, if the data to be filtered have changed. For example, add the filter to a simple graph and keep the slider at min and max (1 and 36 for Les Miserables.gexf). Now add an edge to the node with the highest degree or simply insert a node. In the former case, the filter should update its max automatically to 37, in latter case, the min should be set to 0. However, nothing works automatically, but only after manually updating the filter.

This could be a general problem for all filters that in one or the other way rely on data about the graph. In that case, the filters should listen to changes of the graph (topology, attributes, etc.)

André Panisson (panisson) wrote :

Just to add a comment regarding filter updating and performance. We had a similar problem in another application, and it is not very simple. If the filter listen to changes in the graph and updates it accordingly for each event, this could be a great performance problem in case of high event rate, and if the filter should analyze the entire graph in order to update.
In our case, we choose to redesign some of the filters to not analyze the entire graph for each event (for example, by updating only affected nodes when an edge is added), but I don't know if it would be as easy in Gephi.

Actually, Filters are already listening to graph events, with an 'AutoRefreshor' class. If you add or remove an element, the current filter query is reexecuted. However, as your observed the user interface is not refreshed, and that's an issue for degree filters for instance. I think we can open another bug for that.

Currently the filter auto refreshor lives in a separate thread and will refresh fiters if necessary, with a one second rate. That impacts performances, but it should be okay.

Changed in gephi:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers