@yode here is the source

@yode Hi. I'd say these are two different bugs, but probably closely related. Let me have another look.

well, one is fixed in 11.0.1 and the other not, so I suppose the bug is not the same. If it is, the correction of the bug was not made general enough? I cannot say, I've to give a closer look at your post first.

you can run the code in the source I linked to have the updated version (didn't try myself)

@yode both seem to be fixed in 11.0.1 actually. I may have checked the latter in 11.0.0 but forgot to check it in 11.0.1

ah wait no...

I was being confused with the code you wrote and the one you have in the image

@yode so this bug is about the two-argument form of RelationGraph, and the issue with duplicates

a simpler code would be: RelationGraph[#1 < 4 && #2 >= 4 &, {1, 1, 2, 3, 4, 5, 6, 7, 8, 9}]

this fails from 10.2 to 11.0.1

if you remove the duplicates, this works in all versions

I don't get the vertex labels with RelationGraph[#1 < 4 && #2 >= 4 &, {1, 1, 2, 3, 4, 5, 6, 7, 8, 9}] however in 11.0.1, but I have them without the duplicates.

@yode this other bug is about the three-argument form of RelationGraph

I get error messages in both 11.0.0 and 11.0.1, although not the same.

"this fails from 10.2 to 11.0.1" ---> "this fails from 10.2 to 11.0.0"

@J.M. OK, thanks.

@yode I think those are two different wrong behaviors

About the graph and code you posted in the chat, RelationGraph was doing unnecessary evaluations, which has been fixed in 11.0.1. About the presence of two {1,4}, it seems that RelationGraph evaluates once the test function on the first element of the first list (Range[3]) and of the second list (Range[4, 7]). If it does not evaluate to True or False, the algo of RelationGraph will stop; otherwise it will continue.

Compare for instance Reap[RelationGraph[(Sow[{##}]; Mod[#1, #2] == 2) &, {1, 2, 3}, Range[4, 7]];]

to Reap[RelationGraph[(Sow[{##}]; Mod[#1, #2] == 2) &, {"a", 2, 3}, Range[4, 7]];].

This is probably some safety feature. RelationGraph considers that if its check did not yield True or False, the lists or the test function are not properly constructed, so it doesn't bother evaluating the test function on all elements.

Plot is doing some extra evaluations as well (not for the same reason). Evaluate for instance Reap[Plot[Sow[x], {x, -1, 1}, MaxRecursion -> 1, PlotPoints -> 2];]

@yode Yes, the check test is only performed on the first element of the two lists. At this point, I think this is only a choice of design by the developers. The first check test must return True or False for the algorithm to proceed. If this is not wanted, one could wrap the test function in a TrueQ to get the full evaluation in the first situation: Reap[RelationGraph[(Sow[{##}]; TrueQ[Mod[#1, #2] == 2]) &, {"a", 2, 3}, Range[4, 7]];].

@sky-light What about doing $PreRead=.?

@yode I am thinking that this safety feature makes sense when giving a bad test function, such as an undefined symbol f, rather than "bad" vertices.

I would say so. It prevents evaluations when a test function is badly constructed (or simply not a test function), e.g. ClearAll[f]; Reap[RelationGraph[(Sow[{##}]; f[#1, #2]) &, Range[10^6], Range[10^6]];].

Also, for this last code, if the condition of having True or False on the first check was not done, and since an evaluation to something else than True and False is effectively considered as False for all the other checks, you would just end up with a graph of not-connected vertices, for any badly constructed test function.

This may not be useful when asking for a relation graph.

@yode There are implementations where no check is done, and the evaluation is performed completely. For instance, ContainsAll[{"A", "B", "C"}, {"a", "b"}, SameTest -> (Echo@f[##] &)]. So in the end, I think this is just a choice of design done by each developer.

@yode I think the behavior you linked is a bug, unrelated to the other. In the first bug you wrote, whose simplified version is RelationGraph[#1 < 4 && #2 >= 4 &, {1, 1, 2, 3, 4, 5, 6, 7, 8, 9}], the combination are down within the same list. This is expected in view of the first usage line of the ref page: "... whenever f[vi, vj] is True."

Somehow, having a duplicate vertex messed up the computation, and this was fixed in 11.0.1. Compare for instance in 10.4.1 and 11.0.1: Reap[RelationGraph[(Sow[{##}]; #1 < 4 && #2 >= 4) &, {1, 1, 2, 3, 4, 5, 6, 7, 8, 9}]][[2, 1]].

@yode In the behavior you linked, there was combinations of elements in the same list, which should not have happened in view of the second usage line: "... whenever f[vi, wj] is True."

You can compare now Reap[RelationGraph[(Sow[{##}]; #1 < 4 && #2 >= 4) &, {1, 2, 3}, {4, 5, 6}]][[2, 1]] in 10.4.1 and 11.0.1. The wrong combinations happen in 10.4.1 but not anymore in 11.0.1.

You can see that what you underlined in red in your post does not happen anymore in 11.0.1. Combinations from elements of the same list is not done anymore.

There are however still unnecessary/uncorrect evaluations in 11.0.1, as reported by the error messages. Those were in 10.4.1 and are still in 11.0.1. RegionMember[#1, #2] & evaluates in RelationGraph as RegionMember[#1, #2] & and as RegionMember[#2, #1] &, which should not happen.

I think those are the not the same problem, but maybe we are not using the same terminology, hence the disagreement.

@yode Ah sorry, I think I understand now. "RegionMember[#1, #2] & evaluates in RelationGraph as RegionMember[#1, #2] & and as RegionMember[#2, #1] &, which should not happen." ---> This is not correct. The test function needs not to be symmetric, in which case one will end up with directed graphs.

So yeah, this bug seems to be fixed as well.

I am not sure though that this is the same problem as the other bug, but I may be mistaken again. I'll have yet another look.

@yode I think I have a clearer picture about what was happening for this post. I have made an answer with my current understanding.