BigDecimal represents decimal floating-point numbers of arbitrary precision. By default, the precision approximately matches that of IEEE 128-bit floating point numbers (34 decimal digits, HALF_EVEN rounding mode). Within the range of IEEE binary128 numbers, BigDecimal will agree with BigInt for both equality and hash codes (and will agree with primitive types as well). Beyond that range--numbers with more than 4934 digits when written out in full--the hashCode of BigInt and BigDecimal is allowed to diverge due to difficulty in efficiently computing both the decimal representation in BigDecimal and the binary representation in BigInt.

When creating a BigDecimal from a Double or Float, care must be taken as the binary fraction representation of Double and Float does not easily convert into a decimal representation. Three explicit schemes are available for conversion. BigDecimal.decimal will convert the floating-point number to a decimal text representation, and build a BigDecimal based on that. BigDecimal.binary will expand the binary fraction to the requested or default precision. BigDecimal.exact will expand the binary fraction to the full number of digits, thus producing the exact decimal value corresponding to the binary fraction of that floating-point number. BigDecimal equality matches the decimal expansion of Double: BigDecimal.decimal(0.1) == 0.1. Note that since 0.1f != 0.1, the same is not true for Float. Instead, 0.1f == BigDecimal.decimal((0.1f).toDouble).

To test whether a BigDecimal number can be converted to a Double or Float and then back without loss of information by using one of these methods, test with isDecimalDouble, isBinaryDouble, or isExactDouble or the corresponding Float versions. Note that BigInt's isValidDouble will agree with isExactDouble, not the isDecimalDouble used by default.

BigDecimal uses the decimal representation of binary floating-point numbers to determine equality and hash codes. This yields different answers than conversion between Long and Double values, where the exact form is used. As always, since floating-point is a lossy representation, it is advisable to take care when assuming identity will be maintained across multiple conversions.

BigDecimal maintains a MathContext that determines the rounding that is applied to certain calculations. In most cases, the value of the BigDecimal is also rounded to the precision specified by the MathContext. To create a BigDecimal with a different precision than its MathContext, use new BigDecimal(new java.math.BigDecimal(...), mc). Rounding will be applied on those mathematical operations that can dramatically change the number of digits in a full representation, namely multiplication, division, and powers. The left-hand argument's MathContext always determines the degree of rounding, if any, and is the one propagated through arithmetic operations that do not apply rounding themselves.

A trait for representing equivalence relations. It is important to distinguish between a type that can be compared for equality or equivalence and a representation of equivalence on some type. This trait is for representing the latter.

An equivalence relation is a binary relation on a type. This relation is exposed as the equiv method of the Equiv trait. The relation must be:

reflexive: equiv(x, x) == true for any x of type T.symmetric: equiv(x, y) == equiv(y, x) for any x and y of type T.transitive: if equiv(x, y) == true and equiv(y, z) == true, then equiv(x, z) == true for any x, y, and z of type T.

A trait for data that have a single, natural ordering. See scala.math.Ordering before using this trait for more information about whether to use scala.math.Ordering instead.

Classes that implement this trait can be sorted with scala.util.Sorting and can be compared with standard comparison operators (e.g. > and <).

Ordered should be used for data with a single, natural ordering (like integers) while Ordering allows for multiple ordering implementations. An Ordering instance will be implicitly created if necessary.

scala.math.Ordering is an alternative to this trait that allows multiple orderings to be defined for the same type.

scala.math.PartiallyOrdered is an alternative to this trait for partially ordered data.

For example, create a simple class that implements Ordered and then sort it with scala.util.Sorting:

case class OrderedClass(n:Int) extends Ordered[OrderedClass] {
	def compare(that: OrderedClass) =  this.n - that.n
}

val x = Array(OrderedClass(1), OrderedClass(5), OrderedClass(3))
scala.util.Sorting.quickSort(x)
x

It is important that the equals method for an instance of Ordered[A] be consistent with the compare method. However, due to limitations inherent in the type erasure semantics, there is no reasonable way to provide a default implementation of equality for instances of Ordered[A]. Therefore, if you need to be able to use equality on an instance of Ordered[A] you must provide it yourself either when inheriting or instantiating.

It is important that the hashCode method for an instance of Ordered[A] be consistent with the compare method. However, it is not possible to provide a sensible default implementation. Therefore, if you need to be able compute the hash of an instance of Ordered[A] you must provide it yourself either when inheriting or instantiating.

Ordering is a trait whose instances each represent a strategy for sorting instances of a type.

Ordering's companion object defines many implicit objects to deal with subtypes of AnyVal (e.g. Int, Double), String, and others.

To sort instances by one or more member variables, you can take advantage of these built-in orderings using Ordering.by and Ordering.on:

import scala.util.Sorting
val pairs = Array(("a", 5, 2), ("c", 3, 1), ("b", 1, 3))

// sort by 2nd element
Sorting.quickSort(pairs)(Ordering.by[(String, Int, Int), Int](_._2))

// sort by the 3rd element, then 1st
Sorting.quickSort(pairs)(Ordering[(Int, String)].on(x => (x._3, x._1)))

An Ordering[T] is implemented by specifying compare(a:T, b:T), which decides how to order two instances a and b. Instances of Ordering[T] can be used by things like scala.util.Sorting to sort collections like Array[T].

For example:

import scala.util.Sorting

case class Person(name:String, age:Int)
val people = Array(Person("bob", 30), Person("ann", 32), Person("carl", 19))

// sort by age
object AgeOrdering extends Ordering[Person] {
  def compare(a:Person, b:Person) = a.age compare b.age
}
Sorting.quickSort(people)(AgeOrdering)

This trait and scala.math.Ordered both provide this same functionality, but in different ways. A type T can be given a single way to order itself by extending Ordered. Using Ordering, this same type may be sorted in many other ways. Ordered and Ordering both provide implicits allowing them to be used interchangeably.

You can import scala.math.Ordering.Implicits to gain access to other implicit orderings.

A trait for representing partial orderings. It is important to distinguish between a type that has a partial order and a representation of partial ordering on some type. This trait is for representing the latter.

A partial ordering is a binary relation on a type T, exposed as the lteq method of this trait. This relation must be:

reflexive: lteq(x, x) == true, for any x of type T.anti-symmetric: if lteq(x, y) == true and lteq(y, x) == true then equiv(x, y) == true, for any x and y of type T.transitive: if lteq(x, y) == true and lteq(y, z) == true then lteq(x, z) == true, for any x, y, and z of type T.

Additionally, a partial ordering induces an equivalence relation on a type T: x and y of type T are equivalent if and only if lteq(x, y) && lteq(y, x) == true. This equivalence relation is exposed as the equiv method, inherited from the Equiv trait.