nominolo / union-find Goto Github PK

Like so

bug :: ()
bug = 
  let pt = evalState (state (fresh ()))
      v = descriptor newPointSupply pt
  in v

Now, arguably this is just the fault of the user. I'd like to entertain the idea that it's a deficiency in the API. Since Points are only meaningful in reference to a particular value of type PointSupply it's possible for them to "travel back in time". In other words, the semantics of the types of this API cannot forbid time travel.

Which would just be unfortunate, except there's a perfectly wonderful way to solve this problem by using the same phantom type variable trick that ST uses. It would require actually producing the monadic interface instead of leaving it thinly available from the types of the API, of course.

(Interestingly, this bug can be seen as inevitable in the code itself since IntMap.! is used without ensuring its invariants hold.)

In particular, I'd like to highlight this issue for this package as I ran into this problem elsewhere (in a Javascript library I'm writing) and now I'm writing up a series of blog posts to highlight it. I chose Union/Find as an algorithmic example and looked up to find this package.

Since the point of the post is to culminate in calling out this API bug and encouraging more people to use ST-style phantom variables, I wanted to give a forewarning in the event you would like to update documentation or API.

Finally, if it's not worth the added complexity in the API, I totally understand. I don't intend to call out this module specifically by any means. It's a perfectly good toolset for the proper use of an IntMap-backed Union/Find, but simply requires a little care.

Some exported modules lack documentation altogether, see https://hackage.haskell.org/package/union-find-0.2/docs/Data-UnionFind-IntMap.html

The source code contains commented out unfinished code: https://hackage.haskell.org/package/union-find-0.2/docs/src/Data-UnionFind-IntMap.html#newPointSupply

descriptor has an abruptly ending sentence as documentation. https://hackage.haskell.org/package/union-find-0.2/docs/Control-Monad-Trans-UnionFind.html

Consider

repr       :: PointSupply a -> Point a -> Point a
descriptor :: PointSupply a -> Point a -> a
equivalent :: PointSupply a -> Point a -> Point a -> Bool

They do not perform path compression, which may lead to O(n) performance for some points. It is nice to have simple interfaces where the updated PointSupply doesn't need to be handled. But, it would be nice to also have the following functions:

repr'       :: PointSupply a -> Point a -> (PointSupply a, Point a)
descriptor' :: PointSupply a -> Point a -> (PointSupply a, a)
equivalent' :: PointSupply a -> Point a -> Point a -> (PointSupply a, Bool)

That do path compression. It would be particularly nice to have in the Control.Monad.Trans.UnionFind transformer.

The naming conventions and implementation strategy coincide with the implementation of union find in The essence of ML type inference. Was it based off of that code? If so, a proper citation is in order.

I need to use point as key for a map.

Please add quickCheck properties and unit tests.
That would make me more confident to use this package.

Hi,

The IntMap implementation for the union function seems to present an incorrect behaviour when comparing the rank of the two sets S1 and S2 it's supposed to unite:

• if rank(S1) < rank(S2) then S2 is the taller tree and S1 is appended to its root;
• if their ranks are equal then S1 is appended to S2 and its rank is increased;
• if rank(S1) > rank(S2) then S2 is overwritten onto S1 and used as the taller tree.

The third case seems to contradict the intended behaviour of the union by rank operation, since the set with the highest rank (i.e. S1) is appended to the other.

The issue can be traced to line 64 of IntMap.hs:

63      GT ->
64        let !eqs1 = IM.insert i1 (Info r2 a2) eqs
65            !eqs2 = IM.insert i2 (Link i1) eqs1 in
66        PointSupply next eqs2

Since r2 is the lower rank, the function should not replace p1 with p2's Info; overwriting p2 as a Link to p1 should be enough.

In base-4.17, the MonadFail instance for ST was removed:

$ cabal build
Build profile: -w ghc-9.4.4 -O1
In order, the following will be built (use -v for more details):
 - union-find-0.2 (lib:union-find) (first run)
...
src/Data/UnionFind/ST.hs:133:5: error:
    • No instance for (MonadFail (ST s))
        arising from a do statement
        with the failable pattern ‘Info info_ref1’
    • In a stmt of a 'do' block: Info info_ref1 <- readSTRef link_ref1
      In the second argument of ‘($)’, namely
        ‘do Info info_ref1 <- readSTRef link_ref1
            Info info_ref2 <- readSTRef link_ref2
            MkInfo w1 d1 <- readSTRef info_ref1
            MkInfo w2 d2 <- readSTRef info_ref2
            ....’
      In a stmt of a 'do' block:
        when (point1 /= point2)
          $ do Info info_ref1 <- readSTRef link_ref1
               Info info_ref2 <- readSTRef link_ref2
               MkInfo w1 d1 <- readSTRef info_ref1
               MkInfo w2 d2 <- readSTRef info_ref2
               ....

Lifted from:

• commercialhaskell/stackage#6770

In my role as Hackage Trustee, I revised base to <4.17: https://hackage.haskell.org/package/union-find-0.2/revisions/

It'd be useful to split the operations into a typeclass, mtl-style; then we could (for instance) test with the IntMap version but use an ST-based monad in production. I'm guessing it'd be something like

class Monad m => MonadUnionFind p m | m -> p where
  type Point m
  fresh :: p -> m (Point m)
  repr :: p -> m (Point m)
  descriptor :: Point m -> m p
  union :: Point m -> Point m -> m ()
  equivalent :: Point m -> Point m -> m ()