FWIW, my point about range is it relies on One being the number 1, rather than
being the multiplicative identity. AFAIK there's nothing special about 1 in a
ring outside of its status as a multiplicative identity. Certainly it's not
considered some special value for addition.
As an example as to why this usage is weird, range(0f32, 10f32) actually is
defined, and will produce [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]. Similarly,
range(0.5f32, 10f32) is defined and will produce [0.5, 1.5, 2.5, 3.5, 4.5, 5.5,
6.5, 7.5, 8.5, 9.5]. This is technically a mis-use of One, but it just happens
to produce reasonable values.
Of course, if you use it on, say, a 2x2 matrix that defines Add<Matrix,Matrix>,
defines One as {{1,0},{0,1}} (the multiplicative identity), and also has some
arbitrary definition of Ord, then range() would operate over this matrix and
produce very weird results. For example, range(matrix![[1,2],[3,4]],
matrix![10,10],[10,10]]) might, depending on the Ord definition, produce
[matrix![[1,2],[3,4]], matrix![[2,2],[3,5]], matrix![[3,2],[3,6]], ...]. You
can see that this is a nonsensical range (not that I think there is a way to
define range for matrices that makes any sense).
In any case, my overall point is Zero and One are more practical names than
AdditiveIdentity and MultiplicativeIdentity. If we wanted a proper, accurate
numeric hierarchy, we'd use the latter. But libstd wants a practical, shallow
hierarchy. And there's certainly nothing stopping you from defining a separate
libnumerics that provides an accurate mathematica numeric hierarchy (this is
probably something that would be useful to have, but libstd doesn't want it
because it's really easy to get wrong, e.g. I believe Haskell thinks their
numeric hierarchy was a mistake).
-Kevin
On Apr 9, 2014, at 2:10 PM, Eric Reed <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> wrote:
>
> >> On 09 Apr 2014, at 20:46, Kevin Ballard <[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
