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.
Package mathext provides functions that supplement the golang math library.
Package maths provides shared interfaces and functions across all packages in the maths module.
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 go3d is a performance oriented vector and matrix math package for 2D and 3D graphics. Every type has its own sub-package and is named T. So vec3.T is the 3D vector type. For every vector and matrix type there is a String() method and a Parse() function. Besides methods of T there are also functions in the packages, like vec3.Dot(a, b). Packages under the float64 directory are using float64 values instead of float32. Matrices are organized as arrays of columns which is also the way OpenGL expects matrices. DirectX expects "arrays of rows" matrices, use the Transpose() to convert. Methods that don't return a specific value, return a pointer to the struct to allow method call chaining. Example: Method names in the past tense return a copy of the struct instead of a pointer to it. Example: Documentation: http://godoc.org/github.com/ungerik/go3d
float32 math package. This library provides float32 counterparts for Go's float64 math functions. E.g.: The implementation partially uses assembly code (see, e.g., sqrtf_amd64.s) for fast computation. However, when no assembly implementation exists yet a generic implementation is used which uses Go's float64 math functions underneath. Note: the assembly code is not goinstallable on all platforms. Therefore, goinstall will compile the portable implementation. If you manually execute "make install", you will get the faster implementation.
Package mathutil provides utilities supplementing the standard 'math' and 'math/rand' packages. 2020-12-20 v1.2.1 fixes MulOverflowInt64. 2020-12-19 Added {Add,Sub,Mul}OverflowInt{8,16,32,64} 2018-10-21 Added BinaryLog 2018-04-25: New functions for determining 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
The chromath package provides math functions for common colorspace transformations including customizable RGB working space to XYZ transformations and commonly used CIE colorspaces including CIELAB, CIELUV, and their cylindrical coordinate counterparts. Addtionally it provides convenient and performant application of commonly used chromatic adaptation transforms. Most transformations are invoked on methods of transformer objects. A transformer receiver can therefore precompute certain aspects of the transform such as a combined chromatic adaptation and working space transform matrix.
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.
Package math provides basic constants and mathematical functions.
Package intmath provides a simple integer math library. The standard Go math library uses the float64 type for everything. This often requires casting both input and result, resulting in more verbose and (possibly) slower code. This library aims to extend the Go math library by providing math packages for the int, uint, int32, uint32, int64 and uint64 types. The intmath package itself is just a dummy package used for documentation, testing and benchmarking - the real library is in the subpackages. Import the relevant type to use math functions tailored to that type. Note that the dedicated FPU in your computer can be so fast that casting to and from float64 would be faster than using integer math. In other words, the standard math library can in theory outperform these libraries despite repeated casting to and from float64. Similarly, some code in u64 and i64 may be optimised to run faster on 32bit systems, at a minor cost for 64bit systems. All else being equal, the code in the library will favour this behaviour (see for example the u64.Log2 source). Benchmarks are included so you can easily test the differences for yourself. They assume a uniform distribution of input. Not all math functions will be copied, as not all of them make sense in an integer math context. At the moment, the following functions have been implemented: As a general rule, all functions take and return types matching the type of the library. Functions in u64 only take and return uint64, for example. Think of it as fake function overloading: the functions have the same name in every library, but the library name determines the type. Compare the following code snippets using the standard math library, a hypothetical library throwing all types in the same library, and this library: Note that the last example is the least verbose, yet it is immediately clear what the types of c, k and z are. If there ever will be exceptions to this general rule of input and return types the functions will be listed here and the reasoning behind making an exception will be explained in the documentation. As mentioned before, the speed of modern FPUs should not be underestimated. Benchmarking is advised to see if your system actually benefits form this library. To do this run go test: Some benchmarks also include alternate implementations for different functions. These might just be more effective on your architecture.