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
Allow creating module instances outside hk.transform #16
Comments
The primary reason we don't currently allow this is that Uniquifying names requires us to track some state about the names that have already been created. We've made an attempt towards allowing the construction of modules that don't use There are other solutions that we could try here! One idea is to late-bind names inside Does that make sense? WDYT? |
That all makes sense, thanks for the explanation!
I think that would be great if that could be implemented without adding much complexity but I completely agree that it doesn't feel like a priority. I think the current API is just as powerful without this feature once you get use to it (which in my personal experience took me about 3 "oupsies" and cost me no more than 5 min in refactoring). |
I'm not sure if you want to keep this issue open for feature request tracking purposes but, if not, feel free to close it. |
That's good to hear - that's been my experience as well :) |
This makes transform trivial (the actual impl is only longer because of error checking): def transform_with_state(f): def init_fn(rng, x): with new_context(rng=rng) as ctx: f(x) return ctx.collect_params(), ctx.collect_state() def apply_fn(params, state, rng, x): with new_context(params=params, state=state, rng=rng) as ctx: return f(x), ctx.collect_state() return init_fn, apply_fn But also means we could in theory offer a fully imperative API: with new_context(rng=rng) as ctx: mod = hk.nets.MLP([300, 100, 10]) mod(example) params = ctx.collect_params() .. at some point later .. with new_context(params=params): out = mod(x) My motivation for exploring this API is that users very commonly want to be able to use their Haiku modules without having to wrap them in `hk.transform`, and some advanced users would like to be able to produce functions that look like `hk.transform` but with a different contract (e.g. producing multiple apply methods). My gut feeling is that this API while being strictly more flexible is also quite dangerous in JAX (e.g. there are many assumptions about functional purity in JAX which the results of `hk.transform` satisfies that this does not). I would like to make this available for folks to play with, but not expose it or promote it widely for now. Ping #16. PiperOrigin-RevId: 301013361 Change-Id: Ia5766a470ef08109c90be6d07f1226b742880c2b
Hello @trevorcai, @tomhennigan. I like a lot out of the box solutions, but I struggle with extending class Parameter():
def __init__(self, init_value: float, name: Text):
super().__init__(name="parameter")
self._name = name
self._init = hk.initializer.Constant(jnp.log(init_value))
def __call__(self):
return jnp.exp(hk.get_parameter(f"unconstrained_{self._name}", shape=[], init=self._init))
class Model(hk.Module):
def __init__(self, init_variance: float, name: Text):
super().__init__(name)
self._variance = Parameter(init_variance, "variance")
@property
def variance(self):
return self._variance()
def __call__(self, x: jnp.array) -> jnp.array:
return jnp.sum(self.variance * x) As you can see, a variance value in a parameter dictionary will not have much meaning without information about a transformation that a model uses (could be exp, softplus or another positive bijector). 1. One solution could be to return a model with transformed functions. def forward_fn(x):
m = Model(0.1)
hk.link(m)
return m(x)
forward = hk.transoform(forward_fn)
model = forward.linked_objects # get access to read only object 2. Another possible (?) solution could be making class Holder(hk.ModuleHolder):
@hk.transform
def forward(self, x):
self.model = Model(0.1)
return self.model(x)
forward = Holder().forward() PS: for me, it is a very important issue and a deciding factor on how I'm going to use the library. |
PiperOrigin-RevId: 350006409 Change-Id: If5c80b0e443ad41767185459940b524b31e1c607
This is as much a question as it is a feature request. What is the reasoning for not allowing a module instance from being created (but not used) outside
hk.transform
? I took a look athk.Module
andModuleMetaClass
but I feared my soul would get harvested by the dark forbidden magic involved before I could identify all the API features it permits.For example, I would have expected this to be possible:
Concretely, I'm curious to know what would have to be sacrificed (if anything) to support this kind of usage? Is it meant to prevent a module instance from being used in two different functions wrapped by two different
hk.transform
calls?I wouldn't be surprised if I were missing some nasty side effect if you were to allow module creation outside of
hk.transform
, but, if not, I think it would be more intuitive to allow this kind of usage.The text was updated successfully, but these errors were encountered: