GraphDistance error when Graph vertices are Associations

up vote
3
down vote

favorite

Bug introduces in 10.0 or earlier and persisting through 11.3

Here is a nice graph whose vertices are Associations:

g = Graph[> -> <,
 VertexLabels -> Automatic]

graph with associations as vertices

Several graph functions work as expected, e.g., AcyclicGraphQ[g] and AdjacencyMatrix[g].

However, functions that refer explicitly to the vertices don't work:

GraphDistance[g, <|"n" -> 2|>, <|"n" -> 4|>]

"GraphDistance: Unknown option "n" in GraphDistance."

Or:

GraphDistance[g, <|"n" -> 2|>]

"GraphDistance: GraphDistance called with 1 argument; 2 or 3 arguments are expected."

It looks like it's interpreting the Association as a bunch of options to GraphDistance. Is that use of Associations documented somewhere?

(It seems that using non-integer vertices causes problems: link.)

edited 15 mins ago

Szabolcs

154k13418902

asked 5 hours ago

ConvexMartian

769416

Actually, I'm pretty confident that this will be fixed in the next version. :-) But do report it anyway.
â€“Â Szabolcs
14 mins ago

add a commentÂ |Â

up vote
3
down vote

favorite

Bug introduces in 10.0 or earlier and persisting through 11.3

Here is a nice graph whose vertices are Associations:

g = Graph[> -> <,
 VertexLabels -> Automatic]

graph with associations as vertices

Several graph functions work as expected, e.g., AcyclicGraphQ[g] and AdjacencyMatrix[g].

However, functions that refer explicitly to the vertices don't work:

GraphDistance[g, <|"n" -> 2|>, <|"n" -> 4|>]

"GraphDistance: Unknown option "n" in GraphDistance."

Or:

GraphDistance[g, <|"n" -> 2|>]

"GraphDistance: GraphDistance called with 1 argument; 2 or 3 arguments are expected."

It looks like it's interpreting the Association as a bunch of options to GraphDistance. Is that use of Associations documented somewhere?

(It seems that using non-integer vertices causes problems: link.)

edited 15 mins ago

Szabolcs

154k13418902

asked 5 hours ago

ConvexMartian

769416

Actually, I'm pretty confident that this will be fixed in the next version. :-) But do report it anyway.
â€“Â Szabolcs
14 mins ago

add a commentÂ |Â

up vote
3
down vote

favorite

Bug introduces in 10.0 or earlier and persisting through 11.3

Here is a nice graph whose vertices are Associations:

g = Graph[> -> <,
 VertexLabels -> Automatic]

graph with associations as vertices

Several graph functions work as expected, e.g., AcyclicGraphQ[g] and AdjacencyMatrix[g].

However, functions that refer explicitly to the vertices don't work:

GraphDistance[g, <|"n" -> 2|>, <|"n" -> 4|>]

"GraphDistance: Unknown option "n" in GraphDistance."

Or:

GraphDistance[g, <|"n" -> 2|>]

"GraphDistance: GraphDistance called with 1 argument; 2 or 3 arguments are expected."

It looks like it's interpreting the Association as a bunch of options to GraphDistance. Is that use of Associations documented somewhere?

(It seems that using non-integer vertices causes problems: link.)

edited 15 mins ago

Szabolcs

154k13418902

asked 5 hours ago

ConvexMartian

769416

Bug introduces in 10.0 or earlier and persisting through 11.3

Here is a nice graph whose vertices are Associations:

g = Graph[> -> <,
 VertexLabels -> Automatic]

graph with associations as vertices

Several graph functions work as expected, e.g., AcyclicGraphQ[g] and AdjacencyMatrix[g].

However, functions that refer explicitly to the vertices don't work:

GraphDistance[g, <|"n" -> 2|>, <|"n" -> 4|>]

"GraphDistance: Unknown option "n" in GraphDistance."

Or:

GraphDistance[g, <|"n" -> 2|>]

"GraphDistance: GraphDistance called with 1 argument; 2 or 3 arguments are expected."

It looks like it's interpreting the Association as a bunch of options to GraphDistance. Is that use of Associations documented somewhere?

(It seems that using non-integer vertices causes problems: link.)

bugs graphs-and-networks associations

edited 15 mins ago

Szabolcs

154k13418902

asked 5 hours ago

ConvexMartian

769416

edited 15 mins ago

Szabolcs

154k13418902

asked 5 hours ago

ConvexMartian

769416

edited 15 mins ago

Szabolcs

154k13418902

edited 15 mins ago

Szabolcs

154k13418902

edited 15 mins ago

Szabolcs

154k13418902

asked 5 hours ago

ConvexMartian

769416

asked 5 hours ago

ConvexMartian

769416

asked 5 hours ago

ConvexMartian

769416

