Unrecognized edge type o--.

[tk27182]

Running a bootstrapped tetradrunner FCI with a high enough alpha value (0.1) will sometimes throw the error:

Error in cgraph(graph$nodes, new_edges) : Unrecognized edge type o--.

Printing the graph's edge lists doesn't show that edge type in the list, and running it again will sometimes not throw the error and proceed normally.

[tk27182]

Actually, the edge does appear in the original graph, I was printing after the cgraph was made.

Perhaps adding a new global variable .CIRCLEUNDIRECTED <- "o--" to globals.R would be a solution?

[tzimiskes]

@ekummerfeld is one of those things that Joe did to try to make sense of the "orientation" phase in FCI when the data is bad? It seems to me that "o--" isn't quite a real edge type

[tzimiskes]

@tk27182 Depending on what Erich says, I may convert it into "o-o" when I get around to updating the code

[ekummerfeld]

I'm also not 100% sure if that's a real edge type or not. I'm trying to imagine how FCI's logic would produce such a thing. It looks like it's making an arrow tail at one end, and a circle at the other, so it's at least still the standard 3 characters long. I juts can't really think up on the fly a situation where one would identify that specific combination of endpoints from data.

I'll inquire with Joe and get back to you.

[ekummerfeld]

Thinking about it more, the circle kinda indicated "maybe a latent here" while the arrow tail indicate "no latents here", so at the very least this combination of endpoints on one edge seems contradictory in terms of their semantics. That makes me lean towards "not a real edge type", but I still want to confirm with Joe first. If it isn't a real edge type, there's still a big "then why did FCI do this?" question.

[tzimiskes]

I think we have shown the resampling methods can really muck up TETRAD PC variants, especially when the sample size is pretty small.