Add getter for dim in Shape and StrideShape

[stokhos]

Code should compile. fixes#820

But there are 2 parts that I'm not sure.

1. (3,2).f() returns an instance that has the trait ShapeBuilder. I'm confused that it seems only Shape and StrideShape implemented ShapeBuilder. Why does (usize, usize) also have .f() method?
2. How can I test the StrideShape? The 'Stride' is entirely new to me. Can someone give me an example over this?

It looks like my vim formats the code automatically. Is that ok, or I have to follow the original format?

[bluss]

This looks good to me. Since we have some unfortunate naming around dimensions, these methods should probably be called raw_dim, that's the convention that the arrays use for now. ☹️. dimension or dim is clearly a better name, but it's hard to decide if convention or better name is the way to go. Change looks good to me of course, as soon as we know what name to use.

[bluss]

The .f() method comes from the IntoDimension blanket impl if I don't misremember. It's a strange feature, that we put some extra methods on tuples so that tuples can be shape builder values for us.

[stokhos]

This looks good to me. Since we have some unfortunate naming around dimensions, these methods should probably be called raw_dim, that's the convention that the arrays use for now. frowning_face. dimension or dim is clearly a better name, but it's hard to decide if convention or better name is the way to go. Change looks good to me of course, as soon as we know what name to use.

Do you have a plan for resolving the naming issue? Cause I feel this would be an great opportunity for me to learn the internals.

[bluss]

Resolving the name for arrays in general won't come until we remake dimensions for const generics (ndarray 0.16 or later).

Right now I'm wondering what you think about the naming. I could see either .dimension() or .raw_dim() being a good choice here.

[stokhos]

I have changed method name from dimension to raw_dim.

[stokhos]

Resolving the name for arrays in general won't come until we remake dimensions for const generics (ndarray 0.16 or later).

Right now I'm wondering what you think about the naming. I could see either .dimension() or .raw_dim() being a good choice here.

The reason I used dimension is it consistent with method size in below.

[bluss]

Thanks, looks good. I give up the naming, either would be fine, this is consistent (sadly).

[stokhos]

Thanks, looks good. I give up the naming, either would be fine, this is consistent (sadly).

So if we stick to convention, do we need to change size to raw_size? I'm incline toward conventional name. Cause this will save us more time to resolve name inconsistency when doing refactorization.

[jturner314]

I agree that raw_dim is the best name for now, for consistency with ArrayBase's methods. I think the size method should be named size, because that's what the similar method is named in the Dimension trait.

While we're at it, I'd like an is_f method on Shape for use with ndarray_npy::write_zeroed_npy, assuming @bluss agrees. (I'd like to reuse ndarray's ShapeBuilder stuff to allow the user to optionally specify that they'd like Fortran layout, like ArrayBase::zeros does.) I could create a separate issue/PR for that, but it seems closely enough related to this PR to include here.

[bluss]

The is_f method sounds fine - but it might as well be a separate PR, no need truly to pile-on an already good PR (so it's entirely voluntary 🙂 ). Note that the Shape/StrideShape things are due for redesign

[stokhos]

I'd like to work on the is_f if it is not urgent.

[bluss]

It is good to avoid extra formatting changes, but it's not so much of it here. Thanks for this.