New functions defined to make things working with autodiffr

[Non-Contradiction]

To get autodiffr working in some cases, some new functions are created to use instead of the original ones. The issue is to keep record of these new functions and provide a space to discuss about them.

• cSums, cMeans, rSums, rMeans are created w.r.t the original colSums, colMeans, rowSums, rowMeans.

  • Reason for implementation: The documentation in R made me believe that the original R functions are totally written in C and is not generic, These functions are equivalent to use of apply with FUN = mean or FUN = sum with appropriate margins, but are a lot faster. As they are written for speed, ....
    So the only way to work with them seems to be defining new functions.
  • Current issue: the implementation currently doesn't totally match the behavior of the original functions and arguments like na.rm are not accepted.
  • Examples: softmax <- function(x) sum(exp(x) / rSums(exp(x)))

• diagm are created to replace part of diag.

  • Reason for implementation: it's quite straightforward to get diag working for julia matrices to extract the diagonal part, but it turns out to be quite hard to let diag working for julia vectors to create a matrix with the vector as diagonal. This is a general issue about matrix creation problem, and we can see similar problems appear multiple times.... And I think using diagm and diag instead of one diag is great and can avoid many potential issues.
  • Current issue: the new method doesn't accept arguments like ncol, nrow and names.
  • Examples: don't have examples currently.

• map instead of mapply and sapply.

  • Reason for implementation: many functions involved in mapply and sapply are either internal-generic or non-generic at all, implementation a new function can really save the quirks in getting mapply or sapply working, and can be more efficient and the usage are nearly the same as mapply.
  • Current issue: the new method doesn't accept the same arguments that mapply accepts.
  • Examples: function(x) sum(map(function(y) x[1] * y, x))

• %m% instead of %*%.

  • Reason for implementation: as the R documentation suggests, %*% are only S4 generic but not S3 generic.
  • Current issue: the behavior of the current implementation of the product of matrix and vector doesn't match the behavior of %*% in R.
  • Examples: function(x) det(x[1,1] * solve(x %m% x) + x)

* `Jmatrix` instead of `matrix(x, nrow, ncol)`. * Reason for implementation: the `matrix` function is not generic in R, and I believe that the R implementation will have something like creation of a matrix, which is similar to the problem we have in `diagm`. * Current issue: should have some default value for arguments, and should have a way to repeat the vector as the behavior in R, arguments like `byrow` is also not accepted currently. * Examples: `function(x){a <- Jmatrix(x, length(x), 1); b <- Jmatrix(x, 1, length(x)); sum(log((1 + (a %m% b)) + a - b))}`

• Use array(x, c(nrow, ncol)) instead of matrix(x, nrow, ncol))

  • Reason: array is more friendly with generics than matrix.
  • Current issue: the current behavior doesn't match the behavior in R for things like scalar, and mode argument is ignored for now.
  • Examples: function(x){ a <- array(x, c(length(x), 1)) b <- array(x, c(1, length(x))) sum(log((1 + (a %m% b)) + a - b)) }

• zeros and ones instead of matrix(0, nrow, ncol) and matrix(1, nrow, ncol).

  • Similar to the above problem, has issues in matrix creation. The problem here is to create a matrix with the same type to the input, and it is quite obvious that matrix in R cannot create a julia matrix with the desired element type, which is quite a common practice in writing julia functions for the sake of automatic differentiation.
  • Current issue: only accept x as argument, should be able to accept more arguments to be really useful.
  • Examples: function(x){y <- zeros(x); y[1] <- x[1]; y[1] <- y[1] * x[2]; y[2] <- y[2] * x[3]; y[3] <- sum(y); y}

[Non-Contradiction]

I just found that array could be used instead of matrix, and it allows generic code to go in. So maybe array instead of Jmatrix.

[nashjc]

I wonder if we need to think of a pre-processor that will go through a code and look for the problem cases.
Eventually we might be able to "translate" automatically. I can see a work process like:

• develop preprocessor to identify troublesome constructs
• provide "suggested" changes for user to approve
• if the "suggestions" always work (or there are some that do always work), then those are done, possibly with highlighting, leaving only a few for the user to work around.