Thanks for the background and the document Nigel. Sorry to be stirring up
something that was discussed and essentially settled before. I am sorry I
didn't see/participate then.

Indeed those two issues are the ones I was referring to. I filed one and
commented on the other previously. Of course, those are computational
errors I personally have encountered (having not touch parts of the API
like the Affine type).

I haven't looked deeply into the mobile/exp/f32 lineage yet.. But the first
issue (#14360) may actually be case in point for an earlier comment made by

When doing graphics coding, you end up writing shaders in parallel to Go/C
code; having the same notation (or as close as possible) in both is IMHO a

It seems to me that two non-trivial graphics-specific functions in f32,
Mat4.Perspective() and Mat4.LookAt(), were implemented expecting
column-major order (possibly from a corresponding implementation in C or
some literature?). So I think the argument of an existing, strong precedent
for column-order matrices specifically in the graphics community has merit.
So, while I agree that having row-major indexing for generic MxN matrices
is probably OK academically and correct for Go I think that the special
case of fixed-size matrices for graphics applications may deserve a
different treatment.

Furthermore, because of these two functions Perspective and LookAt can the
package really be fully deprecated? Nigel, this is something I'm quoting
from one of the discussions you linked to.

The package will just be the type definitions, and maybe some dumb
methods (e.g. adding two vectors) that we can all agree on. Smart
code, such as calculating a projection matrix based on viewpoint,
angle, etc. are out of scope, and belongs in packages that *use* f32,
instead of being *in* f32.

You seem to be discussing these functions specifically; and you are saying
that image/math/f32 is not their home. Am I misreading things due to
improper context? If image/math/f32 is not where they will end up then
mobile/exp/f32 should not disappear, I believe (though trying to import two
packages called "f32" is a pain in the neck IMO, goimports is already
messing this one up for me).

- Bryan
On Wednesday, March 30, 2016 at 11:23:07 PM UTC-7, Nigel Tao wrote:

CC'ing crawshaw.

On Wed, Mar 30, 2016 at 2:30 AM, Bryan Matsuo <bryan....@gmail.com
<javascript:>> 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.

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,

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
that second one links to a doc at

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


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 17 | next ›
Discussion Overview
groupgolang-dev @
postedMar 29, '16 at 3:30p
activeMar 31, '16 at 12:58p



site design / logo © 2021 Grokbase