Actually, I'm pretty confident that this will be fixed in the next version. :-) But do report it anyway.
â€“Â Szabolcs
14 mins ago

add a commentÂ |Â

Actually, I'm pretty confident that this will be fixed in the next version. :-) But do report it anyway.
â€“Â Szabolcs
14 mins ago

Actually, I'm pretty confident that this will be fixed in the next version. :-) But do report it anyway.
â€“Â Szabolcs
14 mins ago

add a commentÂ |Â

2 Answers
2

active

oldest

votes

up vote
3
down vote

accepted

Sadly, this another one in a long row of issues with noninteger vertices for Graph where things neither work as documented nor as they should. Since GraphDistance is a kernel function, we non-insiders cannot tell why this happens. (But every now and then, associations are interpreted as list of rules; e.g. when used as second argument of ReplaceAll.)

What I can do for you is to provide a way to circumvent that by using integer vertices and the associations as vertex labels. For looking up a vertex from its label, we employ an association a.

edgelist = "n" -> 4; 
vertexlist = Sort[DeleteDuplicates[Flatten[List @@@ edgelist]]];
a = AssociationThread[vertexlist, Range[Length[vertexlist]]];

Visuably, we obtain the same graph:

g = Graph[
 Map[a, edgelist, 2],
 VertexLabels -> KeyValueMap[key, val [Function] val -> key, a]
 ]

enter image description here

In calls to Graph-related function that require vertices as argument, we have to insert the lookup function a:

GraphDistance[g, a[<|"n" -> 2|>], a[<|"n" -> 4|>]]

1

answered 5 hours ago

Henrik Schumacher

41.6k259124

Thank you! And regarding the behavior where an Association as a final argument is interpreted as options, is this known behavior?
â€“Â ConvexMartian
2 hours ago

No, I don't think so. For example, Graphics[Disk, <|PlotRange -> -10, 10|>] produces errors while Graphics[Disk, Normal@<|PlotRange -> -10, 10|>] works as expected. But option processing is not handled consistently, even among built-in functions. An in particular Graph-related functions process their arguments in a very obfuscated and inconsistent way (e.g. flattening out lists so that using lists as vertices causes errors in a similar way).
â€“Â Henrik Schumacher
1 hour ago

I once browsed HighlightGraph and its backend to repair a bug for Szabolcs. (Fortunately, the bug was not completely hidden in the kernel) and it got me the creeps how WRI processes the input. There were at least a dozen of layers of abstraction to unravel before I could find the actual bug (which was in itself not that complicated). But I have to admit that writing computational code is one thing and that writing code for user interaction is an entirely different thing.
â€“Â Henrik Schumacher
1 hour ago

add a commentÂ |Â

up vote
1
down vote

This is clearly a bug, and as Henrik said, a fairly common type of bug, unfortunately. When you encounter such problems, please do report them to Wolfram.

As a workaround, you can use IGDistanceMatrix from my IGraph/M package.

