Package math implements custom Cosmos SDK math types used for arithmetic operations. Signed and unsigned integer types utilize Golang's standard library big integers types, having a maximum bit length of 256 bits.
This file creates type and function aliases the sdkmath.LegacyDec This is done for reducing verbosity and improving readability. For consistency, we also alias Int and Uint so that sdkmath does not have to be directly imported in files where both decimal and integer types are used.
Package uint256 implements highly optimized fixed precision unsigned 256-bit integer arithmetic. This example demonstrates calculating the result of dividing a max unsigned 256-bit integer by a max unsigned 128-bit integer and outputting that result in hex with leading zeros.
Package mathutil provides utilities supplementing the standard 'math' and 'math/rand' packages. 2018-10-21 Added BinaryLog 2018-04-25: New functions for determinig Max/Min of nullable values. Ex: 2017-10-14: New variadic functions for Max/Min. Ex: 2016-10-10: New functions QuadPolyDiscriminant and QuadPolyFactors. 2013-12-13: The following functions have been REMOVED 2013-05-13: The following functions are now DEPRECATED These functions will be REMOVED with Go release 1.1+1. 2013-01-21: The following functions have been REMOVED They are now replaced by untyped constants Additionally one more untyped constant was added This change breaks any existing code depending on the above removed functions. They should have not been published in the first place, that was unfortunate. Instead, defining such architecture and/or implementation specific integer limits and bit widths as untyped constants improves performance and allows for static dead code elimination if it depends on these values. Thanks to minux for pointing it out in the mail list (https://groups.google.com/d/msg/golang-nuts/tlPpLW6aJw8/NT3mpToH-a4J). 2012-12-12: The following functions will be DEPRECATED with Go release 1.0.3+1 and REMOVED with Go release 1.0.3+2, b/c of http://code.google.com/p/go/source/detail?r=954a79ee3ea8
Notes for the programmer: ------------------------- The underlying value describing an *Element will be an int64 when possible; otherwise it will be a *big.Int. You should attempt to gain the performance boost of using int64 versions of your computations when possible. Typical code will branch into two cases: Take care not to modify the *big.Int returned by x.bigInt(), as this will modify the corresponding *Element (thus breaking our contract of immutability). Similarly, do not allow this *big.Int to escape into user-land. The implementation attempts to guarantee that there is a unique 0 and 1 *Element element, returned via the functions Zero() and One(). However this isn't completely true: following good Go standard, a nil *Element behaves identically to 0. Furthermore, there's nothing stoping a user from writing: and thus creating a new, distinct 0. Care must be taken when adding new package functions: you should use the methods x.IsZero() and x.IsOne(). It's good practice to try to reuse Zero() and One(), rather than allowing additional copies of 0 or 1 to leak out of the package. The easiest way to ensure this is to use FromInt64(n) and fromBigIntAndReuse(n) to convert your working value into a *Element suitable for returning to the user. Performance-wise, the biggest issue is big.Int.Mul(x,y), when x and y are large. Here Magma vastly outperforms big.Int. A quick search on the web shows that there exist several different algorithms for computing x * y, with different performance characteristics that depend on the size of x and y. Implementing these different algorithms, and modifying big.Int so that it uses the appropriate algorithm in each case, is a clear future task.
Package math32 provides basic constants and mathematical functions for float32 types. At its core, it's mostly just a wrapper in form of float32(math.XXX). This applies to the following functions: Everything else is a float32 implementation. Implementation schedule is sporadic an uncertain. But eventually all functions will be replaced
Package datemath provides an expression language for relative dates based on Elasticsearch's date math. This package is useful for letting end-users describe dates in a simple format similar to Grafana and Kibana and for persisting them as relative dates. The expression starts with an anchor date, which can either be "now", or an ISO8601 date string ending with ||. This anchor date can optionally be followed by one or more date math expressions, for example: The supported time units are: This package aims to be a superset of Elasticsearch's expressions. That is, any datemath expression that is valid for Elasticsearch should evaluate in the same way here. In addition to the expressions supported by Elasticsearch, this package also supports business days, annual quarters, and fiscal years/quarters.
Package datemath provides an expression language for relative dates based on Elasticsearch's date math. This package is useful for letting end-users describe dates in a simple format similar to Grafana and Kibana and for persisting them as relative dates. The expression starts with an anchor date, which can either be "now", or an ISO8601 date string ending with ||. This anchor date can optionally be followed by one or more date math expressions, for example: The supported time units are: This package aims to be a superset of Elasticsearch's expressions. That is, any datemath expression that is valid for Elasticsearch should evaluate in the same way here. Currently the package does not support expressions outside of those also considered valid by Elasticsearch, but this may change in the future to include additional functionality.
Package math provides helper functions for mathematical operations over all integer Go types. Almost all files in this package are automatically generated. To regenerate this package This package relies on github.com/davecheney/godoc2md.