Gorgonia is a library that helps facilitate machine learning in Go.

Overview

Logo

GoDoc GitHub version test and build Coverage Status Go Report Card unstable

Gorgonia is a library that helps facilitate machine learning in Go. Write and evaluate mathematical equations involving multidimensional arrays easily. If this sounds like Theano or TensorFlow, it's because the idea is quite similar. Specifically, the library is pretty low-level, like Theano, but has higher goals like Tensorflow.

Gorgonia:

  • Can perform automatic differentiation
  • Can perform symbolic differentiation
  • Can perform gradient descent optimizations
  • Can perform numerical stabilization
  • Provides a number of convenience functions to help create neural networks
  • Is fairly quick (comparable to Theano and Tensorflow's speed)
  • Supports CUDA/GPGPU computation (OpenCL not yet supported, send a pull request)
  • Will support distributed computing

Goals

The primary goal for Gorgonia is to be a highly performant machine learning/graph computation-based library that can scale across multiple machines. It should bring the appeal of Go (simple compilation and deployment process) to the ML world. It's a long way from there currently, however, the baby steps are already there.

The secondary goal for Gorgonia is to provide a platform for exploration for non-standard deep-learning and neural network related things. This includes things like neo-hebbian learning, corner-cutting algorithms, evolutionary algorithms and the like.

Why Use Gorgonia?

The main reason to use Gorgonia is developer comfort. If you're using a Go stack extensively, now you have access to the ability to create production-ready machine learning systems in an environment that you are already familiar and comfortable with.

ML/AI at large is usually split into two stages: the experimental stage where one builds various models, test and retest; and the deployed state where a model after being tested and played with, is deployed. This necessitate different roles like data scientist and data engineer.

Typically the two phases have different tools: Python (PyTorch, etc) is commonly used for the experimental stage, and then the model is rewritten in some more performant language like C++ (using dlib, mlpack etc). Of course, nowadays the gap is closing and people frequently share the tools between them. Tensorflow is one such tool that bridges the gap.

Gorgonia aims to do the same, but for the Go environment. Gorgonia is currently fairly performant - its speeds are comparable to PyTorch's and Tensorflow's CPU implementations. GPU implementations are a bit finnicky to compare due to the heavy cgo tax, but rest assured that this is an area of active improvement.

Getting started

Installation

The package is go-gettable: go get -u gorgonia.org/gorgonia.

Gorgonia is compatible with go modules.

Documentation

Up-to-date documentation, references and tutorials are present on the official Gorgonia website at https://gorgonia.org.

Keeping Updated

Gorgonia's project has a Slack channel on gopherslack, as well as a Twitter account. Official updates and announcements will be posted to those two sites.

Usage

Gorgonia works by creating a computation graph, and then executing it. Think of it as a programming language, but is limited to mathematical functions, and has no branching capability (no if/then or loops). In fact this is the dominant paradigm that the user should be used to thinking about. The computation graph is an AST.

Microsoft's CNTK, with its BrainScript, is perhaps the best at exemplifying the idea that building of a computation graph and running of the computation graphs are different things, and that the user should be in different modes of thoughts when going about them.

Whilst Gorgonia's implementation doesn't enforce the separation of thought as far as CNTK's BrainScript does, the syntax does help a little bit.

Here's an example - say you want to define a math expression z = x + y. Here's how you'd do it:

package gorgonia_test

import (
	"fmt"
	"log"

	. "gorgonia.org/gorgonia"
)

// Basic example of representing mathematical equations as graphs.
//
// In this example, we want to represent the following equation
//		z = x + y
func Example_basic() {
	g := NewGraph()

	var x, y, z *Node
	var err error

	// define the expression
	x = NewScalar(g, Float64, WithName("x"))
	y = NewScalar(g, Float64, WithName("y"))
	if z, err = Add(x, y); err != nil {
		log.Fatal(err)
	}

	// create a VM to run the program on
	machine := NewTapeMachine(g)
	defer machine.Close()

	// set initial values then run
	Let(x, 2.0)
	Let(y, 2.5)
	if err = machine.RunAll(); err != nil {
		log.Fatal(err)
	}

	fmt.Printf("%v", z.Value())
	// Output: 4.5
}

You might note that it's a little more verbose than other packages of similar nature. For example, instead of compiling to a callable function, Gorgonia specifically compiles into a *program which requires a *TapeMachine to run. It also requires manual a Let(...) call.

The author would like to contend that this is a Good Thing - to shift one's thinking to a machine-based thinking. It helps a lot in figuring out where things might go wrong.

Additionally, there are no support for branching - that is to say there are no conditionals (if/else) or loops. The aim is not to build a Turing-complete computer.


More examples are present in the example subfolder of the project, and step-by-step tutorials are present on the main website

Using CUDA

Gorgonia comes with CUDA support out of the box. Please see the reference documentation about how cuda works on the Gorgonia.org website, or jump to the tutorial.

About Gorgonia's development process

Versioning

We use semver 2.0.0 for our versioning. Before 1.0, Gorgonia's APIs are expected to change quite a bit. API is defined by the exported functions, variables and methods. For the developers' sanity, there are minor differences to semver that we will apply prior to version 1.0. They are enumerated below:

  • The MINOR number will be incremented every time there is a deleterious break in API. This means any deletion, or any change in function signature or interface methods will lead to a change in MINOR number.
  • Additive changes will NOT change the MINOR version number prior to version 1.0. This means that if new functionality were added that does not break the way you use Gorgonia, there will not be an increment in the MINOR version. There will be an increment in the PATCH version.

API Stability

Gorgonia's API is as of right now, not considered stable. It will be stable from version 1.0 forwards.

Go Version Support

Gorgonia supports 2 versions below the Master branch of Go. This means Gorgonia will support the current released version of Go, and up to 4 previous versions - providing something doesn't break. Where possible a shim will be provided (for things like new sort APIs or math/bits which came out in Go 1.9).

The current version of Go is 1.13.1. The earliest version Gorgonia supports is Go 1.11.x but Gonum supports only 1.12+. Therefore, the minimum Go version to run the master branch is Go > 1.12.

Hardware and OS supported

Gorgonia runs on :

  • linux/AMD64
  • linux/ARM7
  • linux/ARM64
  • win32/AMD64
  • darwin/AMD64
  • freeBSD/AMD64

If you have tested gorgonia on other platform, please update this list.

Hardware acceleration

Gorgonia use some pure assembler instructions to accelerate somes mathematical operations. Unfortunately, only amd64 is supported.

Contributing

Obviously since you are most probably reading this on Github, Github will form the major part of the workflow for contributing to this package.

See also: CONTRIBUTING.md

Contributors and Significant Contributors

All contributions are welcome. However, there is a new class of contributor, called Significant Contributors.

A Significant Contributor is one who has shown deep understanding of how the library works and/or its environs. Here are examples of what constitutes a Significant Contribution:

  • Wrote significant amounts of documentation pertaining to why/the mechanics of particular functions/methods and how the different parts affect one another
  • Wrote code, and tests around the more intricately connected parts of Gorgonia
  • Wrote code and tests, and have at least 5 pull requests accepted
  • Provided expert analysis on parts of the package (for example, you may be a floating point operations expert who optimized one function)
  • Answered at least 10 support questions.

Significant Contributors list will be updated once a month (if anyone even uses Gorgonia that is).

How To Get Support

The best way of support right now is to open a ticket on Github.

Frequently Asked Questions

Why are there seemingly random runtime.GC() calls in the tests?

The answer to this is simple - the design of the package uses CUDA in a particular way: specifically, a CUDA device and context is tied to a VM, instead of at the package level. This means for every VM created, a different CUDA context is created per device per VM. This way all the operations will play nicely with other applications that may be using CUDA (this needs to be stress-tested, however).

The CUDA contexts are only destroyed when the VM gets garbage collected (with the help of a finalizer function). In the tests, about 100 VMs get created, and garbage collection for the most part can be considered random. This leads to cases where the GPU runs out of memory as there are too many contexts being used.

Therefore at the end of any tests that may use GPU, a runtime.GC() call is made to force garbage collection, freeing GPU memories.

In production, one is unlikely to start that many VMs, therefore it's not really a problem. If there is, open a ticket on Github, and we'll look into adding a Finish() method for the VMs.

Licence

Gorgonia is licenced under a variant of Apache 2.0. It's for all intents and purposes the same as the Apache 2.0 Licence, with the exception of not being able to commercially profit directly from the package unless you're a Significant Contributor (for example, providing commercial support for the package). It's perfectly fine to profit directly from a derivative of Gorgonia (for example, if you use Gorgonia as a library in your product)

Everyone is still allowed to use Gorgonia for commercial purposes (example: using it in a software for your business).

Dependencies

There are very few dependencies that Gorgonia uses - and they're all pretty stable, so as of now there isn't a need for vendoring tools. These are the list of external packages that Gorgonia calls, ranked in order of reliance that this package has (subpackages are omitted):

Package Used For Vitality Notes Licence
gonum/graph Sorting *ExprGraph Vital. Removal means Gorgonia will not work Development of Gorgonia is committed to keeping up with the most updated version gonum license (MIT/BSD-like)
gonum/blas Tensor subpackage linear algebra operations Vital. Removal means Gorgonial will not work Development of Gorgonia is committed to keeping up with the most updated version gonum license (MIT/BSD-like)
cu CUDA drivers Needed for CUDA operations Same maintainer as Gorgonia MIT/BSD-like
math32 float32 operations Can be replaced by float32(math.XXX(float64(x))) Same maintainer as Gorgonia, same API as the built in math package MIT/BSD-like
hm Type system for Gorgonia Gorgonia's graphs are pretty tightly coupled with the type system Same maintainer as Gorgonia MIT/BSD-like
vecf64 optimized []float64 operations Can be generated in the tensor/genlib package. However, plenty of optimizations have been made/will be made Same maintainer as Gorgonia MIT/BSD-like
vecf32 optimized []float32 operations Can be generated in the tensor/genlib package. However, plenty of optimizations have been made/will be made Same maintainer as Gorgonia MIT/BSD-like
set Various set operations Can be easily replaced Stable API for the past 1 year set licence (MIT/BSD-like)
gographviz Used for printing graphs Graph printing is only vital to debugging. Gorgonia can survive without, but with a major (but arguably nonvital) feature loss Last update 12th April 2017 gographviz licence (Apache 2.0)
rng Used to implement helper functions to generate initial weights Can be replaced fairly easily. Gorgonia can do without the convenience functions too rng licence (Apache 2.0)
errors Error wrapping Gorgonia won't die without it. In fact Gorgonia has also used goerrors/errors in the past. Stable API for the past 6 months errors licence (MIT/BSD-like)
gonum/mat Compatibility between Tensor and Gonum's Matrix Development of Gorgonia is committed to keeping up with the most updated version gonum license (MIT/BSD-like)
testify/assert Testing Can do without but will be a massive pain in the ass to test testify licence (MIT/BSD-like)

Various Other Copyright Notices

These are the packages and libraries which inspired and were adapted from in the process of writing Gorgonia (the Go packages that were used were already declared above):

Source How it's Used Licence
Numpy Inspired large portions. Directly adapted algorithms for a few methods (explicitly labelled in the docs) MIT/BSD-like. Numpy Licence
Theano Inspired large portions. (Unsure: number of directly adapted algorithms) MIT/BSD-like Theano's licence
Caffe im2col and col2im directly taken from Caffe. Convolution algorithms inspired by the original Caffee methods Caffe Licence
Issues
  • Masked tensor

    Masked tensor

    As promised, set about trying to implement basic masked array functionality.

    To begin with, created a new iterator type 'MultIterator', which is designed to iterate over multiple arrays simultaneously, with the same syntax as 'FlatIterator', to allow switching between them (it uses an array of FlatIterators internally). For single non-masked arrays, MultIterator is about 20% slower than FlatIterator. However, it only calculates offsets for unique shapes/stride combinations, and so when indexing arrays of same shape, a single FlatIterator is shared between them all, allowing significant compute savings.

    func BenchmarkFlatIteratorMulti6(b *testing.B) {
    	ap := make([]*AP, 6)
    	for j := 0; j < 6; j++ {
    		ap[j] = NewAP(Shape{30, 60, 10}, []int{1000000, 15000, 50})
    	}
    	it := NewMultIterator(ap...)
    	for n := 0; n < b.N; n++ {
    		for _, err := it.Next(); err == nil; _, err = it.Next() {
    		}
    		it.Reset()
    	}
    	DestroyMultIterator(it)
    }
    

    You could create a MultiIterator from tensors directly

    T1 := New(Of(Float64), WithShape(3, 20), WithMaskStrides([]bool{true, true}))
    T2 := New(Of(Float64), WithShape(3, 20), WithMaskStrides([]int{20,1}))
    T3 := New(Of(Float64), FromScalar(7))
    it := MultIteratorFromDense(T1, T2, T3)
    

    It also means that you don't have to worry when creating functions of multiple arguments in which the same array could be repeated as different arguments - in which case naive use of FlatIterator could cause that array to be iterated multiple times in a single for loop iteration - with MultIterator that can not happen.

    As for the mask, for the time being I opted to simply add a []bool to the Dense struct, and an additional stride int to AP. MultIterator supports masked operations, such as NextValid() or NextInvalid(), in addition to Next(). Examples of usage can be seen in dense_maskmethods_test.go and iterator_test.go.

    func TestMaskedIteration(t *testing.T) {
    	assert := assert.New(t)
    	T := New(Of(Float64), WithShape(2, 3, 4, 5))
    	assert.True(len(T.mask) < 1)
    	dataF64 := T.Data().([]float64)
    	for i := range dataF64 {
    		dataF64[i] = float64(i)
    	}
    	for i := 0; i < 5; i++ {
    		T.MaskedEqual(float64(i) * 10.0)
    	}
    
    	it := MultIteratorFromDense(T)
    
    	j := 0
    	for _, err := it.Next(); err == nil; _, err = it.Next() {
    		j++
    	}
    	it.Reset()
    	assert.True(j == 120)
    
    	j = 0
    	for _, err := it.NextValid(); err == nil; _, err = it.NextValid() {
    		j++
    	}
    	it.Reset()
    	assert.True(j == 115)
    
    	j = 0
    	for _, err := it.NextInvalid(); err == nil; _, err = it.NextInvalid() {
    		j++
    	}
    	it.Reset()
    	assert.True(j == 5)
    }
    

    I did not want to spend too much time going further before agreeing on the basics. While I show some basic mask setting operations in dense_maskmethods.go, I only do this for float64 tensors as a demonstration - the functionality would have to be implemented in genlib at some point which would take me sometime to do properly as this is my first time using text/template.

    I also did not optimize masked iteration, there are smarter ways to find next valid/valid, e.g. by processing >=8 bytes at once, but I figure that it's best to leave that until the structure is agreed upon.

    opened by kabaka0 37
  • [WIP] work on getting the gorgonia to use the errors package

    [WIP] work on getting the gorgonia to use the errors package

    This is the work in progress for the integration of the errors package into gorgonia which addressed #46

    As this work touches a large surface area, I wanted to open this branch early to mark the progress, so that I can get some feedback (if any) about the approach.

    once all the work is done, I will be squashing all the commits into one with a meaningful commit message to keep everything in master clean, so please note that I may be doing a force push at some point.

    opened by NDari 36
  • [fix] Using the iterator of the new Gonum API

    [fix] Using the iterator of the new Gonum API

    This change allows the v0.9.2-working2 branch to compile and work with the latest evolution of the Gonum API. The implementation relies on the OrderedNode implementation of the iterator package.

    opened by owulveryck 31
  • The Broadcast function is exported but not usable outside of the package

    The Broadcast function is exported but not usable outside of the package

    I need to implement a "add" operator for two tensors with a broadcasting mechanism as described here.

    The Broadcast function seems to be a perfect fit for this. Moreover, the test is partially implementing what I am trying to do. But nor the ʘBinaryOperatorType or any other binOp implementations are exported.

    Therefore the Broadcast function can only be used within the Gorgonia package.

    Maybe we should make it private to avoid confusion in the documentation and expose "Broadcasted version" of some operators instead? What do you think?

    question ux 
    opened by owulveryck 17
  • Iterator.Chan() considered harmful

    Iterator.Chan() considered harmful

    sketch space for describing how to create a chan int of negative length, and how to reproduce it

    Background/Context of the Issue

    Gorgonia is a library for representing and executing mathematical equations, and performing automatic differentiation. It's like Tensorflow and PyTorch for Go. It's currently undergoing some major internal refactor (that will not affect the public APIs much)

    I was improving the backend tensor package by splitting up the data structure into a data structure + pluggable execution engine, instead of having built in methods (see also #128). The reasons are so that it's easier to change out execution backends (CPU, GPU... even a network CPU (actual experiment I did was to run a small neural network on a Raspberry Pi and all computation is offshored to my workstation, and vice versa, which turned out to be a supremely bad idea)).

    Another reason was due to the fact that I wanted to do some experiments at my work which use algorithms that involve sparse tensors (see also #127) for matrix factorization tasks.

    Lastly, I wanted to clean up the generics support of the tensor package. The current master branch of the tensor package had a lot of code to support arbitrary tensor types. With the split of execution engines and data structure, more of this support could be offloaded to the execution engine instead. This package provides a default execution engine (type StdEng struct{}: https://github.com/chewxy/gorgonia/blob/debugrace/tensor/defaultengine.go), which could be extended (example: https://github.com/chewxy/gorgonia/blob/debugrace/tensor/example_extension_test.go) . The idea was to have an internal/execution package which held all the code for the default execution engine.

    Data Structures

    The most fundamental data structure is storage.Header, which is an analogue for a Go slice: it's a three word structure. It's chosen because it is a ridiculously simple structure can store Go-allocated memory, C-allocated memory and device-allocated memory (like CUDA).

    On top of storage.Header is tensor.array. It's essentially a storage.Header with an additional field for the type. The v field will eventually be phased out once the refactor is complete.

    On top of tensor.array are the various implementations of tensor.Tensor. Chief amongst these is the tensor.Dense struct. Essentially it's a tensor.array coupled with some access patterns and meta information.

    Access to the data in the tensor.Tensor can be achieved by use of Iterators. The Iterator basically assumes that the data is held in a flat slice, and returns the next index on the slice. There are auxiliary methods like NextValidity to handle special case tensors like masked tensors, where some elements are masked from operations.

    The bug happens in the Chan method of the FlatIterator type.

    How to reproduce

    The branch where the bug is known to exist is the debugrace branch, which can be found here: 1dee6d2 .

    1. git checkout debugrace
    2. Run tests with various GOMAXPROCS like so: GOMAXPROCS=1 go test -run=. . Try it with various GOMAXPROCS, one of them is bound to trigger an issue.
    3. The test won't panic, because I have added a recover statement here https://github.com/chewxy/gorgonia/blob/debugrace/tensor/dense_viewstack_specializations.go#L636. Removing the deferred function causes a index out of bounds panic.
    4. All the tests must be run to trigger the issue.
    5. The issue is found in the test for the Stack function: https://github.com/chewxy/gorgonia/blob/debugrace/tensor/dense_matop_test.go#L768 . If only the stack test is run (for example GOMAXPROCS=1 go test -run=Stack), it is unlikely the problem will show up (I wrote a tiny python script to run it as many times as possible with many GOMAXPROCS configurations and none of them caused an error).

    You should get something like this:

    image

    Environments

    I've managed to reproduce the issue on OS X, with Go 1.8 and on Ubuntu 16.10 with Go 1.8.2 and Go tip (whatever gvm thinks is Go tip). I've no access to Go on a windows box so I can't test it on Windows.

    Magic and Unsafe Use

    As part of the refactoring, there are a few magic bits being used. Here I attempt to list them all (may not be exhaustive):

    • The Go slice structure is re-implemented in https://github.com/chewxy/gorgonia/blob/debugrace/tensor/internal/storage/header.go. Note that here an unsafe.Pointer is used instead of the standard one like reflect.SliceHeader which stores a uintptr. This is due to the fact that I want Go to keep a reference to the actual slice. This may affect the runtime and memory allocation.. I'm not too sure.
    • //go:linkname is used in some internal packages (specific example here: https://github.com/chewxy/gorgonia/blob/debugrace/tensor/internal/execution/generic_arith_vv.go). It's basically just a rename of functions in github.com/chewxy/vecf32 and github.com/chewxy/vecf64. Those packages contain optional AVX/SSE related vector operations like arithmetics. However, those have to be manually invoked via a build tag. By default it uses go algorithms, not SSE/AVX operations.
    • //go:linkname is used in unsafe.go: https://github.com/chewxy/gorgonia/blob/debugrace/tensor/unsafe.go#L105. However it should be noted that memmove is never called as after some tests I decided it would be too unsafe to use (also explains why there are comments that say TODO: implement memmove.
    • There are several naughty pointer arithmetics at play:

    What I suspect

    I suspect that there may be some naughty things happening in memory (because it only happens when all the tests are run). The problem is I don't know exactly where to start looking.

    bug 
    opened by chewxy 17
  • Adopt

    Adopt "dep" as the official installation mechanism

    With the possible integration of the dep package manager into the Go toolchain, it may be worth it to adopt it as the official installation method for Gorgonia. There are a good bit of packages to install to fully utilize Gorgonia, which may scare people new to Go and/or programming in general.

    • [x] provide a Gopkg.toml with explicit versions of the libraries whenever possible
    • [x] provide a Gopkg.lock
    • [x] Add the vendor directory to the .gitignore file so that it is not checked in.
    • [ ] Provide an installation section in the readme showing how to use dep to install Gorgonia and how to test if your installation was successful.
    enhancement documentation 
    opened by NDari 17
  • 1.15.3

    1.15.3 "Import Cycle Not Allowed" on convnet example w/ Cuda

    Hello,

    I get the following error when trying to run the convnet cuda example.

    package command-line-arguments
    	imports gorgonia.org/gorgonia
    	imports gorgonia.org/gorgonia: import cycle not allowed
    

    My file structure is as below;

    ├── project
    │ ├── convnet.go
    │ └── cudamodules.go
    

    Note that if I roll back Go to 1.13.9 (Which is fine so by no means urgent), this error does not present itself.

    However... Without piggybacking too much of this issue for another, when I run the following command in the project directory, on version 1.13.9, I get the following output which indefinitely hangs.

    >>>/usr/local/go-1.13/bin/go run -tags='cuda' .
    2020/10/21 10:03:07 Using CUDA build
    2020/10/21 10:03:07 gorgonia. true
    2020/10/21 10:03:08 p0 (100, 32, 14, 14)
    2020/10/21 10:03:08 p2 shape (100, 128, 3, 3)
    2020/10/21 10:03:08 r2 shape (100, 1152)
    2020/10/21 10:03:08 l2 shape (100, 1152) | (1152, 625)
    2020/10/21 10:03:08 l3 name Dropout 0.55(%15) :: Matrix float64 | a3 name ReLU(%14) :: Matrix float64
    2020/10/21 10:03:08 DONE
    2020/10/21 10:03:08 m.out.Shape (100, 10), y.Shape (100, 10)
    2020/10/21 10:03:08 Batches 600
    Epoch 0 0 / 600 [------------------------------------------------------]   0.00%
    

    Running nvidia-smi I can see it has allocated memory to it, but seems to just hang

    0      6477      C   /tmp/go-build071137485/b001/exe/goHide       470MiB
    

    It could be that i'm doing something wrong, but I build the cudamodules using the cudagen tool. The only strange thing is that I have to remove //+build cuda from the top of convnet.go prior to running the cudagen tool otherwise I get the following

    2020/10/21 10:07:50 failed to get name of package in working directory. Error: exit status 1. go list error: package .: build constraints exclude all Go files in /path/to/project. I then add it back in afterwards and it runs, but hangs as mentioned.

    Apologies if the latter is just me being a Go novice!

    opened by phillips96 13
  • Test broadcast add

    Test broadcast add

    See #301

    Note that this branch currently fails, but I believe that it is due an implementation error in the broadcasting. Specifically, I was unable to make the following operation:

    given a tensor a with shape (2,) and a tensor b with shape (2,2,2), broadcast-add them, such that the result c has shape (2,2,2). This stems from the fact that when I try to broadcast a into shape (2,2,2) (using left=[]byte{1, 2}) in the broadcastAdd, it panics.

    This situation is demonstrated on the second commit of this MR.

    This behavior is not consistent with when we do the same operation where b has shape (2,2) and a is broadcasted using left=[]byte{1}, which is valid (as per test named "vec-mat").

    Note that I am assuming that we are following the same rules as the broadcasting rules of numpy

    opened by jorgecarleitao 13
  • go get-u gorgonia assembly failed error

    go get-u gorgonia assembly failed error

    Hey guys, whenever I try to use go get gorgonia, I keep hitting the following error:

    gorgonia.org/gorgonia

    asm: asmins: illegal 64: 00000 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:7) MOVQ a+4(FP), SI asm: asmins: illegal in mode 32: 00000 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:7) MOVQ a+4(FP), SI (24 18) asm: asmins: illegal 64: 00005 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:8) MOVQ b+12(FP), CX asm: asmins: illegal in mode 32: 00005 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:8) MOVQ b+12(FP), CX (24 15) asm: asmins: illegal 64: 00010 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:9) MOVQ SI, AX asm: asmins: illegal in mode 32: 00010 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:9) MOVQ SI, AX (18 14) asm: asmins: illegal 64: 00013 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:10) CMPQ CX, $-1 asm: asmins: illegal in mode 32: 00013 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:10) CMPQ CX, $-1 (15 5) asm: asmins: illegal 64: 00019 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:13) CQO asm: asmins: illegal in mode 32: 00019 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:13) CQO (1 1) asm: asmins: illegal 64: 00021 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:14) IDIVQ CX asm: asmins: illegal in mode 32: 00021 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:14) IDIVQ CX (15 1) asm: asmins: illegal 64: 00024 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:15) MOVQ AX, q+20(FP) asm: asmins: illegal in mode 32: 00024 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:15) MOVQ AX, q+20(FP) (14 24) asm: asmins: illegal 64: 00029 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:16) MOVQ DX, r+28(FP) asm: asmins: illegal in mode 32: 00029 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:16) MOVQ DX, r+28(FP) (21 24) asm: asmins: illegal 64: 00035 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:20) NEGQ AX asm: asmins: illegal in mode 32: 00035 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:20) NEGQ AX (1 14) asm: asmins: illegal 64: 00038 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:21) MOVQ AX, q+20(FP) asm: asmins: illegal in mode 32: 00038 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:21) MOVQ AX, q+20(FP) (14 24) asm: asmins: illegal 64: 00043 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:22) MOVQ $0, r+28(FP) asm: asmins: illegal in mode 32: 00043 (C:\Users\manikandank\go\src\gorgonia.org\gorgonia\mathutils.s:22) MOVQ $0, r+28(FP) (2 24) asm: assembly failed

    bug 
    opened by casijoe5231 12
  • How to do a prediction after training

    How to do a prediction after training

    Hi,

    I have tried example code CONVNET. I am able to run it. After the program finish the training, is there a way to predict immediately?

    I have tried for few days without any luck. I could not find any sample code which is doing prediction after Training. Or saving and load the result after Training. Hope you can help me.

    func main() {
    	flag.Parse()
    	parseDtype()
    	rand.Seed(1337)
    
    	// intercept Ctrl+C
    	sigChan := make(chan os.Signal, 1)
    	signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
    	doneChan := make(chan bool, 1)
    
    	var inputs, targets tensor.Tensor
    	var err error
    
    	go func() {
    		log.Println(http.ListenAndServe("localhost:6060", nil))
    	}()
    
    	trainOn := *dataset
    	if inputs, targets, err = mnist.Load(trainOn, loc, dt); err != nil {
    		log.Fatal(err)
    	}
    
    	// the data is in (numExamples, 784).
    	// In order to use a convnet, we need to massage the data
    	// into this format (batchsize, numberOfChannels, height, width).
    	//
    	// This translates into (numExamples, 1, 28, 28).
    	//
    	// This is because the convolution operators actually understand height and width.
    	//
    	// The 1 indicates that there is only one channel (MNIST data is black and white).
    	numExamples := inputs.Shape()[0]
    	bs := *batchsize
    	// todo - check bs not 0
    
    	if err := inputs.Reshape(numExamples, 1, 28, 28); err != nil {
    		log.Fatal(err)
    	}
    	g := gorgonia.NewGraph()
    	x := gorgonia.NewTensor(g, dt, 4, gorgonia.WithShape(bs, 1, 28, 28), gorgonia.WithName("x"))
    	y := gorgonia.NewMatrix(g, dt, gorgonia.WithShape(bs, 10), gorgonia.WithName("y"))
    	m := newConvNet(g)
    	if err = m.fwd(x); err != nil {
    		log.Fatalf("%+v", err)
    	}
    	losses := gorgonia.Must(gorgonia.HadamardProd(m.out, y))
    	cost := gorgonia.Must(gorgonia.Mean(losses))
    	cost = gorgonia.Must(gorgonia.Neg(cost))
    
    	// we wanna track costs
    	var costVal gorgonia.Value
    	gorgonia.Read(cost, &costVal)
    
    	if _, err = gorgonia.Grad(cost, m.learnables()...); err != nil {
    		log.Fatal(err)
    	}
    
    	// debug
    	// ioutil.WriteFile("fullGraph.dot", []byte(g.ToDot()), 0644)
    	// prog, _, _ := gorgonia.Compile(g)
    	// log.Printf("%v", prog)
    	// logger := log.New(os.Stderr, "", 0)
    	// vm := gorgonia.NewTapeMachine(g, gorgonia.BindDualValues(m.learnables()...), gorgonia.WithLogger(logger), gorgonia.WithWatchlist())
    
    	vm := gorgonia.NewTapeMachine(g, gorgonia.BindDualValues(m.learnables()...))
    	solver := gorgonia.NewRMSPropSolver(gorgonia.WithBatchSize(float64(bs)))
    
    	// pprof
    	// handlePprof(sigChan, doneChan)
    
    	var profiling bool
    	if *cpuprofile != "" {
    		f, err := os.Create(*cpuprofile)
    		if err != nil {
    			log.Fatal(err)
    		}
    		profiling = true
    		pprof.StartCPUProfile(f)
    		defer pprof.StopCPUProfile()
    	}
    	go cleanup(sigChan, doneChan, profiling)
    
    	batches := numExamples / bs
    	log.Printf("Batches %d", batches)
    	bar := pb.New(batches)
    	bar.SetRefreshRate(time.Second)
    	bar.SetMaxWidth(80)
    
    	for i := 0; i < *epochs; i++ {
    		bar.Prefix(fmt.Sprintf("Epoch %d", i))
    		bar.Set(0)
    		bar.Start()
    		for b := 0; b < batches; b++ {
    			start := b * bs
    			end := start + bs
    			if start >= numExamples {
    				break
    			}
    			if end > numExamples {
    				end = numExamples
    			}
    
    			var xVal, yVal tensor.Tensor
    			if xVal, err = inputs.Slice(sli{start, end}); err != nil {
    				log.Fatal("Unable to slice x")
    			}
    
    			if yVal, err = targets.Slice(sli{start, end}); err != nil {
    				log.Fatal("Unable to slice y")
    			}
    			if err = xVal.(*tensor.Dense).Reshape(bs, 1, 28, 28); err != nil {
    				log.Fatalf("Unable to reshape %v", err)
    			}
    
    			gorgonia.Let(x, xVal)
    			gorgonia.Let(y, yVal)
    			if err = vm.RunAll(); err != nil {
    				log.Fatalf("Failed at epoch  %d: %v", i, err)
    			}
    			solver.Step(m.learnables())
    			vm.Reset()
    			bar.Increment()
    		}
    		log.Printf("Epoch %d | cost %v", i, costVal)
    
    	}
    
    opened by jerrycraft2 10
  • Export tapeMachine / lispMachine

    Export tapeMachine / lispMachine

    I know in vm.go you emphasize that tapeMachine and lispMachine are not exported. But since one is able to get these types anyway through e.g. NewTapeMachine it feels awkward.

    My specific "issue" is that I am playing around with your library (thank you very much btw) and want to do stuff like

    var machine G.TapeMachine if option_enabled { machine = G.NewTapeMachine(g, option) } else { machine = G.NewTapeMachine(g) }

    opened by siquus 10
  • Issue importing examples

    Issue importing examples

    Hello, I'm new to Go and I'm trying to follow the MNIST tutorial. However, when I try to import the gorgonia.org/gorgonia/examples/mnist package, it gives me the following error:

    could not import gorgonia.org/gorgonia/examples/mnist (no required module provides package "gorgonia.org/gorgonia/examples/mnist")
    

    Any suggestions? Here's the code:

    package main
    
    import (
            "fmt"
            "log"
    
            "gorgonia.org/gorgonia/examples/mnist"
            "gorgonia.org/tensor"
    )
    
    func main() {
            for _, typ := range []string{"test", "train"} {
                    inputs, targets, err := mnist.Load(typ, "./testdata", tensor.Float64)
                    if err != nil {
                            log.Fatal(err)
                    }
                    fmt.Println(typ+" inputs:", inputs.Shape())
                    fmt.Println(typ+" data:", targets.Shape())
            }
    }
    

    I'm running go 1.17.8 and have installed Gorgonia with go get go get -u gorgonia.org/gorgonia.

    opened by adzcai 0
  • panic: Something in this program imports go4.org/unsafe/assume-no-moving-gc

    panic: Something in this program imports go4.org/unsafe/assume-no-moving-gc

    panic: Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the go1.18 runtime. If you want to risk it, run with environment variable ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.18 set. Notably, if go1.18 adds a moving garbage collector, this program is unsafe to use.

    opened by alanmoleapfive 1
  • Fail when install cuda test

    Fail when install cuda test

    Hi, this is an awesome work, i was so excited to try this bute get error installing cudatest, i have the drivers installed and cuda and cudnn, bute get somuch errors __DEPRECATES im using cuda 11.6 gorgonia suports that version? Keep doing this is awesome

    Thanks

    opened by FernandoIV 0
  • Failing to compile with cuda

    Failing to compile with cuda

    I have been coming across and issue while trying to use cuda with gorgonia. I have gotten this error now in both windows and arch linux.

    ../../../../../pkg/mod/gorgonia.org/[email protected]/cuda.go:141:23: v.Pointer undefined (type Value has no field or method Pointer)
    ../../../../../pkg/mod/gorgonia.org/[email protected]/cuda.go:186:48: v.Pointer undefined (type Value has no field or method Pointer)
    ../../../../../pkg/mod/gorgonia.org/[email protected]/cuda.go:199:24: retVal.Pointer undefined (type Value has no field or method Pointer)
    ../../../../../pkg/mod/gorgonia.org/[email protected]/vm_tape_cuda.go:190:45: dv.d.Pointer undefined (type Value has no field or method Pointer)
    ../../../../../pkg/mod/gorgonia.org/[email protected]/vm_tape_cuda.go:197:25: dv.d.Pointer undefined (type Value has no field or method Pointer)
    ../../../../../pkg/mod/gorgonia.org/[email protected]/vm_tape_cuda.go:227:50: from.Pointer undefined (type Value has no field or method Pointer)
    ../../../../../pkg/mod/gorgonia.org/[email protected]/vm_tape_cuda.go:232:20: to.Pointer undefined (type Value has no field or method Pointer)
    

    The cudatest worked without issue. I am not very familiar with gorgonia so if someone is able to point me in the right direction I would appreciate it a lot. Thanks!

    opened by Trey2k 3
  • The result of softmax in convnet example has negative numbers

    The result of softmax in convnet example has negative numbers

    I tried to run convnet example in examples/convnet/main.go and found the loss doesn't decrease and the accuracy is low(just like random guess). Screen Shot 2022-01-10 at 6 04 16 PM

    Then I printed out the output of softmax operator and found that it has negative numbers. Maybe the calculation of softmax is wrong? Screen Shot 2022-01-10 at 6 01 28 PM

    PS: I run the code on Mac OS.

    opened by xuyifangreeneyes 1
Releases(v0.9.17)
  • v0.9.17(Mar 14, 2021)

    CI

    CI (GitHub actions) has a new template system that will ease the go releases' upgrade. On top of that, it now has a custom runner for ARM64. This leads to discovering and fixing a couple of issues in the tests on ARM64.

    Fixes

    • Support flat weights for the BatchNorm op (#465)
    • fix the reset method of the tape machine (#467)
    • fix clipping in Adam solver (#469)
    • fix panic message in GlorotEtAlN64 (#470)
    • fix concurrent example (#472)

    API change

    • functions to create primitive Value types (NewF64, NewF32, ...) (#481)
    • Breaking change: the BatchNorm1d function has been removed; BatchNorm function supports 1d and 2d operations (#482)
    Source code(tar.gz)
    Source code(zip)
  • v0.9.16(Dec 31, 2020)

    This version incorporates the semantics clarification of the tensor package - the unsafe pointer things are cleaned up as well.

    Small bugfixes to SoftMax was also fixed - SoftMax no longer cause a race condition.

    Source code(tar.gz)
    Source code(zip)
  • v0.9.15(Sep 28, 2020)

    When vectors were broadcast with a repeat of 1, one of the values is accidentally zero'd. This leaves very strange artifacts in neural networks.

    This has now been fixed

    Source code(tar.gz)
    Source code(zip)
  • v0.9.14(Sep 10, 2020)

  • v0.9.13(Aug 6, 2020)

  • v0.9.12(Jun 18, 2020)

    The Upsample2D operator has been added by @cpllbstr . It is similar to the operator in PyTorch: https://pytorch.org/docs/master/generated/torch.nn.Upsample.html

    Source code(tar.gz)
    Source code(zip)
  • v0.9.11(Jun 15, 2020)

    Due to the great work by @wzzhu, shape inference is now a bit more robust. It goes back to the original Gorgonia understanding of shapes - where reductions do not aggressively squeeze the dimensions.

    Source code(tar.gz)
    Source code(zip)
  • v0.9.10(Apr 10, 2020)

    In the previous version, the repeatOp was a compound operation. It had this function signature effectively: func repeat(a, nTimes *Node, axes ...int). So you could do something like repeat(a, 300, 1, 2, 3) in which a gets repeated 300 times across axes 1, 2 and 3.

    This has been deoptimized such that it's effectively func repeat(a, repeat *Node, axis int). The reason for this deoptimization is because upon further analyses of what the function actually does, it simply calls tensor.Repeat many times. This causes many new tensors to be allocated. But the whole point of symbolic operations is so that we may preallocate ahead of time.

    This deoptimization allows for the repeatOp to call tensor.RepeatReuse which allows for a repeat operation to reuse preallocated values, leading to less allocations, improving performance

    Source code(tar.gz)
    Source code(zip)
  • v0.9.9(Mar 25, 2020)

  • v0.9.8(Feb 10, 2020)

    Two bugfixes in this release:

    • An Off-By-One bug in which the axes of softmax was affected.
    • TrimSpace being used in the iris example
    • Return value of scalar values are fixed
    Source code(tar.gz)
    Source code(zip)
  • v0.9.7(Jan 19, 2020)

    Previously when an expression such as -(x+y) is given and x and y are scalar values, the neg op would fail to correctly pass the derivative into the constituents. This is due to a misuse of UnsafeDo . This has been rectified now.

    Source code(tar.gz)
    Source code(zip)
  • v0.9.5(Dec 8, 2019)

    A number of new features were added, mainly to support golgi - gorgonia.org/golgi. Here is an incomplete enumeration:

    • KeepDims is introduced as a function to decorate another function
    • A bunch of BroadcastXXX operations were added (autogenerated)
    • Unconcat which is the opposite of Concat
    • BatchedMatMul supports more than 3D tensors
    • SoftMax supports multiple axes now
    • Monadish handling of *Nodes
    • Consistent axis operations thanks to @bdleitner
    • GAP operator
    Source code(tar.gz)
    Source code(zip)
  • v0.9.4(Nov 7, 2019)

  • v0.9.3(Sep 6, 2019)

  • v0.9.2(Aug 30, 2019)

  • v0.9.0-beta(Aug 19, 2018)

    Ongoing notes:

    • CUDA: Better CUDA support (IN PROGRESS)
      • ~ColMajor used by default if engine is CUDA.~ (ColMajor is supported, but defaults to using RowMajor for all the major cuBLAS versions. Careful reasoning of the parameters obviates the need for ColMajor by default, which causes more headaches. It is still supported)
      • Transposition will be automatically done when performing transports back to CPU.
      • cudnn operations supported (IN PROGRESS) (note: these are the ones I use more often hence gets bigger attention):
        • [x] Conv2d
        • [x] Dropout
        • [x] Maxpool2d
        • [x] BatchNorm
        • [x] Rectify
      • Other CUDA related optimizations
        • [x] full cuBLAS support
    • New Ops:
      • BatchNorm
      • InvSqrt
      • CUDA enabled ops in ops/nn (preview for how things will start to look in v0.10.0)
    • New Features:
      • Limited shape inference. Working towards a calculus for shapes (first raised in #96 and #97).
    • Optimizations:
      • Optimizations of basic ops to use engine functions if available, otherwise, fall back to using Apply, which adds a penalty from repeatedly calling functions.
      • Faster VMs (1 of 2 VMs): ~greedy goroutines grabs gigs from a priority queue. This causes faster execution of code in general.~ (this is moved to a future version of 0.9.xx):
    benchmark                           old ns/op      new ns/op      delta
    BenchmarkTapeMachineExecution-8     3129074510     2695304022     -13.86%
    
    benchmark                           old allocs     new allocs     delta
    BenchmarkTapeMachineExecution-8     25745          25122          -2.42%
    
    benchmark                           old bytes      new bytes      delta
    BenchmarkTapeMachineExecution-8     4804578705     4803784111     -0.02%
    
    • Code generation: some exported API is now auto generated
    • New Solver : @ynqa added the Momentum solver.
    • Breaking API: Solver now take a slice of ValueGrad instead of Nodes. ValueGrad is an interface, of which a *Node fulfils. An additional utility function NodesToValueGrads has been added to aid with refactoring. This was done for two reasons:
      • ~The support for BatchNorm operation, which is a verily impure and highly stateful function. The BatchNorm Op has internal states that need to have their gradients updated as well. But the internal state of BatchNorm isn't really part of the expression graph, and really it shouldn't be.~ Turns out there was a better API for BatchNorm.
      • In the next version, v0.10.0. We aim to do better package organization for managability. With this API breaking change, the solver now is less dependent on the other parts of Gorgonia and can be easily separated.
    • Breaking Semantics: A gorgonia.VM now implements io.Closer. It should be treated as a resource as well as a computation device - the VM must be Close()d in order for the resources acquired by the VM to actually be released. Turns out, automatic resource management is too difficult. Who'd thunk that?
    Source code(tar.gz)
    Source code(zip)
  • v0.8.4(May 11, 2018)

  • v0.8.3(May 6, 2018)

    Bugfixes for UnbindAllNonInput was done.

    Furthermore, because Gonum no longer supports Go with versions less than 1.8, Gorgonia will not support that either

    Source code(tar.gz)
    Source code(zip)
  • v0.8.2(Jan 27, 2018)

  • v0.8.1(Jan 22, 2018)

  • v0.8.0(Dec 17, 2017)

    In v0.8.0, the Gorgonia packages have officially been split:

    • "gorgonia.org/gorgonia" - handles graph creation and execution
    • "gorgonia.org/tensor" - underlying data structures
    • "gorgonia.org/cu" - CUDA interface

    Futhermore, dep is now officially used. TensorDot support for automatic and symbolic differentiation added by @siquus

    Source code(tar.gz)
    Source code(zip)
  • v0.7.5(Nov 15, 2017)

    There has been a bug fix for MatMul. Previously this would panic:

    // Case 1
    a := New(WithShape(2, 1), WithBacking(Range(Float64, 0, 2)))
    b := New(WithShape(1, 3), WithBacking(Range(Float64, 0, 3)))
    c, err := MatMul(a, b)
    
    // Case 2
    a = New(WithShape(1, 2), WithBacking(Range(Float64, 0, 2)))
    b = New(WithShape(2, 3), WithBacking(Range(Float64, 0, 6)))
    c, err = MatMul(a, b)
    

    @siquus discovered the bug and fixed it for Case 1. Additional test cases were generated for Case 2 and fixed.

    Source code(tar.gz)
    Source code(zip)
  • v0.7.4(Oct 3, 2017)

    Added convolution operations and its differential functions. The convolution function is heavily based on IM2Col and Col2IM.

    Much of the code was cribbed from Caffe's implementation of im2col and col2im. Licences will be added in the upcoming commit.

    Source code(tar.gz)
    Source code(zip)
  • v0.7.3(Sep 23, 2017)

    A bug was fixed in the example.

    Additional smarts for subgraphing were added so that nodes with infidel ops will also be automatically added when subgraphing

    Source code(tar.gz)
    Source code(zip)
  • v0.7.2(Sep 20, 2017)

    @docmerlin submitted a patch for a bug in OneHotVector. Also tests were added.

    Additionally, new README notes were also added, informing users of upcoming changes to future versions.

    Source code(tar.gz)
    Source code(zip)
  • v0.7.1(Sep 10, 2017)

    Some issues with versioning Gorgonia has now been resolved. No more compiler magics are being used Additional tests and documentation were added.

    Source code(tar.gz)
    Source code(zip)
Owner
Gorgonia
Gorgonia
Generative Adversarial Network in Go via Gorgonia

Generative adversarial networks Recipe for simple GAN in Golang ecosystem via Gorgonia library Table of Contents About Why Instruments Usage Code expl

Dimitrii Lopanov 72 Feb 22, 2022
A High-level Machine Learning Library for Go

Overview Goro is a high-level machine learning library for Go built on Gorgonia. It aims to have the same feel as Keras. Usage import ( . "github.

AUNUM 294 Apr 16, 2022
Self-contained Machine Learning and Natural Language Processing library in Go

Self-contained Machine Learning and Natural Language Processing library in Go

NLP Odyssey 1.1k May 13, 2022
Machine Learning for Go

GoLearn GoLearn is a 'batteries included' machine learning library for Go. Simplicity, paired with customisability, is the goal. We are in active deve

Stephen Whitworth 8.3k May 15, 2022
On-line Machine Learning in Go (and so much more)

goml Golang Machine Learning, On The Wire goml is a machine learning library written entirely in Golang which lets the average developer include machi

Conner DiPaolo 1.3k May 8, 2022
Machine Learning libraries for Go Lang - Linear regression, Logistic regression, etc.

package ml - Machine Learning Libraries ###import "github.com/alonsovidales/go_ml" Package ml provides some implementations of usefull machine learnin

Alonso Vidales 194 Apr 22, 2022
Prophecis is a one-stop machine learning platform developed by WeBank

Prophecis is a one-stop machine learning platform developed by WeBank. It integrates multiple open-source machine learning frameworks, has the multi tenant management capability of machine learning compute cluster, and provides full stack container deployment and management services for production environment.

WeBankFinTech 331 May 9, 2022
Go Machine Learning Benchmarks

Benchmarks of machine learning inference for Go

Nikolay Dubina 22 May 7, 2022
Deploy, manage, and scale machine learning models in production

Deploy, manage, and scale machine learning models in production. Cortex is a cloud native model serving platform for machine learning engineering teams.

Cortex Labs 7.8k May 10, 2022
Standard machine learning models

Cog: Standard machine learning models Define your models in a standard format, store them in a central place, run them anywhere. Standard interface fo

Replicate 2.4k May 10, 2022
Katib is a Kubernetes-native project for automated machine learning (AutoML).

Katib is a Kubernetes-native project for automated machine learning (AutoML). Katib supports Hyperparameter Tuning, Early Stopping and Neural Architec

Kubeflow 1.2k May 11, 2022
PaddleDTX is a solution that focused on distributed machine learning technology based on decentralized storage.

中文 | English PaddleDTX PaddleDTX is a solution that focused on distributed machine learning technology based on decentralized storage. It solves the d

null 55 Apr 19, 2022
Go (Golang) encrypted deep learning library; Fully homomorphic encryption over neural network graphs

DC DarkLantern A lantern is a portable case that protects light, A dark lantern is one who's light can be hidden at will. DC DarkLantern is a golang i

Raven 1 Dec 2, 2021
Reinforcement Learning in Go

Overview Gold is a reinforcement learning library for Go. It provides a set of agents that can be used to solve challenges in various environments. Th

AUNUM 267 May 2, 2022
Spice.ai is an open source, portable runtime for training and using deep learning on time series data.

Spice.ai Spice.ai is an open source, portable runtime for training and using deep learning on time series data. ⚠️ DEVELOPER PREVIEW ONLY Spice.ai is

Spice.ai 722 May 10, 2022
FlyML perfomant real time mashine learning libraryes in Go

FlyML perfomant real time mashine learning libraryes in Go simple & perfomant logistic regression (~100 LoC) Status: WIP! Validated on mushrooms datas

Vadim Kulibaba 0 May 3, 2022
A tool for building identical machine images for multiple platforms from a single source configuration

Packer Packer is a tool for building identical machine images for multiple platforms from a single source configuration. Packer is lightweight, runs o

null 2 Oct 3, 2021
Genetic Algorithms library written in Go / golang

Description Genetic Algorithms for Go/Golang Install $ go install git://github.com/thoj/go-galib.git Compiling examples: $ git clone git://github.com

Thomas Jager 191 May 7, 2022
Go package for OCR (Optical Character Recognition), by using Tesseract C++ library

gosseract OCR Golang OCR package, by using Tesseract C++ library. OCR Server Do you just want OCR server, or see the working example of this package?

Hiromu OCHIAI 1.8k May 15, 2022