Introducing mathgl: a vector and matrix math library for Go

[Jsor]

I've been working on this pretty extensively for the past couple weeks, and I think I'm finally ready to post it.

https://github.com/Jragonmiris/mathgl

Mathgl is a vector, matrix, and quaternion library for Go. Right now I consider it "working", but that doesn't mean "complete." It's stable in that it provably works for simple applications (as seen in the examples), however, the tests likely aren't thorough enough to guarantee that every edge case is covered and it will never freak out on you in a complex application.

It's geared towards 3D math and the goal of the project is to get it up to the point that maybe some day it will be rolled in with go-gl (github.com/go-gl).

I encourage people to use it for simple OpenGL applications, I ported the first 8 tutorials on opengl-tutorials.org to Go replacing uses of GLM with mathgl (at the moment, porting the rest of the tutorials is halted until I find a way to bypass an AMD driver bug). For the willing, though, what I really need is people to A. Interpret the benchmarks (I don't have a handle on how good/bad they are), B. Suggest API improvements and C. Help think of/write more tests and benchmarks.

At the moment, it kind of sidesteps the lack of generics with some fancy wrapper and enum tricks. As I mention in the README, I'm considering just dropping support for int32s and uint32s entirely and making everything float64s -- with the option to request an array of other types when needed (like the AsArray method already does now). This should speed it up at least a little and remove some of the kludgyness, but it also removes the ability to use other types should people need them for some bizarre reason

There's also a "subpackage" called mathglfast which is experimental, nowhere near as mature, and relies on arrays rather than slices, and spells out all the multiplications rather than using loops. So in THEORY it should be faster, but I'm not sure if it would improve speed enough enough to be worth it. Writing it is a huge pain as evidenced by all the code generation tricks I tried.

(And yes, I know about the math3D package. It appears to be dead, which is why I started this)

[John Asmuth]

I would have expected a math package meant for gl would have hard-coded 3x3 and 4x4 matrices, rather than the general case.

I don't mean to imply that it's a waste of effort to rewrite something I've already worked on, but there exists https://github.com/skelterjohn/go.matrix for general matrix manipulation in pure go, and it's pretty full-featured.

[Tim Shannon]

Looks interesting.  In my benchmarks, I found that arrays were much faster than slices, and there's a nice vectormath library here: https://github.com/spate/vectormath using structs.

Have you seen any issues with garbage collection after a lot of matrix operations?

[Jsor]

No, I haven't noticed any GC issues.

How about now? I swapped mathglfast to the "main" folder, which is all explicitly sized arrays that are autogenerated by a script in genprog, and converted to different types using a makefile and gofmt. It lack a lot (determinants, translate, quaternions, transforms etc), but is that a better idea?

Sorry my package sucks :(

[Philipp Schumann]

Gonna stick to my own just-as-incomplete pkg for now [ https://github.com/metaleap/go-util/tree/master/num ] but good stuff, always great to have a wider range of options in the greater ecosystem.

Next time I'm missing a function or run into a bug, I have one more reference package to compare to and look into...  ;))

Yeah GC shouldn't be an issue if your package doesn't have root-level pointer-type/ref-type variables including slices. Of course for GC, sized arrays for mat3/mat4 and/or structs for vec2/3/4 are a must...  ;)

And indeed why anyone would ever want int vectors / int matrices in a 3D context escapes me, but nevermind...  ;-)

[Tim Shannon]

Philipp, your library looks similar to the way I'm trying to attack the problem (http://code.google.com/p/vmath ) in rewriting Spate's vectormath library, where the result is the method owner.

It's wonderful that there are so many different implementations.  It'll make it nice for bench-marking and testing / verification to have other libraries to hit against.

The interesting thing about yours is you use structs for vectors and arrays for Matrices. Is that just a style preference, or was there some reasoning behind that?

[Philipp Schumann]

Yeah, just for style/readability reasons -- in calling code I want to deal with .X .Y and .Z components rather than index into the vec...

[Raul Mera]

Hi,

I would suggest also posting this to the go.science community in G+ https://plus.google.com/u/0/communities/115354877257015196825 

to see to which extend (it at all) does your package overlaps with previous work, and how do we deal with it if it does.

Also to prevent future duplication of your effort from other developers.