Possible fix for exploding object size

[sebffischer]

I am not yet sure whether this has any negative consequences that are problematic.

What do you think about this approach?

If this is a desirable solution to #1320 then I would still need to add more tests.
Also, I think a more robust way to access the inherit class is required.

devtools::load_all("~/gh/torch")
#> ℹ Loading torch

nn_module1 = nn_module("nn_module1",
  initialize = function(data) {
    data
    self$layer = nn_module("layer",
      initialize = function() {
        self$linear = nn_linear(10, 1)
      },
      forward = function(x) {
        self$linear(x)
      }
    )()
  },
  forward = function(x) {
    self$layer(x)
  }
)

pryr::object_size(nn_module1(rnorm(1L)))
#> 916.81 kB
pryr::object_size(nn_module1(rnorm(1000000L)))
#> 916.81 kB


# What will not work:

nn_module2 = nn_module("nn_module1",
  initialize = function(data) {
    f = nnf_relu
    self$layer = nn_module("layer",
      initialize = function() NULL,
      forward = function(x) {
        f(x)
      }
    )()
  },
  forward = function(x) {
    self$layer(x)
  }
)

nn_module2()(torch_randn(1))
#> Error in f(x): could not find function "f"

^{Created on 2025-05-28 with reprex v2.1.1}

[dfalbel]

Looks reasonable, although I do think we should not recommend people to define modules within modules. It's better to define them in top level environments. In the worst case scenario its always possible to create a generic module that takes a closure to initialize parameters a a forwardclosure. Eg:

nn_generic_module <- nn_mopdule(
   inititialize = function(init, fwd) {
      self$fwd <- fwd
      self$pars <- lapply(init(), nn_parameter) 
   },
   forward = function(x) {
      self$fwd(pars, x)
   } 
)

[dfalbel]

Mayvbve add a comment about the 2 here