FAQ
CC'ing crawshaw.

On Wed, Mar 30, 2016 at 2:30 AM, Bryan Matsuo wrote:
The f32 package has some erroneous computational bugs which I don't need to
go into (they are open issues on github).
I know of these two below. Please let me know if there are others.
https://github.com/golang/go/issues/14360
https://github.com/golang/go/issues/14989

The way things are it makes no sense to me why all the linear algebra
functions aren't implemented in the package golang.org/x/image/math/f32,
which uses a row-major order (though also chose to use a flat array, FWIW).
The x/mobile/exp/f32 package was written first, driven by the
immediate needs of the x/mobile project. The x/image/math/f32 package
was written later, with the broader goal of being a canonical matrix
representation so that different packages (written by different
people) can co-operate. In the long term, I hope to deprecate the
x/mobile flavor, and move the rest of x/mobile to use the x/image
flavor, but the x/image flavor is currently incomplete: we have not
reached consensus on what the API should look like, e.g. m :=
m.Times(n) vs m.Mul(m, n). (This is drifting tangentially, but if the
performance difference is indeed small, I lean towards m.Times(n),
similar to the image.Point methods instead of the big.Int methods;
it's necessary for big.Int because a big-int does not occupy a fixed
number of bytes).

As for the x/image flavor, there was a previous discussion at
https://groups.google.com/d/topic/golang-nuts/cuXorkJD6Bg/discussion
and
https://groups.google.com/d/topic/golang-dev/9sYm9-2Bc2w/discussion
that second one links to a doc at
https://docs.google.com/document/d/1BdQMB7OWzqFyn4VpwkvCVRFZ5KJMQCgyAA5KRMdMId8/edit#heading=h.dfctsvm47oev
which distills other conversations from further back. But there hasn't
been a lot of activity on it recently. It hasn't been the highest
priority thing on my plate or others'.

That doc notes that we agreed on row-major over column-major order.
Sure, OpenGL defaults to CMO, but OpenGL is not the only place where
Go code would like to use matrices, and the gonum folk would know more
about this than I do, but I suspect that other C libraries also
(often??) choose RMO.

As for serialization, yes, having Bytes allocate doesn't look ideal,
although it was certainly the easy route in getting the "Hello World"
of OpenGL programs off the ground. I agree that the x/image flavor of
Bytes should probably take a []byte buffer as an argument.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 17 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedMar 29, '16 at 3:30p
activeMar 31, '16 at 12:58p
posts17
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase