Command mathfmt formats mathematical documentation.
Package vision is a repository containing visual processing packages in Go (golang), focused mainly on providing efficient V1 (primary visual cortex) level filtering of images, with the output then suitable as input for neural networks. Two main types of filters are supported: * **Gabor** filters simulate V1 simple-cell responses in terms of an oriented sine wave times a gaussian envelope that localizes the filter in space. This produces an edge detector that detects oriented contrast transitions between light and dark. In general, the main principle of primary visual filtering is to focus on spatial (and temporal) changes, while filtering out static, uniform areas. * **DoG** (difference of gaussian) filters simulate retinal On-center vs. Off-center contrast coding cells -- unlike gabor filters, these do not have orientation tuning. Mathematically, they are a difference between a narrow (center) vs wide (surround) gaussian, of opposite signs, balanced so that a uniform input generates offsetting values that sum to zero. In the visual system, orientation tuning is constructed from aligned DoG-like inputs, but it is more efficient to just use the Gabor filters directly. However, DoG filters capture the "blob" cells that encode color contrasts. The `vfilter` package contains general-purpose filtering code that applies (convolves) any given filter with a visual input. It also supports converting an `image.Image` into a `etensor.Float32` tensor which is the main data type used in this framework. It also supports max-pooling for efficiently reducing the dimensionality of inputs. The `kwta` package provides an implementation of the feedforward and feedback (FFFB) inhibition dynamics (and noisy X-over-X-plus-1 activation function) from the `Leabra` algorithm to produce a k-Winners-Take-All processing of visual filter outputs -- this increases the contrast and simplifies the representations, and is a good model of the dynamics in primary visual cortex.
Package vecf64 provides common functions and methods for slices of float64. In the days of yore, scientists who computed with computers would use arrays to represent vectors, each value representing magnitude and/or direction. Then came the C++ Standard Templates Library, which sought to provide this data type in the standard library. Now, everyone conflates a term "vector" with dynamic arrays. In the C++ book, Bjarne Stroustrup has this to say: Go has a better name for representing dynamically allocated arrays of any type - "slice". However, "slice" is both a noun and verb and many libraries that I use already use "slice"-as-a-verb as a name, so I had to settle for the second best name: "vector". It should be noted that while the names used in this package were definitely mathematically inspired, they bear only little resemblance the actual mathematical operations performed. The names of the operations assume you're working with slices of float64s. Hence `Add` performs elementwise addition between two []float64. Operations between []float64 and float64 are also supported, however they are differently named. Here are the equivalents: You may note that for the []float64 - float64 binary operations, the scalar (float64) is always the first operand. In operations that are not commutative, an additional function is provided, suffixed with "R" (for reverse) This package does not provide range checking. If indices are out of range, the functions will panic. This package should play well with BCE. TODO: provide SIMD vectorization for Incr and []float32-float64 functions. Pull requests accepted
Package gorgonia is a library that helps facilitate machine learning in Go. Write and evaluate mathematical equations involving multidimensional arrays easily. Do differentiation with them just as easily. Autodiff showcases automatic differentiation Basic example of representing mathematical equations as graphs. In this example, we want to represent the following equation Gorgonia provides an API that is fairly idiomatic - most of the functions in in the API return (T, error). This is useful for many cases, such as an interactive shell for deep learning. However, it must also be acknowledged that this makes composing functions together a bit cumbersome. To that end, Gorgonia provides two alternative methods. First, the `Lift` based functions; Second the `Must` function Linear Regression Example The formula for a straight line is We want to find an `m` and a `c` that fits the equation well. We'll do it in both float32 and float64 to showcase the extensibility of Gorgonia This example showcases the reasons for the more confusing functions. This example showcases dealing with errors. This is part 2 of the raison d'être of the more complicated functions - dealing with errors SymbolicDiff showcases symbolic differentiation
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 math provides basic constants and mathematical functions.
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.
A simple to use implementation of ECDH with curve25519 for Go. The core mathematics of this algorithm are already present in golang.org/x/crypto/curve25519, this library just implements the algorithm in such a way that knowledge of the underlying mathematics is not necessary.
Package vecf64 provides common functions and methods for slices of float64. In the days of yore, scientists who computed with computers would use arrays to represent vectors, each value representing magnitude and/or direction. Then came the C++ Standard Templates Library, which sought to provide this data type in the standard library. Now, everyone conflates a term "vector" with dynamic arrays. In the C++ book, Bjarne Stroustrup has this to say: Go has a better name for representing dynamically allocated arrays of any type - "slice". However, "slice" is both a noun and verb and many libraries that I use already use "slice"-as-a-verb as a name, so I had to settle for the second best name: "vector". It should be noted that while the names used in this package were definitely mathematically inspired, they bear only little resemblance the actual mathematical operations performed. The names of the operations assume you're working with slices of float64s. Hence `Add` performs elementwise addition between two []float64. Operations between []float64 and float64 are also supported, however they are differently named. Here are the equivalents: You may note that for the []float64 - float64 binary operations, the scalar (float64) is always the first operand. In operations that are not commutative, an additional function is provided, suffixed with "R" (for reverse) This package does not provide range checking. If indices are out of range, the functions will panic. This package should play well with BCE. TODO: provide SIMD vectorization for Incr and []float32-float64 functions. Pull requests accepted
This package provides mathematical functions that are not provided by the default math/big package (like logarithm).
Package expr hosts the implementation of string expression evaluator to evaluate basic mathematical expression and boolean expression.
Package geo enables performing mathematical operations on locations around the Earth. Since the Earth is an irregular ellipsoid, rather than a sphere, and the math operations take this into account.
Package vecf32 provides common functions and methods for slices of float32. In the days of yore, scientists who computed with computers would use arrays to represent vectors, each value representing magnitude and/or direction. Then came the C++ Standard Templates Library, which sought to provide this data type in the standard library. Now, everyone conflates a term "vector" with dynamic arrays. In the C++ book, Bjarne Stroustrup has this to say: Go has a better name for representing dynamically allocated arrays of any type - "slice". However, "slice" is both a noun and verb and many libraries that I use already use "slice"-as-a-verb as a name, so I had to settle for the second best name: "vector". It should be noted that while the names used in this package were definitely mathematically inspired, they bear only little resemblance the actual mathematical operations performed. The names of the operations assume you're working with slices of float32s. Hence `Add` performs elementwise addition between two []float32. Operations between []float32 and float32 are also supported, however they are differently named. Here are the equivalents: You may note that for the []float64 - float64 binary operations, the scalar (float64) is always the first operand. In operations that are not commutative, an additional function is provided, suffixed with "R" (for reverse) This package does not provide range checking. If indices are out of range, the functions will panic. This package should play well with BCE. TODO(anyone): provide SIMD vectorization for Incr and []float32-float64 functions Pull requests accepted
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 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 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 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) 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 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 rocketc is fast, simple and lightweight library for CSV data manipulation and mathematical computation involving 2D Matrices.
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
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 vecf32 provides common functions and methods for slices of float32. In the days of yore, scientists who computed with computers would use arrays to represent vectors, each value representing magnitude and/or direction. Then came the C++ Standard Templates Library, which sought to provide this data type in the standard library. Now, everyone conflates a term "vector" with dynamic arrays. In the C++ book, Bjarne Stroustrup has this to say: Go has a better name for representing dynamically allocated arrays of any type - "slice". However, "slice" is both a noun and verb and many libraries that I use already use "slice"-as-a-verb as a name, so I had to settle for the second best name: "vector". It should be noted that while the names used in this package were definitely mathematically inspired, they bear only little resemblance the actual mathematical operations performed. The names of the operations assume you're working with slices of float32s. Hence `Add` performs elementwise addition between two []float32. Operations between []float32 and float32 are also supported, however they are differently named. Here are the equivalents: You may note that for the []float64 - float64 binary operations, the scalar (float64) is always the first operand. In operations that are not commutative, an additional function is provided, suffixed with "R" (for reverse) This package does not provide range checking. If indices are out of range, the functions will panic. This package should play well with BCE. TODO(anyone): provide SIMD vectorization for Incr and []float32-float64 functions Pull requests accepted
Package set provides functions and an interface to work with sets of finite or infinite mathematical sets. There is a distinction between definitely finite sets which provides an explicit representation and non definitely finite sets which are lacking some functionality and performance but are able to handle infinite sets.
Package math provides basic constants and mathematical functions.
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 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 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.
This program is copyright (C) 1982 by D. E. Knuth; all rights are reserved. Unlimited copying and redistribution of this file are permitted as long as this file is not modified. Modifications are permitted, but only if the resulting file is not named tex.web. (The WEB system provides for alterations via an auxiliary file; the master file should stay intact.) See Appendix H of the WEB manual for hints on how to install this program. And see Appendix A of the TRIP manual for details about how to validate it. TeX is a trademark of the American Mathematical Society. METAFONT is a trademark of Addison-Wesley Publishing Company. Version 0 was released in September 1982 after it passed a variety of tests. Version 1 was released in November 1983 after thorough testing. Version 1.1 fixed “disappearing font identifiers” et alia (July 1984). Version 1.2 allowed `0' in response to an error, et alia (October 1984). Version 1.3 made memory allocation more flexible and local (November 1984). Version 1.4 fixed accents right after line breaks, et alia (April 1985). Version 1.5 fixed \the\toks after other expansion in \edefs (August 1985). Version 2.0 (almost identical to 1.5) corresponds to "Volume B" (April 1986). Version 2.1 corrected anomalies in discretionary breaks (January 1987). Version 2.2 corrected "(Please type...)" with null \endlinechar (April 1987). Version 2.3 avoided incomplete page in premature termination (August 1987). Version 2.4 fixed \noaligned rules in indented displays (August 1987). Version 2.5 saved cur_order when expanding tokens (September 1987). Version 2.6 added 10sp slop when shipping leaders (November 1987). Version 2.7 improved rounding of negative-width characters (November 1987). Version 2.8 fixed weird bug if no \patterns are used (December 1987). Version 2.9 made \csname\endcsname's "relax" local (December 1987). Version 2.91 fixed \outer\def\a0{}\a\a bug (April 1988). Version 2.92 fixed \patterns, also file names with complex macros (May 1988). Version 2.93 fixed negative halving in allocator when mem_min<0 (June 1988). Version 2.94 kept open_log_file from calling fatal_error (November 1988). Version 2.95 solved that problem a better way (December 1988). Version 2.96 corrected bug in "Infinite shrinkage" recovery (January 1989). Version 2.97 corrected blunder in creating 2.95 (February 1989). Version 2.98 omitted save_for_after at outer level (March 1989). Version 2.99 caught $$\begingroup\halign..$$ (June 1989). Version 2.991 caught .5\ifdim.6... (June 1989). Version 2.992 introduced major changes for 8-bit extensions (September 1989). Version 2.993 fixed a save_stack synchronization bug et alia (December 1989). Version 3.0 fixed unusual displays; was more \output robust (March 1990). Version 3.1 fixed nullfont, disabled \write{\the\prevgraf} (September 1990). Version 3.14 fixed unprintable font names and corrected typos (March 1991). Version 3.141 more of same; reconstituted ligatures better (March 1992). Version 3.1415 preserved nonexplicit kerns, tidied up (February 1993). Version 3.14159 allowed fontmemsize to change; bulletproofing (March 1995). Version 3.141592 fixed \xleaders, glueset, weird alignments (December 2002). Version 3.1415926 was a general cleanup with minor fixes (February 2008). Version 3.14159265 was similar (January 2014). Version 3.141592653 was similar but more extensive (January 2021). A reward of $327.68 will be paid to the first finder of any remaining bug. Although considerable effort has been expended to make the TeX program correct and reliable, no warranty is implied; the author disclaims any obligation or liability for damages, including but not limited to special, indirect, or consequential damages arising out of or in connection with the use or performance of this software. This work has been a “labor of love” and the author hopes that users enjoy it. Here is TeX material that gets inserted after \input webmac
Package levenshtein implements distance and similarity metrics for strings, based on the Levenshtein measure. The Levenshtein `Distance` between two strings is the minimum total cost of edits that would convert the first string into the second. The allowed edit operations are insertions, deletions, and substitutions, all at character (one UTF-8 code point) level. Each operation has a default cost of 1, but each can be assigned its own cost equal to or greater than 0. A `Distance` of 0 means the two strings are identical, and the higher the value the more different the strings. Since in practice we are interested in finding if the two strings are "close enough", it often does not make sense to continue the calculation once the result is mathematically guaranteed to exceed a desired threshold. Providing this value to the `Distance` function allows it to take a shortcut and return a lower bound instead of an exact cost when the threshold is exceeded. The `Similarity` function calculates the distance, then converts it into a normalized metric within the range 0..1, with 1 meaning the strings are identical, and 0 that they have nothing in common. A minimum similarity threshold can be provided to speed up the calculation of the metric for strings that are far too dissimilar for the purpose at hand. All values under this threshold are rounded down to 0. The `Match` function provides a similarity metric, with the same range and meaning as `Similarity`, but with a bonus for string pairs that share a common prefix and have a similarity above a "bonus threshold". It uses the same method as proposed by Winkler for the Jaro distance, and the reasoning behind it is that these string pairs are very likely spelling variations or errors, and they are more closely linked than the edit distance alone would suggest. The underlying `Calculate` function is also exported, to allow the building of other derivative metrics, if needed.