Mathematics

Package convert is a collection of mathematical conversion functions. The conversion functions are organized into the sub packages radial and nautical. Convert aims to be a well organized collection of math conversion functions. If you have suggestions or updates contributes are welcome.

Package dec is a Go wrapper around the decNumber library (arbitrary precision decimal arithmetic). For more information about the decNumber library, and detailed documentation, see http://speleotrove.com/decimal/dec.html It implements the General Decimal Arithmetic Specification in ANSI C. This specification defines a decimal arithmetic which meets the requirements of commercial, financial, and human-oriented applications. It also matches the decimal arithmetic in the IEEE 754 Standard for Floating Point Arithmetic. The library fully implements the specification, and hence supports integer, fixed-point, and floating-point decimal numbers directly, including infinite, NaN (Not a Number), and subnormal values. Both arbitrary-precision and fixed-size representations are supported. General usage notes: The Number format is optimized for efficient processing of relatively short numbers; It does, however, support arbitrary precision (up to 999,999,999 digits) and arbitrary exponent range (Emax in the range 0 through 999,999,999 and Emin in the range -999,999,999 through 0). Mathematical functions (for example Exp()) as identified below are restricted more tightly: digits, emax, and -emin in the context must be <= MaxMath (999999), and their operand(s) must be within these bounds. Logical functions are further restricted; their operands must be finite, positive, have an exponent of zero, and all digits must be either 0 or 1. The result will only contain digits which are 0 or 1 (and will have exponent=0 and a sign of 0). Operands to operator functions are never modified unless they are also specified to be the result number (which is always permitted). Other than that case, operands must not overlap. Go implementation details: The decimal32, decimal64 and decimal128 types are merged into Single, Double and Quad, respectively. Contexts are created with a immutable precision (i.e. number of digits). If one needs to change precision on the fly, discard the existing context and create a new one with the required precision. From a programming standpoint, any initialized Number is a valid operand in arithmetic operations, regardless of the settings or existence of its creator Context (not to be confused with having a valid value in a given arithmetic operation). Arithmetic functions are Number methods. The value of the receiver of the method will be set to the result of the operation. For example: Arithmetic methods always return the receiver in order to allow chain calling: Using the same Number as operand and result, like in n.Multiply(n, n, ctx), is legal and will not produce unexpected results. A few functions like the context status manipulation functions have been moved to their own type (Status). The C call decContextTestStatus(ctx, mask) is therefore replaced by ctx.Status().Set(mask) in the Go implementation. The same goes for decNumberClassToString(number) which is repleaced by number.Class().String() in go. Error handling: although most arithmetic functions can cause errors, the standard Go error handling is not used in its idiomatic form. That is, arithmetic functions do not return errors. Instead, the type of the error is ORed into the status flags in the current context (Context type). It is the responsibility of the caller to clear the status flags as required. The result of any routine which returns a number will always be a valid number (which may be a special value, such as an Infinity or NaN). This permits the use of much fewer error checks; a single check for a whole computation is often enough. To check for errors, get the Context's status with the Status() function (see the Status type), or use the Context's ErrorStatus() function. The package provides facilities for managing free-lists of Numbers in order to relieve pressure on the garbage collector in computation intensive applications. NumberPool is in fact a simple wrapper around a *Context and a sync.Pool (or the lighter util.Pool provided in the util subpackage); NumberPool will automatically cast the return value of Get() to the desired type. For example: Note the use of pool.Context on the last statement. If a particular implementation needs always-initialized numbers (like any new Go variable being initialize to the 0 value of its type), the pool's New function can be set for example to: If an application needs to change its arithmetic precision on the fly, any NumberPool built on top of the affected Context's will need to be discarded and recreated along with the Context. This will not affect existing numbers that can still be used as valid operands in arithmetic functions. Go re-implementation of decNumber's example1.c - simple addition. Cnvert the first two argument words to decNumber, add them together, and display the result. Extended re-implementation of decNumber's example2.c - compound interest. With added error handling from example3.c. Go re-implementation of decNumber's example5.c. Compressed formats. Go re-implementation of decNumber's example6.c. Packed Decimal numbers. This example reworks Example 2, starting and ending with Packed Decimal numbers. Go re-implementation of decNumber's example7.c. Using decQuad to add two numbers together. Go re-implementation of decNumber's example8.c. Using Quad with Number

Package dec is a Go wrapper around the decNumber library (arbitrary precision decimal arithmetic). For more information about the decNumber library, and detailed documentation, see http://speleotrove.com/decimal/dec.html It implements the General Decimal Arithmetic Specification in ANSI C. This specification defines a decimal arithmetic which meets the requirements of commercial, financial, and human-oriented applications. It also matches the decimal arithmetic in the IEEE 754 Standard for Floating Point Arithmetic. The library fully implements the specification, and hence supports integer, fixed-point, and floating-point decimal numbers directly, including infinite, NaN (Not a Number), and subnormal values. Both arbitrary-precision and fixed-size representations are supported. General usage notes: The Number format is optimized for efficient processing of relatively short numbers; It does, however, support arbitrary precision (up to 999,999,999 digits) and arbitrary exponent range (Emax in the range 0 through 999,999,999 and Emin in the range -999,999,999 through 0). Mathematical functions (for example Exp()) as identified below are restricted more tightly: digits, emax, and -emin in the context must be <= MaxMath (999999), and their operand(s) must be within these bounds. Logical functions are further restricted; their operands must be finite, positive, have an exponent of zero, and all digits must be either 0 or 1. The result will only contain digits which are 0 or 1 (and will have exponent=0 and a sign of 0). Operands to operator functions are never modified unless they are also specified to be the result number (which is always permitted). Other than that case, operands must not overlap. Go implementation details: The decimal32, decimal64 and decimal128 types are merged into Single, Double and Quad, respectively. Contexts are created with a immutable precision (i.e. number of digits). If one needs to change precision on the fly, discard the existing context and create a new one with the required precision. From a programming standpoint, any initialized Number is a valid operand in arithmetic operations, regardless of the settings or existence of its creator Context (not to be confused with having a valid value in a given arithmetic operation). Arithmetic functions are Number methods. The value of the receiver of the method will be set to the result of the operation. For example: Arithmetic methods always return the receiver in order to allow chain calling: Using the same Number as operand and result, like in n.Multiply(n, n, ctx), is legal and will not produce unexpected results. A few functions like the context status manipulation functions have been moved to their own type (Status). The C call decContextTestStatus(ctx, mask) is therefore replaced by ctx.Status().Set(mask) in the Go implementation. The same goes for decNumberClassToString(number) which is repleaced by number.Class().String() in go. Error handling: although most arithmetic functions can cause errors, the standard Go error handling is not used in its idiomatic form. That is, arithmetic functions do not return errors. Instead, the type of the error is ORed into the status flags in the current context (Context type). It is the responsibility of the caller to clear the status flags as required. The result of any routine which returns a number will always be a valid number (which may be a special value, such as an Infinity or NaN). This permits the use of much fewer error checks; a single check for a whole computation is often enough. To check for errors, get the Context's status with the Status() function (see the Status type), or use the Context's ErrorStatus() function. The package provides facilities for managing free-lists of Numbers in order to relieve pressure on the garbage collector in computation intensive applications. NumberPool is in fact a simple wrapper around a *Context and a sync.Pool (or the lighter util.Pool provided in the util subpackage); NumberPool will automatically cast the return value of Get() to the desired type. For example: Note the use of pool.Context on the last statement. If a particular implementation needs always-initialized numbers (like any new Go variable being initialize to the 0 value of its type), the pool's New function can be set for example to: If an application needs to change its arithmetic precision on the fly, any NumberPool built on top of the affected Context's will need to be discarded and recreated along with the Context. This will not affect existing numbers that can still be used as valid operands in arithmetic functions. Go re-implementation of decNumber's example1.c - simple addition. Cnvert the first two argument words to decNumber, add them together, and display the result. Extended re-implementation of decNumber's example2.c - compound interest. With added error handling from example3.c. Go re-implementation of decNumber's example5.c. Compressed formats. Go re-implementation of decNumber's example6.c. Packed Decimal numbers. This example reworks Example 2, starting and ending with Packed Decimal numbers. Go re-implementation of decNumber's example7.c. Using decQuad to add two numbers together. Go re-implementation of decNumber's example8.c. Using Quad with Number

