I think part of the confusion here is that "matrix addition" isn't actually a binary operator, but rather a family of binary operators parametrized over the matrix dimensions. There's +<2,2> for 2 x 2 matrices, +<2,3> for 2 x 3 matrices, etc. Similarly, the "zero matrix" is actually parametrized over dimensions. 0<2,2> is different from 0<2,3>. For any n,m: +<n,m> has the identity 0<n,m>. If we wanted to properly represent that in Rust, we would need type level naturals that we could parametrize Matrix over.
Regarding the range thing, I thought for a minute that it might make sense if we required Mul+One+Add+Zero to be a ring (which is the intention I think), but I don't think that's actually true in general for rings (i.e. that 1 is a generating set of the underlying group). On Wed, Apr 9, 2014 at 1:42 PM, Kevin Ballard <ke...@sb.org> wrote: > The number 0 is the additive identity for numbers. But informally, the > additive identity for other things can be called "zero" without problem. > Heck, even the wikipedia page on Additive Identity uses this example for > groups: > > > Let (G, +) be a group and let 0 and 0' in G both denote additive > identities, so for any g in G, > > > > 0 + g = g = g + 0 and 0' + g = g = g + 0' > > It follows from the above that > > > > (0') = (0') + 0 = 0' + (0) = (0) > > Look at that, an additive identity for something other than a number, and > zero (0) is used to denote this additive identity. > > The only issue comes in when you define addition in multiple different > ways for a single type. Of course, right now I believe compiler bugs > prevent you from actually using multiple implementations of Add<> with > different type parameters for a given type, so this isn't actually a > problem right now. And when that bug is fixed, it's still reasonable to > consider Zero to be the additive identity for any addition where the > receiver type is the right-hand side of the addition. In other words, if > you define Add<uint, Matrix> for Matrix, then the additive identity here is > Zero::<for uint>, not Zero::<for Matrix>. > > Regarding "You can't assign a zero to a 2x2 matrix", additive identity > does not require the ability to assign. And this is only a problem when > considering addition between disparate types. If you consider matrix > addition (e.g. 2x2 matrix + 2x2 matrix) then you certainly can assign the > additive identity back to one of the matrix values. > > let m: Matrix = Zero::zero(); > > looks fine to me. It produces a matrix m that, when added to any other > Matrix m', produces the same matrix m'. This is presumably a Matrix where > every element is 0. But again, this only makes sense if you've actually > defined Add<Matrix,Matrix> for Matrix. > > Regardless, we've already made the decision not to go down numeric type > hierarchy hell. We're trying to keep a reasonable simple numeric hierarchy. > And part of that means using straightforward "lay-person" terms instead of > perhaps more precise mathematical names. As such, we have std::num::Zero as > the additive identity and std::num::One as the multiplicative identity. > > If you really want to complain about something, complain about > std::num::One being used for things other than multiplicative identity, > e.g. std::iter::range() uses Add and One to produce the next value in the > range. > > -Kevin > > On Apr 9, 2014, at 1:25 PM, Tommi Tissari <rusty.ga...@icloud.com> wrote: > > >> On 09 Apr 2014, at 20:46, Kevin Ballard <ke...@sb.org> wrote: > >> > >> Why? Zero is the additive identity. > > > > Zero is _an_ additive identity for numbers, but not for vectors or > matrices. > > > > use std::slice::Items; > > use std::iter::RandomAccessIterator; > > use std::num::Zero; > > > > Items is a RandomAccessIterator, but a RandomAccessIterator is not an > Items. 0 is an additive identity, but an additive identity is not 0. You > can't assign a zero to a 2x2 matrix, and therefore this trait is > incorrectly named. The following just looks wrong: > > > > let m: Matrix = Zero::zero(); > > > >> AdditiveIdentity is the only reasonable alternative, but that's a > mouthful of a name and I think changing the name to this would be more > confusing. > > > > Naming a trait something that it's not is even more confusing. I don't > think we should give an incorrect name to this trait on the grounds of the > correct name being longer. Just look at RandomAccessIterator. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
