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 aand

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'.

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.