Package decimal implements arbitrary-precision decimal floating-point arithmetic.

# decimal

[![godocb]][godoc]
[![travisb]][travis]
[![coverb]][cover]
[![goreportb]][goreport]

Package decimal implements arbitrary-precision decimal floating-point arithmetic
for Go.

## Rationale

How computers represent numbers internally is of no import for most
applications. However numerical applications that interract with humans must use
the same number base as humans. A very simple example is this:
https://play.golang.org/p/CVjiDCdhyoR where `1.1 + 0.11 = 1.2100000000000002`.
Not quite what one would expect.

There are other arbitrary-precision decimal floating-point libraries available,
but most use a binray representation of the mantissa (building on top of
`big.Int`), use external C libraries or are just plain slow.

This started out as an experiment on how an implementation using a pure decimal
representation would fare performance-wise. Secondary goals were to implement it
with an API that would match the Go standard library's math/big API (for better
or worse), and build it in such a way that it could some day be integrated into
the Go standard library.

Admittedly, this actually started out while doing some yak shaving, combined
with an NIH syndrom, but the result was well worth it.

## Features

The implementation is in essence a port of `big.Float` to decimal
floating-point, and the API is identical to that of `*big.Float` with the
exception of a few additional getters and setters, an FMA operation, and helper
functions to support implementation of missing low-level Decimal functionality
outside this package.

Unlike big.Float, the mantissa of a Decimal is stored in a little-endian Word
slice as "declets" of 9 or 19 decimal digits per 32 or 64 bits Word. All
arithmetic operations are performed directly in base 10\*\*9 or 10\*\*19 without
conversion to/from binary (see Performance below for a more in-depth discussion
of this choice).

While basic operations are slower than with a binary representation, some
operations like rounding (happening after every other operation!), or aligning
mantissae (in add/subtract) are much cheaper.

### Decimal and IEEE-754

The decimal package supports IEEE-754 rounding modes, signed zeros, infinity,
and an exactly rounded `Sqrt`. Other functions like Log will be implemented in a
future "math" sub-package. All results are rounded to the desired precision (no
manual rounding).

NaN values are not directly supported (like in `big.Float`). They can be seen as
"signaling NaNs" in IEEE-754 terminology, that is when a NaN is generated as a
result of an operation, it causes a panic. Applications that need to handle NaNs
gracefully can use Go's built-in panic/recover machanism to handle these
efficiently: NaNs cause a panic with an ErrNaN which can be tested to
distinguish NaNs from other causes of panic.

On the other hand, the [context](https://pkg.go.dev/github.com/db47h/decimal/context?tab=doc)
sub-package provides Contexts, which allow panic-free operation and a form of
quiet-NaNs whereby any NaN generated by an operation will make the context enter
into an error state. Further operations with the context will be no-ops until
(*Context).Err is called to check for errors.

Mantissae are always normalized, as a result, Decimals have a single possible
representation:

 0.1 <= mantissa < 1; d = mantissa × 10**exponent

so there is no notion of scale and no Quantize operation.

## TODO's and upcoming features

- Some math primitives are implemented in assembler. Right now only the amd64
 version is implemented, so we're still missing i386, arm, mips, power, riscV,
 and s390. The amd64 version could also use a good review (my assembly days
 date back to the Motorola MC68000). HELP WANTED!
- Complete decimal conversion tests
- A math sub-package that will provide at least the functions required by
 IEEE-754
- Some performance improvement ideas:
 - try a non-normalized mantissa.
 - in add, there are some cycles to shave off by combining the shift and add
 for simple cases (initial testing yielded mitigated results. Wait and see)

The decimal API is frozen, that is, any additional features will be added in
sub-packages.

Well, with the exception of `NewDecimal`: The current `integer mantissa` ×
`10**exp`, works well enough, but I'm not truly happy with it. Early versions
were using a float64 value as initializer, but that lead to unexpected side
effects where one would expect the number to be exact; not quite so as it turned
out, so it's not an option either.

## Performance

There are other full-featured arbitrary-precision decimal-floating point
libraries for Go out there, like [Eric Lagergren's decimal][eldecimal],
[CockroachDB's apd][apd], or [Shopspring's decimal][Shopspring].

For users only interested in performance here are the benchmark results of this
package versus the others using Eric's Pi test (times are in ns/op sorted from
fastest to slowest at 38 digits of precision):

| digits | 9 | 19 | 38 | 100 | 500 | 5000 |
|--------|--:|---:|---:|----:|----:|-----:|
| Eric's decimal (Go) | 6415 | 30254 | 65171 | 194263 | 1731528 | 89841923 |
| decimal | 12887 | 42720 | 100878 | 348865 | 4212811 | 342349031| 
| Eric's decimal (GDA) | 7124 | 39357 | 107720 | 392453 | 5421146 | 1175936547 |
| Shopspring's decimal | 39528 | 96261 | 204017 | 561321 | 3402562 | 97370022 |
| apd | 70833 | 301098 | 1262021 | 9859180 | 716558666 | ??? |

Note that Eric's decimal uses a separate logic for decimals < 1e19 (mantissa
stored in a single uint64), which explains its impressive perfomance for low
precisions.