<<IGraphM`

IGDistanceMatrix[g, >, "n" -> 4]
(* 1 *)

This function takes only lists of vertices as the 2nd and 3rd argument. It does not take single vertex names. This is a mild inconvenience, but on the upside, it eliminates any ambiguities whether an expression is a vertex list or a single vertex name that happens to be a list (or association or whatever).

answered 15 mins ago

Szabolcs

154k13418902

add a commentÂ |Â

Your Answer

StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\$","\$"]]);
);
);
, "mathjax-editing");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "387"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmathematica.stackexchange.com%2fquestions%2f183665%2fgraphdistance-error-when-graph-vertices-are-associations%23new-answer', 'question_page');

);

Post as a guest

Name

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

up vote
3
down vote

accepted

What I can do for you is to provide a way to circumvent that by using integer vertices and the associations as vertex labels. For looking up a vertex from its label, we employ an association a.

edgelist = "n" -> 4; 
vertexlist = Sort[DeleteDuplicates[Flatten[List @@@ edgelist]]];
a = AssociationThread[vertexlist, Range[Length[vertexlist]]];

Visuably, we obtain the same graph:

g = Graph[
 Map[a, edgelist, 2],
 VertexLabels -> KeyValueMap[key, val [Function] val -> key, a]
 ]

enter image description here

In calls to Graph-related function that require vertices as argument, we have to insert the lookup function a:

GraphDistance[g, a[<|"n" -> 2|>], a[<|"n" -> 4|>]]

1

answered 5 hours ago

Henrik Schumacher

41.6k259124

Thank you! And regarding the behavior where an Association as a final argument is interpreted as options, is this known behavior?
â€“Â ConvexMartian
2 hours ago

No, I don't think so. For example, Graphics[Disk, <|PlotRange -> -10, 10|>] produces errors while Graphics[Disk, Normal@<|PlotRange -> -10, 10|>] works as expected. But option processing is not handled consistently, even among built-in functions. An in particular Graph-related functions process their arguments in a very obfuscated and inconsistent way (e.g. flattening out lists so that using lists as vertices causes errors in a similar way).
â€“Â Henrik Schumacher
1 hour ago

I once browsed HighlightGraph and its backend to repair a bug for Szabolcs. (Fortunately, the bug was not completely hidden in the kernel) and it got me the creeps how WRI processes the input. There were at least a dozen of layers of abstraction to unravel before I could find the actual bug (which was in itself not that complicated). But I have to admit that writing computational code is one thing and that writing code for user interaction is an entirely different thing.
â€“Â Henrik Schumacher
1 hour ago

add a commentÂ |Â

up vote
3
down vote

accepted

What I can do for you is to provide a way to circumvent that by using integer vertices and the associations as vertex labels. For looking up a vertex from its label, we employ an association a.

edgelist = "n" -> 4; 
vertexlist = Sort[DeleteDuplicates[Flatten[List @@@ edgelist]]];
a = AssociationThread[vertexlist, Range[Length[vertexlist]]];

Visuably, we obtain the same graph:

g = Graph[
 Map[a, edgelist, 2],
 VertexLabels -> KeyValueMap[key, val [Function] val -> key, a]
 ]

enter image description here

In calls to Graph-related function that require vertices as argument, we have to insert the lookup function a:

GraphDistance[g, a[<|"n" -> 2|>], a[<|"n" -> 4|>]]

1

answered 5 hours ago

Henrik Schumacher

41.6k259124

Thank you! And regarding the behavior where an Association as a final argument is interpreted as options, is this known behavior?
â€“Â ConvexMartian
2 hours ago

No, I don't think so. For example, Graphics[Disk, <|PlotRange -> -10, 10|>] produces errors while Graphics[Disk, Normal@<|PlotRange -> -10, 10|>] works as expected. But option processing is not handled consistently, even among built-in functions. An in particular Graph-related functions process their arguments in a very obfuscated and inconsistent way (e.g. flattening out lists so that using lists as vertices causes errors in a similar way).
â€“Â Henrik Schumacher
1 hour ago

I once browsed HighlightGraph and its backend to repair a bug for Szabolcs. (Fortunately, the bug was not completely hidden in the kernel) and it got me the creeps how WRI processes the input. There were at least a dozen of layers of abstraction to unravel before I could find the actual bug (which was in itself not that complicated). But I have to admit that writing computational code is one thing and that writing code for user interaction is an entirely different thing.
â€“Â Henrik Schumacher
1 hour ago

add a commentÂ |Â

up vote
3
down vote

accepted

What I can do for you is to provide a way to circumvent that by using integer vertices and the associations as vertex labels. For looking up a vertex from its label, we employ an association a.

edgelist = "n" -> 4; 
vertexlist = Sort[DeleteDuplicates[Flatten[List @@@ edgelist]]];
a = AssociationThread[vertexlist, Range[Length[vertexlist]]];

Visuably, we obtain the same graph:

g = Graph[
 Map[a, edgelist, 2],
 VertexLabels -> KeyValueMap[key, val [Function] val -> key, a]
 ]

enter image description here

In calls to Graph-related function that require vertices as argument, we have to insert the lookup function a:

GraphDistance[g, a[<|"n" -> 2|>], a[<|"n" -> 4|>]]

1

answered 5 hours ago

Henrik Schumacher

41.6k259124

What I can do for you is to provide a way to circumvent that by using integer vertices and the associations as vertex labels. For looking up a vertex from its label, we employ an association a.

edgelist = "n" -> 4; 
vertexlist = Sort[DeleteDuplicates[Flatten[List @@@ edgelist]]];
a = AssociationThread[vertexlist, Range[Length[vertexlist]]];

Visuably, we obtain the same graph:

g = Graph[
 Map[a, edgelist, 2],
 VertexLabels -> KeyValueMap[key, val [Function] val -> key, a]
 ]

enter image description here

In calls to Graph-related function that require vertices as argument, we have to insert the lookup function a:

GraphDistance[g, a[<|"n" -> 2|>], a[<|"n" -> 4|>]]

1

answered 5 hours ago

Henrik Schumacher

41.6k259124

answered 5 hours ago

Henrik Schumacher

41.6k259124

answered 5 hours ago

Henrik Schumacher

41.6k259124

answered 5 hours ago

Henrik Schumacher

41.6k259124

Thank you! And regarding the behavior where an Association as a final argument is interpreted as options, is this known behavior?
â€“Â ConvexMartian
2 hours ago

No, I don't think so. For example, Graphics[Disk, <|PlotRange -> -10, 10|>] produces errors while Graphics[Disk, Normal@<|PlotRange -> -10, 10|>] works as expected. But option processing is not handled consistently, even among built-in functions. An in particular Graph-related functions process their arguments in a very obfuscated and inconsistent way (e.g. flattening out lists so that using lists as vertices causes errors in a similar way).
â€“Â Henrik Schumacher
1 hour ago

I once browsed HighlightGraph and its backend to repair a bug for Szabolcs. (Fortunately, the bug was not completely hidden in the kernel) and it got me the creeps how WRI processes the input. There were at least a dozen of layers of abstraction to unravel before I could find the actual bug (which was in itself not that complicated). But I have to admit that writing computational code is one thing and that writing code for user interaction is an entirely different thing.
â€“Â Henrik Schumacher
1 hour ago

add a commentÂ |Â

Thank you! And regarding the behavior where an Association as a final argument is interpreted as options, is this known behavior?
â€“Â ConvexMartian
2 hours ago

No, I don't think so. For example, Graphics[Disk, <|PlotRange -> -10, 10|>] produces errors while Graphics[Disk, Normal@<|PlotRange -> -10, 10|>] works as expected. But option processing is not handled consistently, even among built-in functions. An in particular Graph-related functions process their arguments in a very obfuscated and inconsistent way (e.g. flattening out lists so that using lists as vertices causes errors in a similar way).
â€“Â Henrik Schumacher
1 hour ago

I once browsed HighlightGraph and its backend to repair a bug for Szabolcs. (Fortunately, the bug was not completely hidden in the kernel) and it got me the creeps how WRI processes the input. There were at least a dozen of layers of abstraction to unravel before I could find the actual bug (which was in itself not that complicated). But I have to admit that writing computational code is one thing and that writing code for user interaction is an entirely different thing.
â€“Â Henrik Schumacher
1 hour ago

Thank you! And regarding the behavior where an Association as a final argument is interpreted as options, is this known behavior?
â€“Â ConvexMartian
2 hours ago

No, I don't think so. For example, Graphics[Disk, <|PlotRange -> -10, 10|>] produces errors while Graphics[Disk, Normal@<|PlotRange -> -10, 10|>] works as expected. But option processing is not handled consistently, even among built-in functions. An in particular Graph-related functions process their arguments in a very obfuscated and inconsistent way (e.g. flattening out lists so that using lists as vertices causes errors in a similar way).
â€“Â Henrik Schumacher
1 hour ago

I once browsed HighlightGraph and its backend to repair a bug for Szabolcs. (Fortunately, the bug was not completely hidden in the kernel) and it got me the creeps how WRI processes the input. There were at least a dozen of layers of abstraction to unravel before I could find the actual bug (which was in itself not that complicated). But I have to admit that writing computational code is one thing and that writing code for user interaction is an entirely different thing.
â€“Â Henrik Schumacher
1 hour ago

add a commentÂ |Â

up vote
1
down vote

This is clearly a bug, and as Henrik said, a fairly common type of bug, unfortunately. When you encounter such problems, please do report them to Wolfram.

As a workaround, you can use IGDistanceMatrix from my IGraph/M package.

<<IGraphM`

