Just noticed it's probably good to rewrite something like Min[f /@ data] > x into AllTrue[data, f[#] > x &]... too bad it can't happen automagically.

What would be the most efficient way to get one element from a list that isn't on another? I'm getting the hunch a hand-coded variant probably doesn't compete well with First @* Complement on most cases.

GraphUnion doesn't work with single argument... :I

Heh. Spent couple hours of time writing code that, in the end, is equivalent to BooleanRegion[Xor, #] &. The positive part seems to be that my code is much more efficient with actual discretization (but also demands regions to be nicely-behaving polygons).

BoundaryDiscretizeRegion[
     RegionUnion @@ (Function[{root, g},
         RegionDifference[#, (#0 /@
               Cases[VertexOutComponent[g, #, 1], Except@#]) /. {{} ->
                EmptyRegion@2, {x__} :> RegionUnion@x}] &@
          root] @@@ #)] &[
   Function[g,
       With[{root =
          SelectFirst[VertexList@g,
           VertexInDegree[g, #] == 0 &]}, {root,
         If[Length@# == 1, First@#, GraphUnion @@ #] &@
          Append[Flatten[
            Graph[DirectedEdge @@@ Partition[#, 2, 1]] & /@

I'm not certain if that code wins prizes in readability or elegance in general. :)

I wonder what would be the best way to find a "longest path" in a directed graph. FindShortestPath with negative weights seems to give correct result only occassionally.

To decrease readability of that snippet, I also used #0. :)

One hint, BTW: if you're trying to convert a tree-shaped graph to a hierarchial lists-in-lists kind of data structure, don't bother with DepthFirstScan or BreadthFirstScan. It's much easier to just walk the graph recursively with your own code.

@kirma This code: firstNotIn[fst_, sec_] :=FirstCase[fst, Except[Alternatives @@ sec]] will be about twice faster than First@*Complement on packed arrays, and vastly faster in general on unpacked arrays - for large enough arrays.

@LeonidShifrin Hmmm. That looks like a construct that might indeed work efficiently.

@kirma This is actually not obvious at all. I just happen to know that Cases (and apparently also FirstCase) were optimized for Alternatives @@ options pattern, if options does not contain blanks or other pattern-building placeholders

@LeonidShifrin Well, "might" in the sense it uses abstractions instead of explicit iteration, or something similar. And in this case it does that Alternatives optimization.

@kirma AFAIK, that optimization was added in M8. Apparently, it also works with Except. In general, Cases with Alternatives would have a much worse complexity. So, in general Cases(and other constructs based on pattern-matching) usually aren't the best options for efficiency.

Interesting.

Now I'm amused by the fact that if I slice a region into two using a in RegionIntersection and HalfSpace and then BoundaryDiscretizeRegion it, vertices along the edge of that HalfSpace don't match.

Life would really be much easier if they did...

Note the hole on first region. It disappeared!

Yes, it's a bug. Hrmmmm....

Well, reported it. With luck, there'll be a fix on this decade! :)

Some Methods work better on this regard, but are absolutely not scalable enough...