In additions and subtractions the operands' mantissae need to be aligned
(shifted), this results in an additional multiplication by 10\*\*shift. In
implementations that use a binary representation of the matissa, this is faster
for shifts < 19, but performance degrades as shifts get higher. With a decimal
representation, this requires a multiplication as well but always by a single
Word, regardless of precision. 

Rounding happens after every operation in decimal and Eric's decimal in GDA mode
(not in Go mode, which explains its speed). Rounding requires a decimal shift
right, which translates to a division by 10\*\*shift. Again for small shifts,
binary representations are faster, but degrades even faster as precision gets
higher. On decimal implementations, this operation is quite fast since it
translates to a memcpy and a divmod of the least significant Word.

This explains why decimal's performace degrades slower than Eric's decimal-GDA
as precision increases, and why Eric's decimal in Go mode is so fast (no
rounding, which surprisingly counter-balances the high cost of mantissae
alignment).

## Caveats

The Float <-> Decimal conversion code needs some love.

The math/big API is designed to keep memory allocations to a minimum, but some
people find it cumbersome. Indeed it requires some practice to get used to it, 
so here's a quick rundown of what to do and not do:

Most APIs look like:

 func (z *Decimal) Add(x, y *Decimal) *Decimal

where the function sets the receiver `z` to the result of `a + b` and returns
'z'. The fact that the function returns the receiver is meant to allow chaining
of operations:

 s := new(Decimal).Mul(new(Decimal).Mul(r, r), pi) // d = r**2 * pi

If we don't care about what happens to `r`, we can just:

 s := new(Decimal).Mul(r.Mul(r, r), pi) // r *= r; d = r * pi

and save one memory allocation.

However, NEVER assign the result to a variable:

 d := new(Decimal).SetUint(4)
 d2 := d.Mul(d, d) // d2 == 16, but d == 16 as well!

Again, the sole intent behind returning the receiver is chaining of operations.
By assigning it to a variable, you will shoot yourself in the foot and kill
puppies in some far away land, so never assign the result of an operation!

However, feel free do do this:

 d.Mul(d, d) // d = d*d

The code will properly detect that the receiver is also one of the arguments
(possibly both), and allocate temporary storage space if (and only if)
necessary. Should this kind of construct fail, please file an issue.

## License

Simplified BSD license. See the [LICENSE] file.

The decimal package reuses a lot of code from the Go standard library, governed
by a 3-Clause BSD license. See the [LICENSE-go] file.

