FAQ
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'.
Thanks for the links. But honestly, I'm not sure it's possible to write a
matrix package in Go that would be both standard and useful for everyone.

Graphics coding have clearly settled on column vectors in recent years,
this is how most of the papers and code examples are presented, so trying
to enforce row-majorness will be a no-go for many people. Also, it's said
in the doc that Go is "row-major", but this is a common abuse of language:
Go, just like C, doesn't know anything about columns or rows, its only
concern is storage order. Saying that Go is row-major implies that the
indices are in the order M[row][col], because this mirror the indices used
in math notation. But M[col]row] is very common in less mathematical
contexts, and this index order suddenly makes Go "column major".

That being said, the package can be completely agnostic for majorness: as
long as it contains only standard operations such as the matrix product, it
will work the same whether the matrix is interpreted as row-major or
column-major. It should be the user's decision to construct the matrix in
one way or the other, and use the correct indices, just like in GLSL. Maybe
this is what a standard package should do: drop any reference to majorness,
but explain the relation between indices, storage, and multiplication order
(i.e. use v*M if row-major, M*v if column-major).

Concerning the implementation, I don't understand the argument behind flat
arrays: what would be the use of an arbitrary slice of a matrix? Most
slices would span across rows or columns, which doesn't really make sense.
Even the few that would be mathematically sensible could not be used as
sub-matrices without a copy anyway. IMHO the whole point of a matrix is
that it's structured, and since there is a Go type that directly match this
structure, it should be use openly.

Finally, I understand the choice of [4]float32 for vectors instead of
struct{X,Y,Z,W float32} in a standard package, but on the other hand I
would not want to use that for graphics coding; it makes it too cumbersome
to write and read very common operations.

--
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 | 14 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