Package provides advanced mathematical functions and tools. Functions that start with "Bit" use bit operations ( hacks ) OR, AND, XOR

Package srp Secure Remote Password protocol The principal interface provided by this package is the SRP type. The end aim of the caller is to to have an SRP server and SRP client arrive at the same key. See the documentation for the SRP structure and its methods for the nitty gritty of use. BUG(jpg): This does not use the same padding and hashing scheme as in RFC 5054, and therefore is not interoperable with those clients and servers. Perhaps someday we'll add an RFC 5054 mode that does that, but today is not that day. It would be nice if this package could be used without having some understanding of the SRP protocol, but too much of the language and naming depends on at least some familiarity. Here is a summary. The Secure Remote Password protocol involves a server and a client proving to each other that they know (or can derive) their long term secrets. The client's long term secret is known as "x" and the corresponding server secret, the verifier, is known as "v". The verifier is mathematically related to x and is computed by the client on first enrollment and transmitted to the server. Typically the server will store the verifier and the client will derive x from a user secret such as a password. Because the verifier can used like a password hash with respect to cracking, the derivation of x should be designed to resist password cracking if the verifier is compromised. The client and the server must both use the same Diffie-Hellman group to perform their computations. The server and the client each send an ephemeral public key to each other. (The client sends A; the server sends B.) With their private knowledge of their own ephemeral secrets (a or b) and their private knowledge of x (for the client) and v (for the server) along with public knowledge they are able to prove to each other that they know their respective secrets and can generate a session key, K, which may be used for further encryption during the session. Quoting from http://srp.stanford.edu/design.html (with some modification for KDF and and checks) This package does not address the actual communication between client and server. But through the SRP type it not only performs the calculations needed, it also performs safety and sanity checks on its input, and it hides everything from the caller except what the caller absolutely needs to provide. The key derivation function, KDF() 1. Both client and server: Checking whether methods have returned without error. This is particularly true of SRP.Key() and SetOthersPublic() 2. Client: Using an appropriate key derivation function for deriving x from the user's password (and nudging user toward a good password) 3. Server: Storing the v securely (sent by the client on first enrollment). A captured v can be used to impersonate the server. The verifier, v, can also be used like a password hash in a password cracking attempt 4. Both: Proving to each other that both have the same key. The package includes methods that can assist with that. ExampleServerClientKey is an example.

Tensors is a package designed for facilitating the use of many-dimensional mathematical tensors. Tensors is designed for its primary use case in github.com/sharnoff/badstudent, but is open to improvement. The main unit of this package is the Interpreter, which will suffice for most use cases. Additionally, many methods have two other, 'Safe' and 'Fast' variants, which offer increased or decreased error checking respectively. Much of this is quite self-explanatory -- the only relevant information is that, even though the package is named tensors, the fundamental unit is the Interpreter. Interpreters do the job of handling interactions with tensors; they 'interpret' individual and sets of indices to convert between them.

Package decimal provides a high-performance, arbitrary precision, floating-point decimal library. This package provides floating-point decimal numbers, useful for financial programming or calculations where a larger, more accurate representation of a number is required. In addition to basic arithmetic operations (addition, subtraction, multiplication, and division) this package offers various mathematical functions, including the exponential function, various logarithms, and the ability to compute continued fractions. While lean, this package is full of features. It implements interfaces like “fmt.Formatter” and intuitively utilizes verbs and flags as described in the “fmt” package. (Also included: “fmt.Scanner”, “fmt.Stringer”, “encoding.TextUnmarshaler”, and “encoding.TextMarshaler”.) It allows users to specific explicit contexts for arithmetic operations, but doesn't require it. It provides access to NaN payloads and is more lenient when parsing a decimal from a string than the GDA specification requires. API interfaces have been changed slightly to work more seamlessly with existing Go programs. For example, many “Quantize” implementations require a decimal as both the receiver and argument which isn't very user friendly. Instead, this library accepts a simple “int” which can be derived from an existing decimal if required. It contains two modes of operation designed to make transitioning to various GDA "quirks" (like always rounding lossless operations) easier. There are three primary goals of this library: By adhering to the General Decimal Arithmetic specification, this package has a well-defined structure for its arithmetic operations. Decimal libraries are inherently slow; this library works diligently to minimize memory allocations and utilize efficient algorithms. Performance regularly benchmarks as fast or faster than many other popular decimal libraries. Libraries should be intuitive and work out of the box without having to configure too many settings; however, precise settings should still be available. The following type is supported: The zero value for a Big corresponds with 0, meaning all the following are valid: Method naming is the same as math/big's, meaning: In general, its conventions mirror math/big's. It is suggested to read the math/big package comments to gain an understanding of this package's conventions. Arguments to Binary and Unary methods are allowed to alias, so the following is valid: Unless otherwise specified, the only argument that will be modified is the result (“z”). This means the following is valid and race-free: But this is not:

Package srp Secure Remote Password protocol The principle interface provided by this package is the SRP type. The end aim of the caller is to to have an SRP server and SRP client arrive at the same Key. See the documentation for the SRP structure and its methods for the nitty gritty of use. BUG(jpg): This does not use the same padding and hashing scheme as in RFC 5054, and therefore is not interoperable with those clients and servers. Perhaps someday we'll add an RFC 5054 mode that does that, but today is not that day. It would be nice if this package could be used without having some understanding of the SRP protocol, but too much of the language and naming is depends on at least some familiarity. Here is a summary. The Secure Remote Password protocol involves a server and a client proving to each other that they know (or can derive) their long term secrets. The client long term secret is known as "x" and the corresponding server secret, the verifier, is known as "v". The verifier is mathematically related to x and is computed by the client on first enrollment and transmistted to the server. Typically the server will store the verifier and the client will derive x from a user secret such as a password. Because the verifier can used like a password hash with respect to cracking, the derivation of x should be designed to resist password cracking if the verifier compromised. The client and the server must both use the same Diffie-Hellman group to perform their computations. The server and the client each send an ephemeral public key to each other (The client sends A; the server sends B) With their private knowledge of their own ephemeral secrets (a or b) and their private knowledge of x (for the client) and v (for the server) along with public knowledge they are able to prove to each other that they know their respective secrets and can generate a session key, K, which may be used for further encryption during the session. Quoting from http://srp.stanford.edu/design.html (with some modification for KDF) This package does not address the actual communication between client and server. But through the SRP type it not only performs the calculations needed, it also performs safety and sanity checks on its input, and it hides everything from the caller except what the caller absolutely needs to provide. The key derivation function, KDF() 1. Both client and server: Checking whether methods have returned without error. This is particularly true of SRP.Key() and SetOthersPublic() 2. Client: Using an appropriate key derivation function for deriving x from the user's password (and nudging user toward a good password) 3. Server: Storing the v (send by the client on first enrollment) securely. A captured v can be used to masquerade as the server and be used like a password hash in a password cracking attempt 4. Both: Proving to each other that both have the same key. The package includes methods that can assist with that. ExampleServerClientKey is an example