IGDistanceMatrix[g, >, "n" -> 4]
(* 1 *)

answered 15 mins ago

Szabolcs

154k13418902

add a commentÂ |Â

up vote
1
down vote

This is clearly a bug, and as Henrik said, a fairly common type of bug, unfortunately. When you encounter such problems, please do report them to Wolfram.

As a workaround, you can use IGDistanceMatrix from my IGraph/M package.

<<IGraphM`

IGDistanceMatrix[g, >, "n" -> 4]
(* 1 *)

answered 15 mins ago

Szabolcs

154k13418902

add a commentÂ |Â

up vote
1
down vote

This is clearly a bug, and as Henrik said, a fairly common type of bug, unfortunately. When you encounter such problems, please do report them to Wolfram.

As a workaround, you can use IGDistanceMatrix from my IGraph/M package.

<<IGraphM`

IGDistanceMatrix[g, >, "n" -> 4]
(* 1 *)

answered 15 mins ago

Szabolcs

154k13418902

This is clearly a bug, and as Henrik said, a fairly common type of bug, unfortunately. When you encounter such problems, please do report them to Wolfram.

As a workaround, you can use IGDistanceMatrix from my IGraph/M package.

<<IGraphM`

IGDistanceMatrix[g, >, "n" -> 4]
(* 1 *)

answered 15 mins ago

Szabolcs

154k13418902

answered 15 mins ago

Szabolcs

154k13418902

answered 15 mins ago

Szabolcs

154k13418902

answered 15 mins ago

Szabolcs

154k13418902

add a commentÂ |Â

draft saved

draft discarded

draft saved

draft discarded

Post as a guest

Name

Search This Blog

Iyfjky