Default impl?

[jgarvin]

It would be convenient if mint::Vector2::default() worked (giving zeros) so my own structs could #[derive(Default)].

[kvark]

See https://github.com/kvark/mint/pull/38#issuecomment-638497211

TL;DR: implementing this is possible for some but not the others. So we can't universally provide Default, and therefore we should consider not providing it at all.

[jgarvin]

I'm not sure I understand. I think the default at least for Vector and Matrix is obvious: fill the container with T::default(). If T doesn't implement default, then Vector and Matrix shouldn't, but as I understand it this will be the automatic behavior of derive(Default) anyway:

https://stackoverflow.com/a/48045960/50385

On Tue, Jul 28, 2020, 9:45 AM Dzmitry Malyshau notifications@github.com wrote:

See #38 (comment) https://github.com/kvark/mint/pull/38#issuecomment-638497211

TL;DR: implementing this is possible for some but not the others. So we can't universally provide Default, and therefore we should consider not providing it at all.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kvark/mint/issues/58#issuecomment-665083322, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAY7MSEAQFOEWG6UWBJ7YLR53P7XANCNFSM4PKDHSWA .

[kvark]

I disagree that impl Default for Matrix is obvious to be all-zeroes (filled with T::default()). If I see that a matrix type in a math library implements default, I'll first think about an identity matrix.

[jgarvin]

That would be inconsistent with i32::default() and the like. Pretty sure in every math context in the standard library default is a null element, never an identity element.

On Tue, Jul 28, 2020, 8:02 PM Dzmitry Malyshau notifications@github.com wrote:

I disagree that impl Default for Matrix is obvious to be all-zeroes (filled with T::default()). If I see that a matrix type in a math library implements default, I'll first think about an identity matrix.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kvark/mint/issues/58#issuecomment-665370695, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAY7MVZGSCSYCMNPNTBVWTR55YJRANCNFSM4PKDHSWA .

[kvark]

(thank you for bearing with me on this question!)

The standard library doesn't have math vectors and matrices, so it hardly sets up an example here. If we look at default implementations in the math libraries, they appear to be all over the place:

• cgmath: no default
• nalgebra: there is some default, but it's really hard to see what it does. Likely just fills with T::default() like you suggest
• glam: identity default
• ultraviolet: identity

And that's the reason why I'm hesitating to add anything to mint. The expectations are unclear.

[kvark]

Having dog-fooded mint in my projects extensively, I find it unfortunate to not have defaults for at least vectors. It's just convenient when putting into larger types that can be defaulted. And for vectors, in most situations zeroes is a perfectly reasonable choice. As an example, in Blade config's positions and rotations.

Now, it would be good to have a consistent policy for implementing defaults. I'd argue that initializing quaternions and matrices with "identity" poses the minimal surprise factor for all the users. If the user code expects an identity, they get it. If they don't expect anything useful (e.g. all zeroes), the identity isn't going to screw them over.

To re-iterate on this line of thought:

1. I believe having some defaults would improve the usability of the library.
2. The "identity" default does imply a specific operation (like multiplication for matrices, and addition for vectors), but this is applicable in most cases.
3. In the spirit of "perfect is the enemy of the good" we should add the defaults.

[Ralith]

For comparison, nalgebra's default is zeroes for matrices, vectors, and general quaternions, and the identity rotation for UnitQuaternion. I agree that having some default, even a completely arbitrary one, is helpful.

There doesn't seem to be a drawback to going with identity for square matrixes, but what should non-square matrices have?

[jgarvin]

I still think zeroes is the most natural choice in a programming context:

• It's consistent with numeric scalar types. If a 1x1 i32 matrix defaults to 1, but a scalar i32 defaults to 0, that feels inconsistent.
• It's the behavior you get with container types like Vec<i32> if you resize to larger than the current size. Vectors and Matrices from programmer POV are container-like.
• It's the default state of mmapped memory. From programmer POV matrix can also be thought of as a large memory block.

[kvark]

I'm not keen on the argument that matrices should be naturally analogous to scalars or Vec<i32>. In terms of game development, matrices have very concrete applicability, and they imply multiplication. mint is meant for this - it's not exposing arbitrary matrix dimensions but only those that are practically used for games and visualizations.

Is there a concern with going for identity-ish non-square matrices? E.g.

1 0 0 0
0 1 0 0
0 0 1 0

and

1 0 0
0 1 0
0 0 1
0 0 0

Basically, treat them as parts of a bigger square matrix for cases where the remainder is well known and doesn't need to be stored.

[jgarvin]

Adding and subtracting matrices is also a typical matrix operation, and there 0 is a sane default. Also it avoids needing a separate solution for non-square.

[Ralith]

Is there a concern with going for identity-ish non-square matrices?

I suppose the non-square matrixes you generally see in games/graphics are truncations of homogeneous matrices or their transpose, for which that makes perfect sense. Certainly holds for most of what I've done.

Adding and subtracting matrices is also a typical matrix operation

Not in linear algebra for computer graphics, I don't think.