Package avcodec contains the codecs (decoders and encoders) provided by the libavcodec library Provides some generic global options, which can be set on all the encoders and decoders. Package avfilter contains methods that deal with ffmpeg filters filters in the same linear chain are separated by commas, and distinct linear chains of filters are separated by semicolons. FFmpeg is enabled through the "C" libavfilter library Package avformat provides some generic global options, which can be set on all the muxers and demuxers. In addition each muxer or demuxer may support so-called private options, which are specific for that component. Supported formats (muxers and demuxers) provided by the libavformat library Use of this source code is governed by a MIT license that can be found in the LICENSE file. Giorgis (habtom@giorgis.io) Package avutil is a utility library to aid portable multimedia programming. It contains safe portable string functions, random number generators, data structures, additional mathematics functions, cryptography and multimedia related functionality. Some generic features and utilities provided by the libavutil library Package avformat provides some generic global options, which can be set on all the muxers and demuxers. In addition each muxer or demuxer may support so-called private options, which are specific for that component. Supported formats (muxers and demuxers) provided by the libavformat library Package avutil is a utility library to aid portable multimedia programming. It contains safe portable string functions, random number generators, data structures, additional mathematics functions, cryptography and multimedia related functionality. Some generic features and utilities provided by the libavutil library Package avutil is a utility library to aid portable multimedia programming. It contains safe portable string functions, random number generators, data structures, additional mathematics functions, cryptography and multimedia related functionality. Some generic features and utilities provided by the libavutil library Package avformat provides some generic global options, which can be set on all the muxers and demuxers. In addition each muxer or demuxer may support so-called private options, which are specific for that component. Supported formats (muxers and demuxers) provided by the libavformat library Package avcodec contains the codecs (decoders and encoders) provided by the libavcodec library Provides some generic global options, which can be set on all the encoders and decoders. Package avcodec contains the codecs (decoders and encoders) provided by the libavcodec library Provides some generic global options, which can be set on all the encoders and decoders. Package swresample provides a high-level interface to the libswresample library audio resampling utilities The process of changing the sampling rate of a discrete signal to obtain a new discrete representation of the underlying continuous signal. Package swscale performs highly optimized image scaling and colorspace and pixel format conversion operations. Rescaling: is the process of changing the video size. Several rescaling options and algorithms are available. Pixel format conversion: is the process of converting the image format and colorspace of the image.

Package goav contains the codecs (decoders and encoders) provided by the libavcodec library Provides some generic global options, which can be set on all the encoders and decoders. Package goav deals with the input and output devices provided by the libavdevice library The libavdevice library provides the same interface as libavformat. Namely, an input device is considered like a demuxer, and an output device like a muxer, and the interface and generic device options are the same provided by libavformat Package goav contains methods that deal with ffmpeg filters filters in the same linear chain are separated by commas, and distinct linear chains of filters are separated by semicolons. FFmpeg is enabled through the "C" libavfilter library Package goav provides some generic global options, which can be set on all the muxers and demuxers. In addition each muxer or demuxer may support so-called private options, which are specific for that component. Supported formats (muxers and demuxers) provided by the libavformat library Package goav ... Use of this source code is governed by a MIT license that can be found in the LICENSE file. Giorgis (habtom@giorgis.io) Package goav is a utility library to aid portable multimedia programming. It contains safe portable string functions, random number generators, data structures, additional mathematics functions, cryptography and multimedia related functionality. Some generic features and utilities provided by the libavutil library Package goav provides some generic global options, which can be set on all the muxers and demuxers. In addition each muxer or demuxer may support so-called private options, which are specific for that component. Supported formats (muxers and demuxers) provided by the libavformat library Package goav is a utility library to aid portable multimedia programming. It contains safe portable string functions, random number generators, data structures, additional mathematics functions, cryptography and multimedia related functionality. Some generic features and utilities provided by the libavutil library Package goav is a utility library to aid portable multimedia programming. It contains safe portable string functions, random number generators, data structures, additional mathematics functions, cryptography and multimedia related functionality. Some generic features and utilities provided by the libavutil library Package goav contains golang binding for FFmpeg. A comprehensive binding to the ffmpeg video/audio manipulation library: https://www.ffmpeg.org/ Contains: Package goav contains the codecs (decoders and encoders) provided by the libavcodec library Provides some generic global options, which can be set on all the encoders and decoders. Package goav contains the codecs (decoders and encoders) provided by the libavcodec library Provides some generic global options, which can be set on all the encoders and decoders. Package goav provides a high-level interface to the libswresample library audio resampling utilities The process of changing the sampling rate of a discrete signal to obtain a new discrete representation of the underlying continuous signal. Package goav performs highly optimized image scaling and colorspace and pixel format conversion operations. Rescaling: is the process of changing the video size. Several rescaling options and algorithms are available. Pixel format conversion: is the process of converting the image format and colorspace of the image.

Package geo contains a collection of 2-D types and other mathematical functions geared towards games. Includes This package assumes coordinates where +x is right and +y is down.

