Skip to content
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

Possible: Rename dimensionality to size #12

Closed
ejackson opened this issue Jan 12, 2013 · 9 comments
Closed

Possible: Rename dimensionality to size #12

ejackson opened this issue Jan 12, 2013 · 9 comments

Comments

@ejackson
Copy link
Collaborator

This is a more common name, and shorter ! Rename it ?

https://github.com/mikera/matrix-api/blob/master/src/main/clojure/core/matrix.clj#L78

@mikera
Copy link
Owner

mikera commented Jan 12, 2013

Do you mean dimensionality or dimensions?

For a 3x3 matrix, dimensionality is 2 (it's a 2D matrix) and dimensions are [3 3]

Apart from that I like the word size in principle but the only main I was cautious about size was ambiguity: it might get confused with the total number of items in the matrix. That it what it means in NumPy at least.....

Any examples of what other matrix libraries use?

@ejackson
Copy link
Collaborator Author

Sorry, yes, I mean dimensions. For this R uses dim, MATLAB uses size, mathematica uses Dimensions. So no consensus there :)

For the total number of elements matlab provides numel (i think its a bit ugly). How about count, or card ?

@mjwillson
Copy link
Collaborator

numpy uses "ndim" for the number of array dimensions, and "shape" for the tuple of sizes along those dimensions.

It also uses the term "axis" a lot in its API for a specific dimension of an ndarray

@mikera
Copy link
Owner

mikera commented Jan 13, 2013

I quite like "shape" as an alternative to "dimensions"

ecount might be good as a reasonably concise term for the total number of elements - it would be consistent with ereduce, emap etc, for the other element-by-element operations.

ndim feels unidiomatic to me in Clojure for some reason. Though I recognise I have a general bias against use of abbreviations....

@ejackson
Copy link
Collaborator Author

Yes, shape is nice, sounds like quorum to me :)

ecount I think is a problem. The e_verb_ convention is to apply verb to each element of the matrix, thus wouldn't ecount imply: apply the function count to each element ? The count we want is not an elementwise op, but a collectionwise op. Admittedly, this might be inferring too much from the convention.

I still think count or card are better.

@mikera
Copy link
Owner

mikera commented Jan 13, 2013

OK sounds agreed dimensions -> shape

OTOH I don't think e*verb* does currently mean apply *verb* to each element at present - ereduce for example isn't applying reduce to each element, it is applying reduce to a hypothetical sequence of all elements. Likewise for emap. e+ works as shorthand for emap + in this sense.

ecount would be consistent with that, the sense that (count seq) returns the count of all elements in a seq.

Without having a specific formal definition in mind, I was interpreting e_something_ as "version of something that works over the array seen as a collection of elements". Rather like areduce for Java arrays in clojure.core. I imagine clojure.core would have acount as well were it not for the fact that count already works fine on Java arrays.

This is good discussion though - let's keep pushing this, naming is so important for any API.

@mikera
Copy link
Owner

mikera commented Jan 13, 2013

Anyone want to do a patch for dimensions -> shape?

Happy to do it myself, but I'm conscious that other people may want to get involved with hacking the API and this is probably a good one to start with.....

@ejackson
Copy link
Collaborator Author

e_verb_. I see your point. I need to think about this a bit.

@mikera
Copy link
Owner

mikera commented Jan 25, 2013

Seems like we can close this one.

@mikera mikera closed this as completed Jan 25, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants