github.com/db47h/decimal (go): Package decimal implements arbitrary-precision decimal floating-point arithmetic.  The implementation is heavily based on big.Float and the API is identical to that of *big.Float with the exception of a few additional getters and setters, an FMA operation, and helper functions to support implementation of missing low-level Decimal functionality outside this package (see the math sub-package).  Howvever, and unlike big.Float, the mantissa of a decimal is stored in a little-endian Word slice as "declets" of 9 or 19 decimal digits per 32 or 64 bits Word. All arithmetic operations are performed directly in base 10**9 or 10**19 without conversion to/from binary.  The mantissa of a Decimal is always normalized, that is the most significant digit of the mantissa is always a non-zero digit and:  The bounds for a finite Dicimal x are:  As a consequence to points (1) and (2), and unlike in the IEEE-754 standard, a finite Decimal can only be a normal number (no subnormal numbers) and there is no Quantize operation.  The zero value for a Decimal corresponds to 0. Thus, new values can be declared in the usual ways and denote 0 without further initialization:  Alternatively, new Decimal values can be allocated and initialized with the function:  NewDecimal(x, exp) returns a *Decimal set to the value of x×10**exp. More flexibility is provided with explicit setters, for instance:  Setters, numeric operations and predicates are represented as methods of the form:  For unary and binary operations, the result is the receiver (usually named z in that case; see below); if it is one of the operands x or y it may be safely overwritten (and its memory reused).  Arithmetic expressions are typically written as a sequence of individual method calls, with each call corresponding to an operation. The receiver denotes the result and the method arguments are the operation's operands. For instance, given three *Decimal values a, b and c, the invocation  computes the sum a + b and stores the result in c, overwriting whatever value was held in c before. Unless specified otherwise, operations permit aliasing of parameters, so it is perfectly ok to write  to accumulate values x in a sum.  (By always passing in a result value via the receiver, memory use can be much better controlled. Instead of having to allocate new memory for each result, an operation can reuse the space allocated for the result value, and overwrite that value with the new result in the process.)  Notational convention: Incoming method parameters (including the receiver) are named consistently in the API to clarify their use. Incoming operands are usually named x, y, a, b, and so on, but never z. A parameter specifying the result is named z (typically the receiver).  For instance, the arguments for (*Decimal).Add are named x and y, and because the receiver specifies the result destination, it is called z:  Methods of this form typically return the incoming receiver as well, to enable simple call chaining.  Methods which don't require a result value to be passed in (for instance, Decimal.Sign), simply return the result. In this case, the receiver is typically the first operand, named x:  Various methods support conversions between strings and corresponding numeric values, and vice versa: Decimal implements the Stringer interface for a (default) string representation of the value, but also provides SetString methods to initialize a Decimal value from a string in a variety of supported formats (see the SetString documentation).  Finally, *Decimal satisfies the fmt package's Scanner interface for scanning and the Formatter interface for formatted printing.
Keywords: arbitrary-precision|bignum|decimal|financial|floating-point|go