histogram_sketch is an implementation of the Histogram Sketch data structure described in Ben-Haim and Tom-Tov's "A Streaming Parallel Decision Tree Algorithm" in Journal of Machine Learning Research 11 (http://www.jmlr.org/papers/volume11/ben-haim10a/ben-haim10a.pdf). Modifications from Ben-Haim and Tom-Tov's original description in this implementation include: Adaptation of the "Uniform" function described in the paper into a "Quantile" function here. Allowing initial set of centroids to be bootstrapped with the optimal 1-D centroid decomposition based on squared distance to centroid mean via dynamic programming (see Bellman's "A note on cluster analysis and dynamic programming" in Mathematical Biosciences, 18(3-4):311 – 312, 1973 or Haizhou Wang and Mingzhou Song's "Ckmeans.1d.dp: Optimal k-means clustering in one dimension by dynamic programming" in R Journal, 3(2), 2011 (http://journal.r-project.org/archive/2011-2/RJournal_2011-2_Wang+Song.pdf) Storing the min and max value for better estimation of extreme quantiles. Returning exact values for Sum and Quantile when they're known (before any centroid merging happens). Improvements in handling some boundary conditions.

Package z3 checks the satisfiability of logical formulas. This package provides bindings for the Z3 SMT solver (https://github.com/Z3Prover/z3). Z3 checks satisfiability of logical formulas over a wide range of terms, including booleans, integers, reals, bit-vectors, and uninterpreted functions. For a good introduction to the concepts of SMT and Z3, see the Z3 guide (http://rise4fun.com/z3/tutorialcontent/guide). This package does not yet support all of the features or types supported by Z3, though it supports a reasonably large subset. The main entry point to the z3 package is type Context. All values are created and all solving is done relative to some Context, and values from different Contexts cannot be mixed. Symbolic values implement the Value interface. Every value has a type, called a "sort" and represented by type Sort. Sorts fall into general categories called "kinds", such as Bool and Int. Each kind corresponds to a different concrete type that implements the Value interface, since the kind determines the set of operations that make sense on a value. A Bool expression is also called a "formula". These concrete value types help with type checking expressions, but type checking is ultimately done dynamically by Z3. Attempting to create a badly typed value will panic. Symbolic values are represented as expressions of numerals, constants, and uninterpreted functions. A numeral is a literal, fixed value like "2". A constant is a term like "x", whose value is fixed but unspecified. An uninterpreted function is a function whose mapping from arguments to results is fixed but unspecified (this is in contrast to an "interpreted function" like + whose interpretation is specified to be addition). Functions are pure (side-effect-free) like mathematical functions, but unlike mathematical functions they are always total. A constant can be thought of as a function with zero arguments. It's possible to go back and forth between a symbolic value and the expression representing that value using Value.AsAST and AST.AsValue. Type Solver checks the satisfiability of a set of formulas. If the Solver determines that a set of formulas is satisfiable, it can construct a Model giving a specific assignment of constants and uninterpreted functions that satisfies the set of formulas.

Package math provides basic constants and mathematical functions.

Package rand implements pseudo-random number generators. Random numbers are generated by a Source. Top-level functions, such as Float64 and Int, use a default shared Source that produces a deterministic sequence of values each time a program is run. Use the Seed function to initialize the default Source if different behavior is required for each run. The default Source is safe for concurrent use by multiple goroutines, but Sources created by NewSource are not. Mathematical interval notation such as [0, n) is used throughout the documentation for this package. For random numbers suitable for security-sensitive work, see the crypto/rand package. Package rand implements pseudo-random number generators. Random numbers are generated by a Source. Top-level functions, such as Float64 and Int, use a default shared Source that produces a deterministic sequence of values each time a program is run. Use the Seed function to initialize the default Source if different behavior is required for each run. The default Source is safe for concurrent use by multiple goroutines, but Sources created by NewSource are not. Mathematical interval notation such as [0, n) is used throughout the documentation for this package. For random numbers suitable for security-sensitive work, see the crypto/rand package. This example shows the use of each of the methods on a *Rand. The use of the global functions is the same, without the receiver.

Package pbc provides structures for building pairing-based cryptosystems. It is a wrapper around the Pairing-Based Cryptography (PBC) Library authored by Ben Lynn (https://crypto.stanford.edu/pbc/). This wrapper provides access to all PBC functions. It supports generation of various types of elliptic curves and pairings, element initialization, I/O, and arithmetic. These features can be used to quickly build pairing-based or conventional cryptosystems. The PBC library is designed to be extremely fast. Internally, it uses GMP for arbitrary-precision arithmetic. It also includes a wide variety of optimizations that make pairing-based cryptography highly efficient. To improve performance, PBC does not perform type checking to ensure that operations actually make sense. The Go wrapper provides the ability to add compatibility checks to most operations, or to use unchecked elements to maximize performance. Since this library provides low-level access to pairing primitives, it is very easy to accidentally construct insecure systems. This library is intended to be used by cryptographers or to implement well-analyzed cryptosystems. Cryptographic pairings are defined over three mathematical groups: G1, G2, and GT, where each group is typically of the same order r. Additionally, a bilinear map e maps a pair of elements — one from G1 and another from G2 — to an element in GT. This map e has the following additional property: If G1 == G2, then a pairing is said to be symmetric. Otherwise, it is asymmetric. Pairings can be used to construct a variety of efficient cryptosystems. The PBC library currently supports 5 different types of pairings, each with configurable parameters. These types are designated alphabetically, roughly in chronological order of introduction. Type A, D, E, F, and G pairings are implemented in the library. Each type has different time and space requirements. For more information about the types, see the documentation for the corresponding generator calls, or the PBC manual page at https://crypto.stanford.edu/pbc/manual/ch05s01.html. This package must be compiled using cgo. It also requires the installation of GMP and PBC. During the build process, this package will attempt to include <gmp.h> and <pbc/pbc.h>, and then dynamically link to GMP and PBC. Most systems include a package for GMP. To install GMP in Debian / Ubuntu: For an RPM installation with YUM: For installation with Fink (http://www.finkproject.org/) on Mac OS X: For more information or to compile from source, visit https://gmplib.org/ To install the PBC library, download the appropriate files for your system from https://crypto.stanford.edu/pbc/download.html. PBC has three dependencies: the gcc compiler, flex (http://flex.sourceforge.net/), and bison (https://www.gnu.org/software/bison/). See the respective sites for installation instructions. Most distributions include packages for these libraries. For example, in Debian / Ubuntu: The PBC source can be compiled and installed using the usual GNU Build System: After installing, you may need to rebuild the search path for libraries: It is possible to install the package on Windows through the use of MinGW and MSYS. MSYS is required for installing PBC, while GMP can be installed through a package. Based on your MinGW installation, you may need to add "-I/usr/local/include" to CPPFLAGS and "-L/usr/local/lib" to LDFLAGS when building PBC. Likewise, you may need to add these options to CGO_CPPFLAGS and CGO_LDFLAGS when installing this package. This package is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. For additional details, see the COPYING and COPYING.LESSER files. This example generates a pairing and some random group elements, then applies the pairing operation. This example computes and verifies a Boneh-Lynn-Shacham signature in a simulated conversation between Alice and Bob.

Package squaket implements the squaket data type. A squaket is simply a collection of composite data you could group based on a specific property. Take for example: The data you see are composite data having three properties, namely: name, age, and location. If we are to group them based on the similarity of their locations, we could have the following groups: This kind of collection of data is what we mean by squaket. In practice, elements of a squaket are expected to be structs. However, the elements of a squaket could have different properties, as long as they all have the grouping property. Real world example: Things to note: Why's the meaning of squaket? Well, we needed a name to describe a collection of things capable of being grouped, and we thought of "square brackets". As we know, square brackets are used to group things, in languages, mathematics, and programming. So we shortened it, ending up with "squaket".

Package pbc provides structures for building pairing-based cryptosystems. It is a wrapper around the Pairing-Based Cryptography (PBC) Library authored by Ben Lynn (https://crypto.stanford.edu/pbc/). This wrapper provides access to all PBC functions. It supports generation of various types of elliptic curves and pairings, element initialization, I/O, and arithmetic. These features can be used to quickly build pairing-based or conventional cryptosystems. The PBC library is designed to be extremely fast. Internally, it uses GMP for arbitrary-precision arithmetic. It also includes a wide variety of optimizations that make pairing-based cryptography highly efficient. To improve performance, PBC does not perform type checking to ensure that operations actually make sense. The Go wrapper provides the ability to add compatibility checks to most operations, or to use unchecked elements to maximize performance. Since this library provides low-level access to pairing primitives, it is very easy to accidentally construct insecure systems. This library is intended to be used by cryptographers or to implement well-analyzed cryptosystems. Cryptographic pairings are defined over three mathematical groups: G1, G2, and GT, where each group is typically of the same order r. Additionally, a bilinear map e maps a pair of elements — one from G1 and another from G2 — to an element in GT. This map e has the following additional property: If G1 == G2, then a pairing is said to be symmetric. Otherwise, it is asymmetric. Pairings can be used to construct a variety of efficient cryptosystems. The PBC library currently supports 5 different types of pairings, each with configurable parameters. These types are designated alphabetically, roughly in chronological order of introduction. Type A, D, E, F, and G pairings are implemented in the library. Each type has different time and space requirements. For more information about the types, see the documentation for the corresponding generator calls, or the PBC manual page at https://crypto.stanford.edu/pbc/manual/ch05s01.html. This package must be compiled using cgo. It also requires the installation of GMP and PBC. During the build process, this package will attempt to include <gmp.h> and <pbc/pbc.h>, and then dynamically link to GMP and PBC. Most systems include a package for GMP. To install GMP in Debian / Ubuntu: For an RPM installation with YUM: For installation with Fink (http://www.finkproject.org/) on Mac OS X: For more information or to compile from source, visit https://gmplib.org/ To install the PBC library, download the appropriate files for your system from https://crypto.stanford.edu/pbc/download.html. PBC has three dependencies: the gcc compiler, flex (http://flex.sourceforge.net/), and bison (https://www.gnu.org/software/bison/). See the respective sites for installation instructions. Most distributions include packages for these libraries. For example, in Debian / Ubuntu: The PBC source can be compiled and installed using the usual GNU Build System: After installing, you may need to rebuild the search path for libraries: It is possible to install the package on Windows through the use of MinGW and MSYS. MSYS is required for installing PBC, while GMP can be installed through a package. Based on your MinGW installation, you may need to add "-I/usr/local/include" to CPPFLAGS and "-L/usr/local/lib" to LDFLAGS when building PBC. Likewise, you may need to add these options to CGO_CPPFLAGS and CGO_LDFLAGS when installing this package. This package is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. For additional details, see the COPYING and COPYING.LESSER files. This example generates a pairing and some random group elements, then applies the pairing operation. This example computes and verifies a Boneh-Lynn-Shacham signature in a simulated conversation between Alice and Bob.

Package math provides basic constants and mathematical functions.

Package pbc provides structures for building pairing-based cryptosystems. It is a wrapper around the Pairing-Based Cryptography (PBC) Library authored by Ben Lynn (https://crypto.stanford.edu/pbc/). This wrapper provides access to all PBC functions. It supports generation of various types of elliptic curves and pairings, element initialization, I/O, and arithmetic. These features can be used to quickly build pairing-based or conventional cryptosystems. The PBC library is designed to be extremely fast. Internally, it uses GMP for arbitrary-precision arithmetic. It also includes a wide variety of optimizations that make pairing-based cryptography highly efficient. To improve performance, PBC does not perform type checking to ensure that operations actually make sense. The Go wrapper provides the ability to add compatibility checks to most operations, or to use unchecked elements to maximize performance. Since this library provides low-level access to pairing primitives, it is very easy to accidentally construct insecure systems. This library is intended to be used by cryptographers or to implement well-analyzed cryptosystems. Cryptographic pairings are defined over three mathematical groups: G1, G2, and GT, where each group is typically of the same order r. Additionally, a bilinear map e maps a pair of elements — one from G1 and another from G2 — to an element in GT. This map e has the following additional property: If G1 == G2, then a pairing is said to be symmetric. Otherwise, it is asymmetric. Pairings can be used to construct a variety of efficient cryptosystems. The PBC library currently supports 5 different types of pairings, each with configurable parameters. These types are designated alphabetically, roughly in chronological order of introduction. Type A, D, E, F, and G pairings are implemented in the library. Each type has different time and space requirements. For more information about the types, see the documentation for the corresponding generator calls, or the PBC manual page at https://crypto.stanford.edu/pbc/manual/ch05s01.html. This package must be compiled using cgo. It also requires the installation of GMP and PBC. During the build process, this package will attempt to include <gmp.h> and <pbc/pbc.h>, and then dynamically link to GMP and PBC. Most systems include a package for GMP. To install GMP in Debian / Ubuntu: For an RPM installation with YUM: For installation with Fink (http://www.finkproject.org/) on Mac OS X: For more information or to compile from source, visit https://gmplib.org/ To install the PBC library, download the appropriate files for your system from https://crypto.stanford.edu/pbc/download.html. PBC has three dependencies: the gcc compiler, flex (http://flex.sourceforge.net/), and bison (https://www.gnu.org/software/bison/). See the respective sites for installation instructions. Most distributions include packages for these libraries. For example, in Debian / Ubuntu: The PBC source can be compiled and installed using the usual GNU Build System: After installing, you may need to rebuild the search path for libraries: It is possible to install the package on Windows through the use of MinGW and MSYS. MSYS is required for installing PBC, while GMP can be installed through a package. Based on your MinGW installation, you may need to add "-I/usr/local/include" to CPPFLAGS and "-L/usr/local/lib" to LDFLAGS when building PBC. Likewise, you may need to add these options to CGO_CPPFLAGS and CGO_LDFLAGS when installing this package. This package is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. For additional details, see the COPYING and COPYING.LESSER files. This example generates a pairing and some random group elements, then applies the pairing operation. This example computes and verifies a Boneh-Lynn-Shacham signature in a simulated conversation between Alice and Bob.

Package math provides basic constants and mathematical functions.

Package srp Secure Remote Password protocol The principle interface provided by this package is the SRP type. The end aim of the caller is to to have an SRP server and SRP client arrive at the same Key. See the documentation for the SRP structure and its methods for the nitty gritty of use. BUG(jpg): This does not use the same padding and hashing scheme as in RFC 5054, and therefore is not interoperable with those clients and servers. Perhaps someday we'll add an RFC 5054 mode that does that, but today is not that day. It would be nice if this package could be used without having some understanding of the SRP protocol, but too much of the language and naming is depends on at least some familiarity. Here is a summary. The Secure Remote Password protocol involves a server and a client proving to each other that they know (or can derive) their long term secrets. The client long term secret is known as "x" and the corresponding server secret, the verifier, is known as "v". The verifier is mathematically related to x and is computed by the client on first enrollment and transmistted to the server. Typically the server will store the verifier and the client will derive x from a user secret such as a password. Because the verifier can used like a password hash with respect to cracking, the derivation of x should be designed to resist password cracking if the verifier compromised. The client and the server must both use the same Diffie-Hellman group to perform their computations. The server and the client each send an ephemeral public key to each other (The client sends A; the server sends B) With their private knowledge of their own ephemeral secrets (a or b) and their private knowledge of x (for the client) and v (for the server) along with public knowledge they are able to prove to each other that they know their respective secrets and can generate a session key, K, which may be used for further encryption during the session. Quoting from http://srp.stanford.edu/design.html (with some modification for KDF) This package does not address the actual communication between client and server. But through the SRP type it not only performs the calculations needed, it also performs safety and sanity checks on its input, and it hides everything from the caller except what the caller absolutely needs to provide. The key derivation function, KDF() 1. Both client and server: Checking whether methods have returned without error. This is particularly true of SRP.Key() and SetOthersPublic() 2. Client: Using an appropriate key derivation function for deriving x from the user's password (and nudging user toward a good password) 3. Server: Storing the v (send by the client on first enrollment) securely. A captured v can be used to masquerade as the server and be used like a password hash in a password cracking attempt 4. Both: Proving to each other that both have the same key. The package includes methods that can assist with that. ExampleServerClientKey is an example

Package srp Secure Remote Password protocol The principle interface provided by this package is the SRP type. The end aim of the caller is to to have an SRP server and SRP client arrive at the same Key. See the documentation for the SRP structure and its methods for the nitty gritty of use. BUG(jpg): This does not use the same padding and hashing scheme as in RFC 5054, and therefore is not interoperable with those clients and servers. Perhaps someday we'll add an RFC 5054 mode that does that, but today is not that day. It would be nice if this package could be used without having some understanding of the SRP protocol, but too much of the language and naming is depends on at least some familiarity. Here is a summary. The Secure Remote Password protocol involves a server and a client proving to each other that they know (or can derive) their long term secrets. The client long term secret is known as "x" and the corresponding server secret, the verifier, is known as "v". The verifier is mathematically related to x and is computed by the client on first enrollment and transmistted to the server. Typically the server will store the verifier and the client will derive x from a user secret such as a password. Because the verifier can used like a password hash with respect to cracking, the derivation of x should be designed to resist password cracking if the verifier compromised. The client and the server must both use the same Diffie-Hellman group to perform their computations. The server and the client each send an ephemeral public key to each other (The client sends A; the server sends B) With their private knowledge of their own ephemeral secrets (a or b) and their private knowledge of x (for the client) and v (for the server) along with public knowledge they are able to prove to each other that they know their respective secrets and can generate a session key, K, which may be used for further encryption during the session. Quoting from http://srp.stanford.edu/design.html (with some modification for KDF) This package does not address the actual communication between client and server. But through the SRP type it not only performs the calculations needed, it also performs safety and sanity checks on its input, and it hides everything from the caller except what the caller absolutely needs to provide. The key derivation function, KDF() 1. Both client and server: Checking whether methods have returned without error. This is particularly true of SRP.Key() and SetOthersPublic() 2. Client: Using an appropriate key derivation function for deriving x from the user's password (and nudging user toward a good password) 3. Server: Storing the v (send by the client on first enrollment) securely. A captured v can be used to masquerade as the server and be used like a password hash in a password cracking attempt 4. Both: Proving to each other that both have the same key. The package includes methods that can assist with that. ExampleServerClientKey is an example

This package provides mathematical functions that are not provided by the default math/big package (like logarithm).

Package decimal provides a high-performance, arbitrary precision, floating-point decimal library. This package provides floating-point decimal numbers, useful for financial programming or calculations where a larger, more accurate representation of a number is required. In addition to basic arithmetic operations (addition, subtraction, multiplication, and division) this package offers various mathematical functions, including the exponential function, various logarithms, and the ability to compute continued fractions. While lean, this package is full of features. It implements interfaces like “fmt.Formatter” and intuitively utilizes verbs and flags as described in the “fmt” package. (Also included: “fmt.Scanner”, “fmt.Stringer”, “encoding.TextUnmarshaler”, and “encoding.TextMarshaler”.) It allows users to specific explicit contexts for arithmetic operations, but doesn't require it. It provides access to NaN payloads and is more lenient when parsing a decimal from a string than the GDA specification requires. API interfaces have been changed slightly to work more seamlessly with existing Go programs. For example, many “Quantize” implementations require a decimal as both the receiver and argument which isn't very user friendly. Instead, this library accepts a simple “int” which can be derived from an existing decimal if required. It contains two modes of operation designed to make transitioning to various GDA "quirks" (like always rounding lossless operations) easier. There are three primary goals of this library: By adhering to the General Decimal Arithmetic specification, this package has a well-defined structure for its arithmetic operations. Decimal libraries are inherently slow; this library works diligently to minimize memory allocations and utilize efficient algorithms. Performance regularly benchmarks as fast or faster than many other popular decimal libraries. Libraries should be intuitive and work out of the box without having to configure too many settings; however, precise settings should still be available. The following type is supported: The zero value for a Big corresponds with 0, meaning all the following are valid: Method naming is the same as math/big's, meaning: In general, its conventions mirror math/big's. It is suggested to read the math/big package comments to gain an understanding of this package's conventions. Arguments to Binary and Unary methods are allowed to alias, so the following is valid: Unless otherwise specified, the only argument that will be modified is the result (“z”). This means the following is valid and race-free: But this is not:

Package pbc provides structures for building pairing-based cryptosystems. It is a wrapper around the Pairing-Based Cryptography (PBC) Library authored by Ben Lynn (https://crypto.stanford.edu/pbc/). This wrapper provides access to all PBC functions. It supports generation of various types of elliptic curves and pairings, element initialization, I/O, and arithmetic. These features can be used to quickly build pairing-based or conventional cryptosystems. The PBC library is designed to be extremely fast. Internally, it uses GMP for arbitrary-precision arithmetic. It also includes a wide variety of optimizations that make pairing-based cryptography highly efficient. To improve performance, PBC does not perform type checking to ensure that operations actually make sense. The Go wrapper provides the ability to add compatibility checks to most operations, or to use unchecked elements to maximize performance. Since this library provides low-level access to pairing primitives, it is very easy to accidentally construct insecure systems. This library is intended to be used by cryptographers or to implement well-analyzed cryptosystems. Cryptographic pairings are defined over three mathematical groups: G1, G2, and GT, where each group is typically of the same order r. Additionally, a bilinear map e maps a pair of elements — one from G1 and another from G2 — to an element in GT. This map e has the following additional property: If G1 == G2, then a pairing is said to be symmetric. Otherwise, it is asymmetric. Pairings can be used to construct a variety of efficient cryptosystems. The PBC library currently supports 5 different types of pairings, each with configurable parameters. These types are designated alphabetically, roughly in chronological order of introduction. Type A, D, E, F, and G pairings are implemented in the library. Each type has different time and space requirements. For more information about the types, see the documentation for the corresponding generator calls, or the PBC manual page at https://crypto.stanford.edu/pbc/manual/ch05s01.html. This package must be compiled using cgo. It also requires the installation of GMP and PBC. During the build process, this package will attempt to include <gmp.h> and <pbc/pbc.h>, and then dynamically link to GMP and PBC. Most systems include a package for GMP. To install GMP in Debian / Ubuntu: For an RPM installation with YUM: For installation with Fink (http://www.finkproject.org/) on Mac OS X: For more information or to compile from source, visit https://gmplib.org/ To install the PBC library, download the appropriate files for your system from https://crypto.stanford.edu/pbc/download.html. PBC has three dependencies: the gcc compiler, flex (http://flex.sourceforge.net/), and bison (https://www.gnu.org/software/bison/). See the respective sites for installation instructions. Most distributions include packages for these libraries. For example, in Debian / Ubuntu: The PBC source can be compiled and installed using the usual GNU Build System: After installing, you may need to rebuild the search path for libraries: It is possible to install the package on Windows through the use of MinGW and MSYS. MSYS is required for installing PBC, while GMP can be installed through a package. Based on your MinGW installation, you may need to add "-I/usr/local/include" to CPPFLAGS and "-L/usr/local/lib" to LDFLAGS when building PBC. Likewise, you may need to add these options to CGO_CPPFLAGS and CGO_LDFLAGS when installing this package. This package is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. For additional details, see the COPYING and COPYING.LESSER files. This example generates a pairing and some random group elements, then applies the pairing operation. This example computes and verifies a Boneh-Lynn-Shacham signature in a simulated conversation between Alice and Bob.

Package GLaM provides mathematical types and operations for use with OpenGL.

Package parsefloat converts a string in go expression format into a reverse polish notation representation of its mathematical transformation, as long as it only has float64's, functions of float64 from the math package, and predefined identifiers. Doing this in RPN might be kind of dumb. There may be a better way of evaluating go expressions. Note that only functions of float64s and float64 literals are allowed, with the expection of << and >>, because while those functions can be applied to float64's, it will panic if the amount to shift is not an integer.

Package gocalc is for evaluating mathematical expressions at runtime. See https://github.com/justinsacbibit/gocalc-cl-sample for a sample console app that uses gocalc.

Package set represents the mathematical set.

Package meval provides a mathematical expresison parser. It can parse mathematical expresison into an AST and evaluate it. It also support the concept of variable through Context : An Expression can refer any other expression defined in a Context. For simple case use, a nil Context could be used (any expression refering another expression will fail at evaluation). An expression can be parsed using Compile, and evaluated with a nil context. See #Expression basic example. One can use context, in order for your expression to refer to others, aka variable. TODO(tuleu): document a context and how to use it TODO(tuleu) package global example

Package units provides type Bytes, which implements fmt.Formatter and can be easily formatted to various human-readable string using std fmt package. It also has some mathematics methods to modify the value. See example_test.go. The formatting result typically consists of a number and a unit. There are binary units (kiB, MiB, GiB and TiB), decimal units (kB, MB, GB and TB) and base unit B. Further reading: https://en.wikipedia.org/wiki/Binary_prefix. When calculating the output number, binary units are used by default. You can switch to decimal units by adding the '#' flag. Why is there no 'PiB/PB'? 'TiB/TB' is sufficient for most cases, and many non-technical people are not familiar with 'PiB/PB'. Examples: Examples: Sign for numbers ('+'), left-justify ('-') and zero padding ('0') are not supported. The width includes the unit.

Package galoisfield implements the `GF(2**m)` Galois finite fields. What is a Galois field? A Galois field, also known as a finite field, is a mathematical field with a number of elements equal to a prime number to a positive integer power. While finite fields with a prime number of elements are familiar to most programmers -- boolean arithmetic, a.k.a. arithmetic `mod 2` is a well-known example -- fields that take that prime to powers higher than 1 is less well-known. Basically, an element of `GF(2**m)` can be seen as a list of `m` bits, where addition and multiplication are elementwise `mod 2` (`a XOR b` for addition, `a AND b` for multiplication) and the remaining rules of field arithmetic follow from linear algebra (vectors, or alternatively, polynomial coefficients). Short version: an element of `GF(2**8)` element may be represented as a byte (0 ≤ n ≤ 255), but it's really a vector of 8 bits -- like a very primitive MMX/SSE. We then treat said vector as the coefficients of a polynomial, and that allows us to define multiplication, giving us a full mathematical field. Finite fields -- and `GF(2**8)` in particular -- get a tons of use in codes, in both the "error-correcting code" and "cryptographic code" senses. However, this implementation has NOT been hardened against timing attacks, so it MUST NOT be used in cryptography.

Package libquickjs is a CGo-free, ccgo/v4 version of libquickjs.a, a library implementing an embeddable Javascript engine. It supports the ES2023 specification including modules, asynchronous generators, proxies and BigInt. It optionally supports mathematical extensions such as big decimal floating point numbers (BigDecimal), big binary floating point numbers (BigFloat) and operator overloading. These combinations of GOOS and GOARCH are currently supported Builder results available at: https://modern-c.appspot.com/-/builder/?importpath=modernc.org%2flibquickjs If a builder reports PASS then this package passed all the test262 suite test cases the original C version passed on the respective target.

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 expr provides a framework for parsing and evaluating mathematical expressions.

Package squaket implements the squaket data type. A squaket is simply a collection of composite data you could group based on a specific property. Take for example: The data you see are composite data having three properties, namely: name, age, and location. If we are to group them based on the similarity of their locations, we could have the following groups: This kind of collection of data is what we mean by squaket. In practice, elements of a squaket are expected to be structs. However, the elements of a squaket could have different properties, as long as they all have the grouping property. Real world example: Things to note: Why's the meaning of squaket? Well, we needed a name to describe a collection of things capable of being grouped, and we thought of "square brackets". As we know, square brackets are used to group things, in languages, mathematics, and programming. So we shortened it, ending up with "squaket".

Package decimal implements immutable decimal floating-point numbers. It is specifically designed for transactional financial systems and adheres to the principles set by ANSI X3.274-1996. Decimal is a struct with three fields: The numerical value of a decimal is calculated as follows: This approach allows the same numeric value to have multiple representations, for example, 1, 1.0, and 1.00, which represent the same value but have different scales and coefficients. The range of a decimal is determined by its scale. Here are the ranges for frequently used scales: Subnormal numbers are not supported to ensure peak performance. Consequently, decimals between -0.00000000000000000005 and 0.00000000000000000005 inclusive, are rounded to 0. Special values such as NaN, Infinity, or negative zeros are not supported. This ensures that arithmetic operations always produce either valid decimals or errors. Each arithmetic operation, except for Decimal.Sqrt and [Decimal.SqrtExact], occurs in two steps: The operation is initially performed using uint64 arithmetic. If no overflow occurs, the exact result is immediately returned. If overflow occurs, the operation proceeds to step 2. The operation is repeated with double precision using big.Int arithmetic. The result is then rounded to 19 digits. If no significant digits are lost during rounding, the inexact result is returned. If any significant digit is lost, an overflow error is returned. Step 1 improves performance by avoiding performance impact associated with big.Int arithmetic. It is expected that, in transactional financial systems, most arithmetic operations will compute an exact result during step 1. The following rules determine the significance of digits during step 2: Unlike many other decimal libraries, this package does not provide an explicit context. Instead, the context is implicit and can be approximately equated to the following settings: The equality of Etiny and Emin implies that this package does not support subnormal numbers. Implicit rounding is applied when a result exceeds 19 digits, rounding it to 19 digits using half-to-even rounding. This method ensures that rounding errors are evenly distributed between rounding up and down. For all arithmetic operations, except for Decimal.Pow and Decimal.PowExact, the result is the one that would be obtained by computing the exact mathematical result with infinite precision and then rounding it to 19 digits. Decimal.Pow and Decimal.PowExact may occasionally produce a result that is off by 1 unit in the last place. In addition to implicit rounding, the package provides several methods for explicit rounding: See the documentation for each method for more details. All methods are panic-free and pure. Errors are returned in the following cases: Division by Zero: Unlike the standard library, Decimal.Quo, Decimal.QuoRem, and Decimal.Inv do not panic when dividing by 0. Instead, they return an error. Invalid Operation: Decimal.Pow and Decimal.PowExact return an error if 0 is raised to a negative power. Decimal.Sqrt and [Decimal.SqrtExact] return an error if the square root of a negative decimal is requested. Overflow: Unlike standard integers, there is no "wrap around" for decimals at certain sizes. For out-of-range values, arithmetic operations return an error. Errors are not returned in the following cases: A. JSON The package integrates seamlessly with standard encoding/json through the implementation of encoding.TextMarshaller and encoding.TextUnmarshaler interfaces. Below is an example structure: This package marshals decimals as quoted strings, ensuring the preservation of the exact numerical value. Below is an example OpenAPI schema: B. XML The package integrates with standard encoding/xml via the implementation of encoding.TextMarshaller and encoding.TextUnmarshaler interfaces. Below is an example structure: "xs:decimal" type can represent decimals in XML schema. It is possible to impose restrictions on the length of the decimals using the following type: C. Protocol Buffers Protocol Buffers can represent decimals as numerical strings, preserving trailing zeros. To convert between numerical strings and decimals, use Parse and Decimal.String. Below is an example of a proto definition: Alternatively, decimals can be represented as two integers: one for the integer part and another for the fractional part. However, this format does not preserve trailing zeros and rounds decimals with more than nine digits in the fractional part. For conversion between this format and decimals, use NewFromInt64 and Decimal.Int64 with a scale argument of "9". Below is an example of a proto definition: D. SQL The package integrates with the standard database/sql via the implementation of sql.Scanner and driver.Valuer interfaces. To ensure accurate preservation of decimal scales, it is essential to choose appropriate column types: Below are the reasons for these preferences: PostgreSQL: Always use DECIMAL without precision or scale specifications, that is, avoid DECIMAL(p) or DECIMAL(p, s). DECIMAL accurately preserves the scale of decimals. SQLite: Prefer TEXT, since DECIMAL is just an alias for binary floating-point numbers. TEXT accurately preserves the scale of decimals. MySQL: Use DECIMAL(19, d), as DECIMAL is merely an alias for DECIMAL(10, 0). The downside of this format is that MySQL automatically rescales all decimals: it rounds values with more than d digits in the fractional part (using half away from zero) and pads with trailing zeros those with fewer than d digits in the fractional part. To prevent automatic rescaling, consider using VARCHAR(22), which accurately preserves the scale of decimals. This example demonstrates the advantage of decimals for financial calculations. It computes the sum 1.1 + 1.2 + 1.3 using both decimal and float64 arithmetic. In decimal arithmetic, the result is exactly 3.6, as expected. In float64 arithmetic, the result is 3.5999999999999996 due to floating-point inaccuracy. This example calculates an approximate value of π using the Leibniz formula. The Leibniz formula is an infinite series that converges to π/4, and is given by the equation: 1 - 1/3 + 1/5 - 1/7 + 1/9 - 1/11 + ... = π/4. This example computes the series up to the 500,000th term using decimal arithmetic and returns the approximate value of π. This example implements a simple calculator that evaluates mathematical expressions written in postfix notation. The calculator can handle basic arithmetic operations such as addition, subtraction, multiplication, and division.

Package GLaM provides mathematical types and operations for use with OpenGL.

Package record provides a thin wrapper over a native composite map data structure that simplifies access to the final (leaf) values. Some database SDKs return such composite map structures when fetching a record. - We assume all keys are strings in order to simplify access. - Record values are accessed/set by providing a string representation of the path separated by ".". For example, passing "key1.key2" to a Record fetchs the value with key "key2" in the subrecord S of the record R, where the key of S is "key1". Mathematically, we can view a composite map as a function f whose domain is the subset X of finite length tuples of the countable product of some key set A. For each index i, fi is a function from A to the set of possible values. Then f(k1, k2, k3, ..., kn) := f1 (f2 ... fn(kn)). This makes the dot notation for paths quite natural.

Mathematical art based on: https://blogs.scientificamerican.com/guest-blog/making-mathematical-art/

Package pbc provides structures for building pairing-based cryptosystems. It is a wrapper around the Pairing-Based Cryptography (PBC) Library authored by Ben Lynn (https://crypto.stanford.edu/pbc/). This wrapper provides access to all PBC functions. It supports generation of various types of elliptic curves and pairings, element initialization, I/O, and arithmetic. These features can be used to quickly build pairing-based or conventional cryptosystems. The PBC library is designed to be extremely fast. Internally, it uses GMP for arbitrary-precision arithmetic. It also includes a wide variety of optimizations that make pairing-based cryptography highly efficient. To improve performance, PBC does not perform type checking to ensure that operations actually make sense. The Go wrapper provides the ability to add compatibility checks to most operations, or to use unchecked elements to maximize performance. Since this library provides low-level access to pairing primitives, it is very easy to accidentally construct insecure systems. This library is intended to be used by cryptographers or to implement well-analyzed cryptosystems. Cryptographic pairings are defined over three mathematical groups: G1, G2, and GT, where each group is typically of the same order r. Additionally, a bilinear map e maps a pair of elements — one from G1 and another from G2 — to an element in GT. This map e has the following additional property: If G1 == G2, then a pairing is said to be symmetric. Otherwise, it is asymmetric. Pairings can be used to construct a variety of efficient cryptosystems. The PBC library currently supports 5 different types of pairings, each with configurable parameters. These types are designated alphabetically, roughly in chronological order of introduction. Type A, D, E, F, and G pairings are implemented in the library. Each type has different time and space requirements. For more information about the types, see the documentation for the corresponding generator calls, or the PBC manual page at https://crypto.stanford.edu/pbc/manual/ch05s01.html. This package must be compiled using cgo. It also requires the installation of GMP and PBC. During the build process, this package will attempt to include <gmp.h> and <pbc/pbc.h>, and then dynamically link to GMP and PBC. Most systems include a package for GMP. To install GMP in Debian / Ubuntu: For an RPM installation with YUM: For installation with Fink (http://www.finkproject.org/) on Mac OS X: For more information or to compile from source, visit https://gmplib.org/ To install the PBC library, download the appropriate files for your system from https://crypto.stanford.edu/pbc/download.html. PBC has three dependencies: the gcc compiler, flex (http://flex.sourceforge.net/), and bison (https://www.gnu.org/software/bison/). See the respective sites for installation instructions. Most distributions include packages for these libraries. For example, in Debian / Ubuntu: The PBC source can be compiled and installed using the usual GNU Build System: After installing, you may need to rebuild the search path for libraries: It is possible to install the package on Windows through the use of MinGW and MSYS. MSYS is required for installing PBC, while GMP can be installed through a package. Based on your MinGW installation, you may need to add "-I/usr/local/include" to CPPFLAGS and "-L/usr/local/lib" to LDFLAGS when building PBC. Likewise, you may need to add these options to CGO_CPPFLAGS and CGO_LDFLAGS when installing this package. This package is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. For additional details, see the COPYING and COPYING.LESSER files. This example generates a pairing and some random group elements, then applies the pairing operation. This example computes and verifies a Boneh-Lynn-Shacham signature in a simulated conversation between Alice and Bob.

Package geo contains a collection of 2-D types and other mathematical functions geared towards games. Includes This package assumes coordinates where +x is right and +y is down.