[rust-dev] Division and modulo for signed numbers
eddycizeron at gmail.com
Wed Apr 24 11:02:20 PDT 2013
I'm a bit suprised by the suddenness of all these discussions. When I tried
to call the attention on this issue 4 month ago in a thread called
"Arithmetics and programming", apparently nobody cared :-p
> Moreover, it's not "just C and x86". This same choice is taken (more
> or less) by PowerPC, LLVM, C++, C#, Java, D, Go, JS, Scala, Ocaml,
> etc. etc.
Sorry Graydon, but I don't buy this argument. It's obvious to me that these
languages just followed the hardware choice because either they didn't
thought about the potential issue or they intentionally decided to focus on
performance. I mean that the fact these languages have T-division +
remainder is not an additional argument and that should not count when
considering if which option(s) Rust must have.
This said, I can understand that Rust also cares about performance or
compatibility with hardware and for that reasons want to keep T-division +
remainder as the main behaviour.
> The only remaining thing to struggle with is "which of the two
operation-pairs to assign the / and % symbols to", in the
> For this, we've gone with quot/rem, as in the other languages above, and
in keeping with the design preference above. You have to call .mod() or
.div() to get the other operators
My opinion (that nobody will follow, but I still give it) is that integers
should not have the "/" operator at all. This was one of the bad choices of
C (or maybe of a previous language).
> The floating point "quot" operator is now misnamed. It returns "D/d",
> which is a floating point divide, not a quotient.
> (src/libcore/num/f32.rs line 323)
Well, technically a quotient is always the result of a division. The
problem is that contrary to what the name suggests an euclidean division is
not a division.
> Then the floating-point "/" operator needs to be mapped to a something
> other than "quot" (maybe "div_float"?). The "%" operator can be removed
> on floating point numbers. When a floating-point remainder is needed,
> you would have to call rem() explicitly. The numeric traits do not
> appear to require a "%" operator (which is probably a good thing,
> because it is hard to define for complex numbers).
Right but in that case they shouldn't have a division either: for the
reason given above (integers have no notion of natural division)
2013/4/24 Diggory Hardy <lists at dhardy.name>
> On Tuesday 23 April 2013 10:46:15 Graydon Hoare wrote:
> > On 23/04/2013 8:53 AM, Diggory Hardy wrote:
> > > I suspect (please correct me if I'm wrong) that if it wasn't for C and
> > > compatibility then most people would fall into two categories: don't
> > > know/don't care, and prefer F-division. It's one of those little things
> > > like tau vs. pi which would have been less confusing if we'd started
> > > on the other foot to start with.
> > And IP addresses would have been 64 or 128bit from the start, there
> > would only be one endianness, and so forth ... yes, sure. But we don't
> > cast off the weight of the past so easily, and I do not think this is
> > something it's wise to fiddle with.
> > A very widely-applied design choice in rust is that the basic types are
> > machine-sized and the arithmetic operations on them are (as close as
> > reasonable to) machine operations. The machine operation is remainder.
> > Moreover, it's not "just C and x86". This same choice is taken (more or
> > less) by PowerPC, LLVM, C++, C#, Java, D, Go, JS, Scala, Ocaml, etc. etc.
> > The path we've taken here is to admit _two_ operation-pairs, div/mod and
> > quot/rem. This path is taken by several languages and specs (Scheme,
> > Common Lisp, Ruby, Smalltalk, SML, Prolog, Haskell, Ada, and ISO 10967
> > and IEEE 754). The work for this landed last week:
> > https://github.com/mozilla/rust/pull/5990
> > https://github.com/mozilla/rust/pull/6013
> > https://github.com/mozilla/rust/issues/4565
> > https://github.com/mozilla/rust/issues/4917
> > (Phew! This must really be the week for integer division!)
> > The only remaining thing to struggle with is "which of the two
> > operation-pairs to assign the / and % symbols to", in the
> > operator-overloading sense. For this, we've gone with quot/rem, as in
> > the other languages above, and in keeping with the design preference
> > above. You have to call .mod() or .div() to get the other operators.
> > It does mean there's a bit of a footgun surrounding the symbols / and %
> > specifically, on signed integer types. I would not be at all opposed to
> > adding a lint flag to calls-to-/-and-%-on-signed-integer-types, such
> > that you could trap them all. As with many things here, the design space
> > includes a variety of (sensible) preferences.
> Wow, what a big post! Sorry, looks like I've missed far too much of the
> discussion. (And I'm a little surprised at your patience!)
> I for one am happy so long as arr[ind.mod(z)] is possible (though
> arr[ind mod z] would be neater), and this is covered somewhere in the
> Rust-dev mailing list
> Rust-dev at mozilla.org
41 rue de l'Orillon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev