math.size and Matrix.size are inconsistent

The .size() method on matrices always returns number[]. The math.size(x) method, which should be more robust, can take not only Matrix instances, but also array matrices and scalars. For arrays it returns number[], but for matrices it returns an instance of Matrix.

let a = [ [1], [2] ]
let m = math.matrix(a)
math.size(a) // [1,2]
m.size() // [1,2]
math.size(m) // Matrix([1,2])

This is unexpected and useless. Size is usefull when one can read the dimensions rightaway, with matrix, you have to convert it to array first.

[josdejong]

I’ve been giving this a bit more thought. I think having size always return an Array is the more practical, pragmatic approach, and that this outweighs having consistent input -> output.

So let’s go for it and change size to always return an Array, schedule this for v7 ok?

[josdejong]

I already mentioned this inconvenience in my previous comment.

Ah, your’re right. Yes I had seen it coming too, but using it for real helps me weight the impact (for me and all current users with certain expectations). I’m sorry for the back-and-forth in this regard, but it still doesn’t feel “right” so I’m reluctant to make this change. I have the feeling that we’re going to mix the current API with a different type of API.

Instead of trying to work around the legacy API, I propose a new call signature for zeros, ones and identity in v7: […]

It’s an interesting idea to have zeros and ones become more “smart” and have them take the size of the input in case the input is a SparseMatrix or DenseMatrix. It doesn’t really appeal to me though, because of a couple of reasons:

• I like to have a simple, flat API. Having size do an extra interpretation step in certain cases make the function less transparent to me. I like that it is simply dimensions in -> Matrix out.
• In mathjs, a DenseMatrix can have any number of dimensions, 1-d, 2-d, n-d, etc. I find it important that the function behaves consistent for any type of matrix (Array, DenseMatrix, SparseMatrix). However, for 1-d Arrays the behavior would be different than 2-d or n-d Arrays in your proposal. So, zeros(denseMatrix) could behave differently than zeros(denseMatrix.toArray()).

The problem here is that zeros, ones and identity were designed with the old API in mind. They count on the fact that the size of a matrix also contains information about the type of the matrix. Which, to me, sounds like something that shouldn’t be true.

I think this touches the core of our different way of looking at the API. The API of mathjs is designed around the simple rule “data type in -> same data type out”. Such a rule gives predictability and makes it easy to use the library. The intention also is to use functions and no class methods (functional API). If you’re doing calculations with BigNumbers, the results are in BigNumbers and should not suddenly switch to numbers. When calculating with plain Array, you get plain Array out, and not a DenseMatrix. And when working with DenseMatrices, you get DenseMatrices out and not suddenly switch to low level Arrays.

It may be good to take a step back and first get the bigger picture clear. You have some interesting ideas and a different view on things than me which is always good. Here an open question to you: if you could start from scratch, what API would you come up with for mathjs? Would you like to replace the “data type in -> same data type out” API with something totally different, and if so what?