I'm aware that software using this package might have to include both licenses,
which might be a hassle; tracking licenses from dependencies is hard enough as
it is. I'd love to have a single license and hand over copyright to "The Go
authors", but the clause restricting use of the names of contributors for
endorsement of a derived work in the 3-Clause BSD license that Go uses is
problematic. i.e. I can't just use it as-is, mentioning Google Inc., as that
would be an infringement in itself (well, that's the way I see it, but IANAL).
On the other hand, any piece of software written in Go should include the Go
license anyway...

Any helpful insights are welcome.

[godoc]: https://pkg.go.dev/github.com/db47h/decimal?tab=doc
[godocb]: https://img.shields.io/badge/go.dev-reference-blue
[goreport]: https://goreportcard.com/report/github.com/db47h/decimal
[goreportb]: https://goreportcard.com/badge/github.com/db47h/decimal
[travis]: https://travis-ci.org/db47h/decimal
[travisb]: https://travis-ci.org/db47h/decimal.svg?branch=master
[cover]: https://coveralls.io/github/db47h/decimal?branch=master
[coverb]: https://coveralls.io/repos/github/db47h/decimal/badge.svg?branch=master
[eldecimal]: https://github.com/ericlagergren/decimal
[apd]: https://github.com/cockroachdb/apd
[Shopspring]: https://github.com/shopspring/decimal
[LICENSE]: https://github.com/db47h/decimal/blob/master/LICENSE
[LICENSE-go]: https://github.com/db47h/decimal/blob/master/LICENSE-go

decimal

Simple floating point arithmetic expression evaluator.

evaler
======

[![Build Status](https://travis-ci.org/soniah/evaler.svg?branch=master)](https://travis-ci.org/soniah/evaler)
[![Coverage](http://gocover.io/_badge/github.com/soniah/evaler)](http://gocover.io/github.com/soniah/evaler)
[![GoDoc](https://godoc.org/github.com/soniah/evaler?status.png)](http://godoc.org/github.com/soniah/evaler)
https://github.com/soniah/evaler

Package evaler implements a simple floating point arithmetic expression evaluator.

Evaler uses Dijkstra's [Shunting Yard algorithm](http://en.wikipedia.org/wiki/Shunting-yard_algorithm) to convert an
infix expression to [postfix/RPN format](http://en.wikipedia.org/wiki/Reverse_Polish_notation), then evaluates
the RPN expression. The implementation is adapted from a [Java implementation](http://willcode4beer.com/design.jsp?set=evalInfix). The results
are returned as a `*big.Rat`.

Usage
-----

```go
result, err := evaler.Eval("1+2")
```

Operators
---------

The operators supported are:

```+ - * / ^ ** () < > <= >= == !=```

(`^` and `**` are both exponent operators)

Logical operators like `<` (less than) or `>` (greater than) get lowest precedence,
all other precedence is as expected -
[BODMAS](http://www.mathsisfun.com/operation-order-bodmas.html).

Logical tests like `<` and `>` tests will evaluate to 0.0 for false and 1.0
for true, allowing expressions like:

```
3 * (1 < 2) # returns 3.0
3 * (1 > 2) # returns 0.0
```

Minus implements both binary and unary operations.

See `evaler_test.go` for more examples of using operators.

Trigonometric Operators
-----------------------

The trigonometric operators supported are:

```sin, cos, tan, ln, arcsin, arccos, arctan```

For example:

```
cos(1)
sin(2-1)
sin(1)+2**2
```

See `evaler_test.go` for more examples of using trigonometric operators.

Variables
---------

`EvalWithVariables()` allows variables to be passed into expressions,
for example evaluate `"x + 1"`, where `x=5`.

See `evaler_test.go` for more examples of using variables.

Issues
------

The `math/big` library doesn't have an exponent function `**` and implenting one
for `big.Rat` numbers is non-trivial. As a work around, arguments are converted
to float64's, the calculation is done using the `math.Pow()` function, the
result is converted to a `big.Rat` and placed back on the stack.

* floating point numbers missing leading digits (like `".5 * 2"`) are failing - PR's welcome

Documentation
-------------

http://godoc.org/github.com/soniah/evaler

There are also a number of utility functions e.g. `BigratToFloat()`,
`BigratToInt()` that may be useful when working with evaler.

Contributions
-------------

Contributions are welcome.

If you've never contributed to a Go project before here is an example workflow.

1. [fork this repo on the GitHub webpage](https://github.com/soniah/evaler/fork)
1. `go get github.com/soniah/evaler`
1. `cd $GOPATH/src/github.com/soniah/evaler`
1. `git remote rename origin upstream`
1. `git remote add origin git@github.com:<your-github-username>/evaler.git`
1. `git checkout -b development`
1. `git push -u origin development` (setup where you push to, check it works)

Author
------

Sonia Hamilton sonia@snowfrog.net

Dem Waffles dem-waffles@server.fake - trigonometric operators

License
-------

Modified BSD License (BSD-3)

Links
-----

[1] http://en.wikipedia.org/wiki/Shunting-yard_algorithm

[2] http://en.wikipedia.org/wiki/Reverse_Polish_notation

[3] http://willcode4beer.com/design.jsp?set=evalInfix

[4] http://www.mathsisfun.com/operation-order-bodmas.html

evaler

ewma

A set of libraries and tools for performing High Energy Physics analyses with ease.

hep
===

[![GitHub release](https://img.shields.io/github/release/go-hep/hep.svg)](https://github.com/go-hep/hep/releases)
[![go.dev reference](https://pkg.go.dev/badge/go-hep.org/x/hep)](https://pkg.go.dev/go-hep.org/x/hep)
[![CI](https://github.com/go-hep/hep/workflows/CI/badge.svg)](https://github.com/go-hep/hep/actions)
[![codecov](https://codecov.io/gh/go-hep/hep/branch/main/graph/badge.svg)](https://codecov.io/gh/go-hep/hep)
[![Go Report Card](https://goreportcard.com/badge/go-hep.org/x/hep)](https://goreportcard.com/report/go-hep.org/x/hep)
[![License](https://img.shields.io/badge/License-BSD--3-blue.svg)](https://go-hep.org/license)
[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.597940.svg)](https://doi.org/10.5281/zenodo.597940)
[![JOSS Paper](http://joss.theoj.org/papers/0b007c81073186f7c61f95ea26ad7971/status.svg)](http://joss.theoj.org/papers/0b007c81073186f7c61f95ea26ad7971)
[![Binder](https://mybinder.org/badge.svg)](https://mybinder.org/v2/gh/go-hep/binder/master)
[![TODOs](https://badgen.net/https/api.tickgit.com/badgen/github.com/go-hep/hep)](https://www.tickgit.com/browse?repo=github.com/go-hep/hep)

`hep` is a set of libraries and tools to perform High Energy Physics analyses with ease and [Go](https://golang.org)

See [go-hep.org](https://go-hep.org) for more informations.

## Forum

Drop an email at [~sbinet/go-hep@lists.sr.ht](mailto:~sbinet/go-hep@lists.sr.ht) or visit the web interface [lists.sr.ht/~sbinet/go-hep](https://lists.sr.ht/~sbinet/go-hep) to discuss about `Go-HEP` or ask for help.


## License

`hep` is released under the `BSD-3` license.

## Documentation

Documentation for `hep` is served by [GoDoc](https://godoc.org/go-hep.org/x/hep).

## Contributing

Guidelines for contributing to [go-hep](https://go-hep.org) are available here:
 [go-hep.org/contributing](https://go-hep.org/contributing)
 
### Contributors

This project exists thanks to all the people who contribute. 

# Motivations

Writing analyses in HEP involves many steps and one needs a few tools to
successfully carry out such an endeavour.
But - at minima - one needs to be able to read (and possibly write) ROOT files
to be able to interoperate with the rest of the HEP community or to insert
one's work into an already existing analysis pipeline.

Go-HEP provides this necessary interoperability layer, in the Go programming
language.
This allows physicists to leverage the great concurrency primitives of Go,
together with the surrounding tooling and software engineering ecosystem of Go,
to implement physics analyses.

## Content

Go-HEP currently sports the following packages:

- [go-hep.org/x/hep/brio](https://go-hep.org/x/hep/brio): a toolkit to generate serialization code
- [go-hep.org/x/hep/fads](https://go-hep.org/x/hep/fads): a fast detector simulation toolkit
- [go-hep.org/x/hep/fastjet](https://go-hep.org/x/hep/fastjet): a jet clustering algorithms package (WIP)
- [go-hep.org/x/hep/fit](https://go-hep.org/x/hep/fit): a fitting function toolkit (WIP)
- [go-hep.org/x/hep/fmom](https://go-hep.org/x/hep/fmom): a 4-vectors library
- [go-hep.org/x/hep/fwk](https://go-hep.org/x/hep/fwk): a concurrency-enabled framework
- [go-hep.org/x/hep/groot](https://go-hep.org/x/hep/groot): a pure [Go](https://golang.org) package for [ROOT](https://root.cern.ch) I/O (WIP)
- [go-hep.org/x/hep/hbook](https://go-hep.org/x/hep/hbook): histograms and n-tuples (WIP)
- [go-hep.org/x/hep/hplot](https://go-hep.org/x/hep/hplot): interactive plotting (WIP)
- [go-hep.org/x/hep/hepmc](https://go-hep.org/x/hep/hepmc): `HepMC` in pure [Go](https://golang.org) (EDM + I/O)
- [go-hep.org/x/hep/hepevt](https://go-hep.org/x/hep/hepevt): `HEPEVT` bindings
- [go-hep.org/x/hep/heppdt](https://go-hep.org/x/hep/heppdt): `HEP` particle data table
- [go-hep.org/x/hep/lcio](https://go-hep.org/x/hep/lcio): read/write support for `LCIO` event data model
- [go-hep.org/x/hep/lhef](https://go-hep.org/x/hep/lhef): Les Houches Event File format
- [go-hep.org/x/hep/rio](https://go-hep.org/x/hep/rio): `go-hep` record oriented I/O
- [go-hep.org/x/hep/sio](https://go-hep.org/x/hep/sio): basic, low-level, serial I/O used by `LCIO`
- [go-hep.org/x/hep/slha](https://go-hep.org/x/hep/slha): `SUSY` Les Houches Accord I/O
- [go-hep.org/x/hep/xrootd](https://go-hep.org/x/hep/xrootd): [XRootD](http://xrootd.org) client in pure [Go](https://golang.org)

## Installation

Go-HEP packages are installable via the `go get` command:

```sh
$ go get go-hep.org/x/hep/fads
```

Just select the package you are interested in and `go get` will take care of fetching, building and installing it, as well as its dependencies, recursively.


go-hep

Extended/multivariable ODE solver framework for event-based simulations with simple API.

[![Go Report Card](https://goreportcard.com/badge/github.com/soypat/godesim)](https://goreportcard.com/report/github.com/soypat/godesim)
[![go.dev reference](https://pkg.go.dev/badge/github.com/soypat/godesim)](https://pkg.go.dev/github.com/soypat/godesim)
[![codecov](https://codecov.io/gh/soypat/godesim/branch/main/graph/badge.svg)](https://codecov.io/gh/soypat/godesim/branch/main)
[![Awesome](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go/blob/master/README.md#science-and-data-analysis)

# godesim

Simulate complex systems with a simple API.
---

Wrangle non-linear differential equations while writing maintainable, simple code.

Note: [gonum/exp](https://github.com/gonum/exp) is still in early development but offers a more flexible and lightweight alternative to `godesim`'s full fledged simulator.

## Why Godesim?

ODE solvers seem to fill the niche of simple system solvers in
your numerical packages such as scipy's odeint/solve_ivp. 

Among these integrators there seems to be room for a solver that offers simulation interactivity such as modifying
the differential equations during simulation based on events such as a rocket stage separation.

## Installation

Requires Go.

```console
go get github.com/soypat/godesim
```

## Progress

Godesim is in early development and will naturally change as it is used more.
 The chart below shows some features that are planned or already part of godesim.

| Status legend | Planned | Started | Prototype | Stable | Mature |
| ------------- |:-------:|:-------:|:---------:|:------:|:------:|
| Legend symbol | ✖️ | 🏗️ | 🐞️ | 🚦️ | ✅️ |

| Features | Status | Notes |
| -------- |:------:| ----- |
| Non-linear solvers | 🚦️ | Suite of ODE solvers available. |
| Non-autonomous support | 🚦️ | `U` vector which need not a defined differential equation like `X` does.|
| Event driver | 🚦️ | Eventer interface implemented. |
| Stiff solver | 🚦️ | Newton-Raphson algorithm implemented and tested. |

<details><summary>Algorithms available and benchmarks</summary>

| Algorithm | Time/Operation| Memory/Op | Allocations/Op |
|-------------------|-----------------|---------------|-------------------|
|RK4 	| 1575 ns/op	 | 516 B/op	 | 12 allocs/op |
|RK5 	| 2351 ns/op	 | 692 B/op	 | 21 allocs/op |
|RKF45 	| 3229 ns/op	 | 780 B/op	 | 25 allocs/op |
|Newton-Raphson | 8616 ns/op	 | 4292 B/op	 | 92 allocs/op |
|Dormand-Prince 	| 4365 ns/op	 | 926 B/op	 | 32 allocs/op |

</details>

## [Examples](./_examples)

### Quadratic Solution

```go
// Declare your rate-of-change functions using state-space symbols
Dtheta := func(s state.State) float64 {
	return s.X("theta-dot")
}

DDtheta := func(s state.State) float64 {
 return 1
}
// Set the Simulation's differential equations and initial values and hit Begin!
sim := godesim.New() // Configurable with Simulation.SetConfig(godesim.Config{...})
sim.SetDiffFromMap(map[state.Symbol]state.Diff {
 "theta": Dtheta,
 "theta-dot": DDtheta,
})
sim.SetX0FromMap(map[state.Symbol]float64{
 "theta": 0,
 "theta-dot": 0,
})
sim.SetTimespan(0.0, 1.0, 10) // One second simulated
sim.Begin()
```

The above code solves the following system:

![](_assets/quadratic_eq.png)

for the domain `t=0` to `t=1.0` in 10 steps where `theta` and `theta-dot` are the `X` variables. The resulting curve is quadratic as the solution for this equation (for theta and theta-dot equal to zero) is

![](_assets/quadratic_eq_sol.png)

### How to obtain results
```go
// one can then obtain simulation results as float slices 
t := sim.Results("time")
theta := sim.Results("theta")
```


### Other examples

To run an example, navigate to it's directory (under [`examples`](./_examples)) then type `go run .` in console.

There are three simple examples which have been cooked up and left in `_examples` directory.
I've been having problems running Pixel on my machine so the simulation animations are still under work.

* [Simple pendulum](./_examples/simplePendulum)
* [Double pendulum exhibiting chaotic motion](./_examples/doublePendulum)
* [N-Body simulation](./_examples/n-body)

### Final notes
Future versions of gonum will have an ODE solver too. Ideally godesim would base it's algorithms on `gonum`'s implementation. See https://github.com/gonum/exp `ode` package.


## Contributing

Pull requests welcome!

This is my first library written for any programming language ever. I'll try to be fast on replying to pull-requests and issues.

godesim

# goent -  GO Implementation of Entropy Measures
[![GoDoc](https://godoc.org/github.com/kzahedi/goent?status.svg)](https://godoc.org/github.com/kzahedi/goent) [![Build Status](https://travis-ci.org/kzahedi/goent.svg?branch=master)](https://travis-ci.org/kzahedi/goent) [![Coverage Status](https://coveralls.io/repos/github/kzahedi/goent/badge.svg?branch=master)](https://coveralls.io/github/kzahedi/goent?branch=master) [![Go Report Card](https://goreportcard.com/badge/github.com/kzahedi/goent)](https://goreportcard.com/report/github.com/kzahedi/goent) [![Awesome](https://cdn.rawgit.com/sindresorhus/awesome/d7305f38d29fed78fa85652e3a63e154dd8e8829/media/badge.svg)](https://github.com/avelino/awesome-go)

## Measures for discrete state spaces
### Averaged measures
- Entropy
    - Shannon
    - Maximum Likelihood with Bias Correction
    - Horvitz-Thompson
    - Chao-Shen
- Conditional Entropy
- Mutual Information
- Conditional Mutual Information
- Max Entropy Estimations:
    - Iterative Scaling
- Information Decomposition (Bertschinger et al., 2014) for binary variables

- Morphological Computation measures have been moved to gomi
  https://github.com/kzahedi/gomi

### State-dependent measures
- Mutual Information
- Conditional Mutual Information
- Entropy (Shannon)

- Morphological Computation measures have been moved to gomi
  https://github.com/kzahedi/gomi


## Measures for continuous state spaces
### Averaged measures
- Kraskov-Stoegbauer-Grassberger, Algorithm 1
- Kraskov-Stoegbauer-Grassberger, Algorithm 2
- Frenzel-Pompe

- Morphological Computation measures have been moved to gomi
  https://github.com/kzahedi/gomi


### State-dependent measures
- Kraskov-Stoegbauer-Grassberger, Algorithm 1
- Kraskov-Stoegbauer-Grassberger, Algorithm 2
- Frenzel-Pompe

- Morphological Computation measures have been moved to gomi
  https://github.com/kzahedi/gomi


References:
- T. M. Cover and J. A. Thomas. Elements of Information Theory, Volume 2nd. Wiley, Hoboken, New Jersey, USA, 2006.
- I. Csiszar. i-divergence geometry of probability distributions and minimization problems. Ann. Probab., 3(1):146–158, 02 1975.
- A. Chao and T.-J. Shen. Nonparametric estimation of shannon’s index of diversity when there are unseen species in sample. Environmental and Ecological Statistics, 10(4):429–443, 2003.
- S. Frenzel and B. Pompe. Partial mutual information for coupling analysis of multivariate time series. Phys. Rev. Lett., 99:204101, Nov 2007.
- A. Kraskov, H. Stoegbauer, and P. Grassberger. Estimating mutual information. Phys. Rev. E, 69:066138, Jun 2004.
Bertschinger2013aQuantifying
- N. Bertschinger, J. Rauh, E. Olbrich, J. Jost, and N. Ay, Quantifying unique information, CoRR, 2013



goent

A golang generic graph library that provides mathematical graph-theory and algorithms.

![build](https://github.com/hmdsefi/gograph/actions/workflows/build.yml/badge.svg)
[![Go Report Card](https://goreportcard.com/badge/github.com/hmdsefi/gograph)](https://goreportcard.com/report/github.com/hmdsefi/gograph)
[![codecov](https://codecov.io/gh/hmdsefi/gograph/branch/master/graph/badge.svg?token=BstHl9wXTN)](https://codecov.io/gh/hmdsefi/gograph)
[![Go Reference](https://pkg.go.dev/badge/github.com/hmdsefi/gograph.svg)](https://pkg.go.dev/github.com/hmdsefi/gograph)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go#science-and-data-analysis)
# gograph

<img alt="golang generic graph package" src="https://user-images.githubusercontent.com/11541936/221823924-358994d2-44ff-4236-bbc8-b404de62293e.png" style="width:40%" align="right" title="gograph"/>
 
 
GoGraph is a lightweight, efficient, and easy-to-use graph data structure
implementation written in Go. It provides a versatile framework for representing 
graphs and performing various operations on them, making it ideal for both
educational purposes and practical applications.
 

## Table of Contents

* [Install](#Install)
* [How to Use](#How-to-Use)
 * [Graph](#Graph)
 * [Directed](#Directed)
 * [Acyclic](#Acyclic)
 * [Undirected](#Undirected)
 * [Weighted](#Weighted)
 * [Traverse](#Traverse)
 * [Connectivity](https://github.com/hmdsefi/gograph/tree/master/connectivity#gograph---connectivity)
 * [Shortest Path]()
 * [Dijkstra](https://github.com/hmdsefi/gograph/blob/master/path/dijkstra.md)
 * [Bellman-Ford](https://github.com/hmdsefi/gograph/blob/master/path/bellman-ford.md)
 * [Floyd-Warshall](https://github.com/hmdsefi/gograph/blob/master/path/floyd-warshall.md)
* [License](#License)

## Install

Use `go get` command to get the latest version of the `gograph`:

```shell
go get github.com/hmdsefi/gograph
```

Then you can use import the `gograph` to your code:

```go
package main

import "github.com/hmdsefi/gograph"
```

## How to Use

### Graph

`gograph` contains the `Graph[T comparable]` interface that provides all needed APIs to
manage a graph. All the supported graph types in `gograph` library implemented this interface.

```go
type Graph[T comparable] interface {
GraphType

AddEdge(from, to *Vertex[T], options ...EdgeOptionFunc) (*Edge[T], error)
GetAllEdges(from, to *Vertex[T]) []*Edge[T]
GetEdge(from, to *Vertex[T]) *Edge[T]
EdgesOf(v *Vertex[T]) []*Edge[T]
RemoveEdges(edges ...*Edge[T])
AddVertexByLabel(label T, options ...VertexOptionFunc) *Vertex[T]
AddVertex(v *Vertex[T])
GetVertexByID(label T) *Vertex[T]
GetAllVerticesByID(label ...T) []*Vertex[T]
GetAllVertices() []*Vertex[T]
RemoveVertices(vertices ...*Vertex[T])
ContainsEdge(from, to *Vertex[T]) bool
ContainsVertex(v *Vertex[T]) bool
}
```

The generic type of the `T` in `Graph` interface represents the vertex label. The type of `T`
should be comparable. You cannot use slices and function types for `T`.

#### Directed

![directed-graph](https://user-images.githubusercontent.com/11541936/221904292-face2083-16da-491f-a339-2164b7040264.png)

```go
graph := New[int](gograph.Directed())

graph.AddEdge(gograph.NewVertex(1), gograph.NewVertex(2))
graph.AddEdge(gograph.NewVertex(1), gograph.NewVertex(3))
graph.AddEdge(gograph.NewVertex(2), gograph.NewVertex(2))
graph.AddEdge(gograph.NewVertex(3), gograph.NewVertex(4))
graph.AddEdge(gograph.NewVertex(4), gograph.NewVertex(5))
graph.AddEdge(gograph.NewVertex(5), gograph.NewVertex(6))
```

#### Acyclic

![acyclic-graph](https://user-images.githubusercontent.com/11541936/221911652-ce2dfb5f-5547-4f26-8412-94ad9124d4fa.png)

```go
graph := New[int](gograph.Directed())

graph.AddEdge(gograph.NewVertex(1), gograph.NewVertex(2))
graph.AddEdge(gograph.NewVertex(2), gograph.NewVertex(3))
_, err := graph.AddEdge(gograph.NewVertex(3), gograph.NewVertex(1))
if err != nil {
// do something
}
```

#### Undirected

![undirected-graph](https://user-images.githubusercontent.com/11541936/221908261-a009049d-2b71-46c3-9026-faa4dcc2a693.png)

```go
// by default graph is undirected
graph := New[string]()

graph.AddEdge(gograph.NewVertex("A"), gograph.NewVertex("B"))
graph.AddEdge(gograph.NewVertex("A"), gograph.NewVertex("D"))
graph.AddEdge(gograph.NewVertex("B"), gograph.NewVertex("C"))
graph.AddEdge(gograph.NewVertex("B"), gograph.NewVertex("D"))
```

#### Weighted

![weighted-edge](https://user-images.githubusercontent.com/11541936/221908269-b6db15fb-6104-49d9-b9b9-acc062d94e4a.png)

```go
graph := New[string]()

vA := gograph.AddVertexByLabel("A")
vB := gograph.AddVertexByLabel("B")
vC := gograph.AddVertexByLabel("C")
vD := gograph.AddVertexByLabel("D")

graph.AddEdge(vA, vB, gograph.WithEdgeWeight(4))
graph.AddEdge(vA, vD, gograph.WithEdgeWeight(3))
graph.AddEdge(vB, vC, gograph.WithEdgeWeight(3))
graph.AddEdge(vB, vD, gograph.WithEdgeWeight(1))
graph.AddEdge(vC, vD, gograph.WithEdgeWeight(2))
```

![weighted-vertex](https://user-images.githubusercontent.com/11541936/221908278-83f3138d-8b28-4c38-825a-627a46d65294.png)
```go
graph := New[string]()
vA := gograph.AddVertexByLabel("A", gograph.WithVertexWeight(3))
vB := gograph.AddVertexByLabel("B", gograph.WithVertexWeight(2))
vC := gograph.AddVertexByLabel("C", gograph.WithVertexWeight(4))

graph.AddEdge(vA, vB)
graph.AddEdge(vB, vC)
```

### Traverse
Traverse package provides the iterator interface that guarantees all the algorithm export the same APIs:
```go
type Iterator[T comparable] interface {
	HasNext() bool
	Next() *gograph.Vertex[T]
	Iterate(func(v *gograph.Vertex[T]) error) error
	Reset()
}
```

This package contains the following iterators:
- [Breadth-First iterator](https://github.com/hmdsefi/gograph/tree/master/traverse#BFS)
- [Depth-First iterator](https://github.com/hmdsefi/gograph/tree/master/traverse#DFS)
- [Topological iterator](https://github.com/hmdsefi/gograph/tree/master/traverse#Topological-Sort)
- [Closest-First iterator](https://github.com/hmdsefi/gograph/tree/master/traverse#Closest-First)
- [Random Walk iterator](https://github.com/hmdsefi/gograph/tree/master/traverse#random-walk)

## License

Apache License, please see [LICENSE](https://github.com/hmdsefi/gograph/blob/master/LICENSE) for details.

gograph

gohistogram

Ordinary differential equation (ODE) solver which supports extended states and channel-based iteration stop conditions.

# ode
An [ordinary differential equation](https://en.wikipedia.org/wiki/Ordinary_differential_equation) solving library in golang.

[![Build Status](https://travis-ci.org/ChristopherRabotin/ode.svg?branch=master)](https://travis-ci.org/ChristopherRabotin/ode) [![Coverage Status](https://coveralls.io/repos/ChristopherRabotin/ode/badge.svg?branch=master&service=github)](https://coveralls.io/github/ChristopherRabotin/ode?branch=master)
[![goreport](https://goreportcard.com/badge/github.com/ChristopherRabotin/ode)](https://goreportcard.com/report/github.com/ChristopherRabotin/ode)

# Features
+ Multi-dimensional state vector (i.e. extended states)
+ Channel based stopping condition, which takes full advantage of [goroutines](https://en.wikipedia.org/wiki/Go_(programming_language#Concurrency)
+ Trivial usage (cf. the examples directory)
+ Easily expendable to other ODE solving methods

# Numerical methods
- [x] [RK4](https://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods#The_Runge.E2.80.93Kutta_method)
- [ ] [Dormant-Prince](https://en.wikipedia.org/wiki/Dormand%E2%80%93Prince_method)


Implementation of the "Bailey-Borwein-Plouffe" algorithm for the hexadecimal number Pi.

# PiHex
PiHex Library generates a hexadecimal number sequence in the number Pi in the range from 0 to 1.0e10000000. To calculate using "Bailey-Borwein-Plouffe" algorithm, instructions that was published by David H. Bailey September 17, 2006.

[![API documentation](https://godoc.org/github.com/claygod/PiHex?status.svg)](https://godoc.org/github.com/claygod/PiHex)
[![Go Report Card](https://goreportcard.com/badge/github.com/claygod/PiHex)](https://goreportcard.com/report/github.com/claygod/PiHex)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge-flat.svg)](https://github.com/avelino/awesome-go)

# Usage

An example of using the PiHex Library:
```go
package main

import (
	"fmt"
	"github.com/claygod/PiHex"
)

func main() {
	pi := PiHex.New()
	fmt.Print("The first 9 digits of Pi (hexadecimal): ", pi.Get(0, 9))
}
```

# Settings

In the configuration file, you can change the constant STEP. This constant determines the amount generated in one step numbers. The reduction leads to a constant increase in the operating time of the program.

Attention! This constant can not be more than 9! Limitation due to the 64-bit library architecture.

The configuration file [config.go](https://github.com/claygod/PiHex/blob/master/ph_config.go)

# Perfomance

To optimize the run-time program, highly loaded sections of the library are performed in parallel (4 goroutines).

# API

Methods:
-  *New* - create a new PiHex
-  *Get* - receiving a sequence of hexadecimal digits starting at the specified position and in the right quantity.

Example:
```go
pi := PiHex.New()
x :=  pi.Get(1000, 5)
```

# Algorithm

The Bailey–Borwein–Plouffe formula (BBP formula) is a spigot algorithm for computing the nth binary digit of Pi using base 16 math. The formula can directly calculate the value of any given digit of π without calculating the preceding digits. The BBP is a summation-style formula that was discovered in 1995 by Simon Plouffe and was named after the authors of the paper in which the formula was published, David H. Bailey, Peter Borwein, and Simon Plouffe.

# Implementation

Plays Library is based on the publication "The BBP Algorithm for Pi" of David H. Bailey on September 17, 2006: http://www.davidhbailey.com/dhbpapers/bbp-alg.pdf

## Copyright

Copyright © 2017-2024 Eduard Sesigin. All rights reserved. Contacts: claygod@yandex.ru


The Best Go Libraries For Science and Data Analysis - Libraries for scientific computing and data analyzing. (11)