Mathematics

Command mathfmt formats mathematical documentation.

This is a test to see how publishing works and to provide the maf module The maf module provides mathematical functions and transformations between geometrical objects commonly used in game engines

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 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 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 increased 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. 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: JSON. The package integrates seamlessly with standard encoding/json through the implementation of encoding.TextMarshaller and encoding.TextUnmarshaler interfaces. Here is an example structure: The package marshals decimals as quoted strings, ensuring the preservation of the exact numerical value. Here is an example OpenAPI schema: XML. The package integrates with standard encoding/xml via the implementation of encoding.TextMarshaller and encoding.TextUnmarshaler interfaces. Here is an example structure: "xs:decimal" type can be used to represent decimals in XML schema. It is possible to impose restrictions on the length of the decimals using the following type: 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. Here is an example proto definition: Alternatively, decimals can be represented as two integers: one for the integer part and another for the fractional part. For conversion between this format and decimals, use NewFromInt64 and Decimal.Int64 with a scale argument equal to "9". Here is an example proto definition: 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: Here are the reasons: For PostgreSQL, always use DECIMAL without precision or scale specifications (avoid DECIMAL(p) or DECIMAL(p, s)). DECIMAL accurately preserves the scale of decimals. In SQLite, prefer TEXT, since DECIMAL is just an alias for floating-point numbers. TEXT preserves the scale of decimals. In MySQL, use DECIMAL(19, d), as DECIMAL is just an alias for DECIMAL(10, 0). The disadvantage of this format is that MySQL automatically rescales all decimals: values with a scale exceeding "d" are rounded (using half away from zero), while those with a lower scale are padded with trailing zeros. To avoid automatic rescaling, consider using VARCHAR(22). This example demonstrates the advantage of decimals for financial calculations. It computes the sum 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1. In decimal arithmetic, the result is exactly 1.0. In float64 arithmetic, the result slightly deviates from 1.0 due to binary floating-point representation. 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 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 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 rocketc is fast, simple and lightweight library for CSV data manipulation and mathematical computation involving 2D Matrices.

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 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 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.

Package calculator provides basic constants and mathematical functions for stock options.

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

Because Go does not support operator overloading, most numerical libraries are messy to use. M-AST is an attempt to write a domain-specific language for math, so that code can be written in a more simple way. If it helps, think regular expressions, but for algebra. Mast mostly exists to create parsers for math-like languages. To use it, first create a *mast.Parser object, configuring the various operations and their precidence. Then you invoke the (p *mast.Parser).Parse(string) (*mast.Equation, error) function. Suppose we want to make a basic calculator parser. First, define which operations and grouping operators we want to support: To parse a string using this language, invoke (p *mast.Parser) Parse(string) (*mast.Equation, error) with the source code to evaluate. For example, if we run: then err will be nil and tree will be as follows: By iterating over the tree, your DSL can evaluate the mathematical expression while maintaining type integrity. Mast includes a toy evaluator that handles matrices as [][]float64. To use it, invoke the Eval(code string, args ...interface{}) error function, passing pointers to the respective arguments. Think %-arguments to fmt.Printf. To make setting up variables easier, arguments can be specified in three ways: All other types panic. Suppose we want to compute a linear transform (multiplying a vector by a matrix, and adding a vector). First, we set up the variables to compute: Once those are set up, the computation is fairly easy. The result is then available in y.

go-bliss are Go bindings to bliss, a small library that can analyze songs and compute the distance between two songs. It can be useful for creating "intelligent" playlists of songs that are similar. The main algorithm works by outputting a vector V = (a,b,c,d) for each song. The euclidean distance between these vectors corresponds to the actual distance felt by listening to them: a playlist can then be built by queuing close songs, or do other stuff using mathematical tools available on euclidean 4-dimensionnal spaces. go-bliss depends on bliss (compile-time and runtime), which itself depends on some libav* libraries (compile-time and runtime). Check the project README for detailed setup instructions. Check the project README for links to technical details about the analysis process. go-bliss can compute: - for each song, a force (float) for the overall song intensity, corresponding to a force rating (ForceRating), either calm, loud, or unknown - for each song, a vector containg 4 floats (ForceVector), each rating an aspect of the song: tempo is the BPM of the song, amplitude is the physical force of the song, frequency is the ratio between high and low frequencies, attack is a sum of intensity of all the attacks divided by the song length - for two songs, the distance between them (float) (the euclidian distance between their force vectors), or their cosine similarity There is no global library setup or teardown method. go-bliss can decode an audio file with Decode into a struct, Song, that contains metadata about the file and its samples. Song also contains fields corresponding to the song analysis result, that is not filled by this call. A Song owns internal memory that can be freed explicitly by using Close when done using it, or automatically by the GC after some time (with runtime.SetFinalizer). go-bliss can analyze an audio file with Analyze into a Song, like Decode, except it also analyzes the song and fills its analysis-related fields. go-bliss can compute the distance between two songs (either audio files with DistanceFile, or files already decoded to songs with Distance), or their cosine similarity (with CosineSimilarity and CosineSimilarityFile). go-bliss can also compute a specific value of a song rather than all of them with EnvelopeSort, AmplitudeSort, and FrequencySort. go-bliss also has Mean, Variance, and RectangularFilter helpers, as well as a Version function. As far as I know bliss does not store global state, so processing two different songs concurrently should be fine.

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 abelian provides data structures and functions abelian group in Go. An abelian group is a mathematical group 〈S,·〉 in which the binary operation · can be applied to two group elements x,y ∈ S commutatively, i.e. x·y = y·x. This package provides a minimal representation for such group, where the set S is any types that implements the set.Set interface. Most of the functionalities of the Group will be provided by the set.Set implementation. A number of properties interfaces (e.g. StrictOrdered, Enumerable, ...) are also provided for convenience. To use this package to represent custom abelian groups, simply provide an implementation for the Set and binary function Op.

Package market reads and writes in the NIST Matrix Market native exchange format. The Matrix Market is a service of the Mathematical and Computational Sciences Division of the Information Technology Laboratory of the National Institute of Standards and Technology (NIST), containing "test data for use in comparative studies of algorithms for numerical linear algebra, featuring nearly 500 sparse matrices from a variety of applications, as well as matrix generation tools and services." The Matrix Market native exchange format has become a standard for exchanging matrix data.

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 rating implements the simple glicko-2 Rating. Glicko-2 Rating: see as following. (within this package, denoted as ref[1] below) Note : The variable names in this package match the mathematical Greek letter variables of the dissertation. Note2: This English is written by the power of Google Translate.

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 argon2 provides a simplified interface for the argon2 key derivation function using https://golang.org/x/crypto/argon2. Configuration is handled by creating a Hasher structure with all attributes populated, or by passing a comma-delimited key-value string to the NewHasherFromString function. The Hasher structure possesses the functions to create and verify password hashes. argon2i and argon2id are the only supported variants. When using a string to initialize the Hasher, a mathematical expression can be used to configure memory settings (ie `64*1024`) so kibibyte values do not need to be calculated beforehand.

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

Package math32 provides basic constants and mathematical functions related to the float32 type. This package does not guarantee bit-identical results across architectures.

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 kairos provides utilities for mathematical computations and analyses related to calculus and equations. It consists of three subpackages: integration, equation, and differentiation. The integration package offers methods to calculate definite integrals using different techniques. It includes the Trapezoidal Rule, Simpson's 1/3 Rule, Simpson's 3/8 Rule, and adaptive Simpson integration. The equation package provides methods to find the zero of a given function using various root-finding algorithms. The supported methods are Bisection, FalsePosition, NewtonRaphson, and Secant. The differentiation package offers methods to calculate derivatives of functions. It supports the calculation of the first derivative using two algorithms: Simple (based on the regular definition) and Symmetric (based on the symmetric definition). Additionally, it provides the ability to calculate arbitrary order derivatives using the HigherOrder method. The kairos package aims to assist users in performing mathematical computations with a focus on calculus and equation solving. It provides flexibility in choosing different methods depending on the specific requirements of the user's mathematical analysis. Note: Each subpackage within kairos has its own set of functions and structures, and users are encouraged to refer to the documentation of each subpackage for detailed information on usage and functionality.

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 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.

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.