-
Notifications
You must be signed in to change notification settings - Fork 50
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
what is the current status of support for recursive definitions? #33
Comments
I'm curious about this too. Specifically I'm interested in deriving backpropagation for RNNs, e.g. LSTM. When I try the straightforward approach of folding over the inputs the CCC translation seems to get hung up on the recursive let binding. What makes this a "no go" currently? |
It's just something I've not gotten around to. I think it requires roughly the following:
|
I think I'm going to try tackling part of this. I only need to support non-mutually-recursive local Thanks. |
Great! I haven’t worked on it at all. I’m happy to help with design issues and implementation if you like. |
The approach I've implemented is to "unfix" any recursive definition ( fixC :: Prod k a x `k` x -> a `k` x so, I'd like to be able to weaken the conversion so I can get away with traced monoidal, instead of traced Cartesian in some cases, but I'm not sure how to do that. |
How wonderful to hear of activity on this front!
That How did you come up with your type?
Which is the “extra parameter” here? By argument order, I guess |
The first half of this is correct, but this means This To summarize that paper (and a couple other sources, where I don't remember what comes from which): A traced monoidal category has a So, I was able to come up with a translation in terms of |
Oh, yeah, the nLab page you linked has a brief section on the "parameterized fixed-point" and a reference to the paper I linked: https://ncatlab.org/nlab/show/traced+monoidal+category#in_cartesian_monoidal_categories |
Thanks. I see my mistake now. |
A small update to this. I had said "the extra parameter is always Here's a short conversion: fix :: (a -> a) -> a
fixC :: (x, a) `k` a -> x `k` a
-- the starting point of the conversion, thus the goal is @x `k` a@
(\x -> fix U) :: x -> a
goLam x U :: x `k` a -> a
uncurry (goLam x U) :: (x, a) `k` a
fixC (uncurry (goLam x U)) :: x `k` a So, the extra parameter is the |
we chatted about how thats current a no go at ICFP 2017, has there been any action on that since?
The text was updated successfully, but these errors were encountered: