Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

seminaive propagators #5

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from
Draft

seminaive propagators #5

wants to merge 4 commits into from

Conversation

rntz
Copy link

@rntz rntz commented Sep 22, 2022

I've taken a stab at updating the seminaive propagators to avoid the race condition you mentioned. This involves remembering state for each propagator that might need to access the previous version of its inputs. This linearizes the delta-processing for each relation between propagators; you can think of each one as a little stateful process that reads deltas from its input propagators and writes to its output.

This PR isn't really "ready" yet; I haven't implemented feature-parity with regular Data.Recursive.Set functions. I'm also not entirely confident I've avoided all race conditions, I'm pretty new to concurrent programming in Haskell. I'm not sure whether you're interested in this approach; feel free to close this PR if not. But if you are, I'd be interested in any feedback you have.

@rntz
Copy link
Author

rntz commented Sep 22, 2022

huh, it looks like you've done a big refactor that removes the R type? I'm going to need to take a look at that, I guess!

@nomeata
Copy link
Owner

nomeata commented Sep 22, 2022

Yes, the R value didn’t add much.

But I expect your work could be a drop-in replacement for Data.Propagator.Naive, and not affected by the “pure wrapping”.

I am wondering if anything more elaborate than the naive propagator should live in a separate package – easier to refine independently, and maybe useful to people who don’t trust my pure API anyways. Or maybe it is overkill.

Comment on lines +14 to +22
class (Eq a, Bottom a) => ChangeAction da a where
-- laws:
-- 1. update (kickoff x) bottom == x
-- 2. (update dx x == y) implies ((x == y) == noChange dx x y)
update :: da -> a -> a
kickoff :: a -> da
noChange :: da -> a -> a -> Bool
noChange dx x y = x == y
class ChangeAction (Delta a) a => Change a where type Delta a
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’d also expect (maybe as a later refinement) a way to efficiently assembles deltas. I.e. a Subgroup or Monoid constraint on da, and a law

update dy (update dx x) == update (dy <> dx) x


import Data.POrder

class (Eq a, Bottom a) => ChangeAction da a where
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that I replaced Eq with the check in POrder. This way we can deal with sets whose elements can’t be compared (it suffices to check the size of the sets).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants