-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 06.03.2011 00:59, schrieb David Herman: >> Using the small, fixed size subset of that lib and exporting the >> interface to ECMAScript should give perfect coverage > > Can you be more explicit about what you mean by "perfect coverage?" What set > of use cases are you trying to address? Are we talking specifically 3D > graphics? If that's the case, it's not clear whether that's really > appropriate for the ECMAScript spec. As I say, we standardize very few > libraries, usually just the smallest set needed to provide core functionality. > > Just looking around, there are already lots of WebGL matrix libraries out > there:
Linear algebra is much more than 3D (and 2D) graphics - although it's a very prominent use that currently has a big focus in web development. The traditional usecase (but then with matrices and vectors of more than 4 dimensions) is to solve (linear) equation systems. This has so many uses that I wouldn't know where to start to explain them. They are not only used in mathematics but also in all other nature sciences (physics, chemistry, biology, engineering, ...), in economics, ... That's why I want an ultra efficient but fixed size 2D, 3D and 4D specialisation and a fast arbitrary dimension implementation. That there are lots of WebGL matrix libraries is supporting that point: it's highly needed and a missed feature. Such a library has to cover the data types: - - scalar (= normal number, nothing to do here) - - vectors (= array; in the two variants of a n*1 and a 1*n matrix) - - matrices (= 2 dimensional array) These data-accesses: - - select a vector or matrix element -> scalar - - select a column or row of a matrix -> vector - - transpose a vector -> vector - - transpose a matrix -> matrix - - "glue" enough vectors together-> matrix And to cover these operations: - - vector + vector = vector - - matrix + matrix = matrix - - scalar * vector = vector - - scalar * matrix = matrix - - (row-)vector * (column-)vector = scalar (i.e. scalar product) - - (column-)vector * (row-)vector = matrix - - (column-)vector * matrix = (column-)vector - - matrix * (row-)vector = (row-)vector - - matrix * matrix = matrix This are the basic operations, all other operations build up on them. The extended set of basic operations have piecewise multiplications of two vectors and two matrices. This is also so basic that there is since ages (starting with Fortran...) an API for doing exactly that and lots of highly optimized libraries that follow that API. The key word is "BLAS". Well known implementations for that are: - - ATLAS: math-atlas.sourceforge.net - - Intel MKL: http://software.intel.com/en-us/articles/intel-mkl/ - - GotoBLAS: http://www.tacc.utexas.edu/tacc-projects/gotoblas2/ ... Note: these libraries are extremely well optimized, but they target the arbitrary dimension case with lots of dimensions, so they are usually too slow for the small, fixed size case needed in graphics. Including such a library in a specific ECMAScript implementation would be a good start - but it would still require a bit of extra code that handles the small, fixed size case. (For doing those efficiently there's also heaps of information on the net, e.g. http://software.intel.com/en-us/articles/optimized-matrix-library-for-use-with-the-intel-pentiumr-4-processors-sse2-instructions/) To become a "great coverage" those basic operations should be extended by: - - LU decomposition - - cross product of two vectors in the 3D case And a "perfect coverage" would include: - - quaternions - - SVD decomposition - - doing decompositions in place and add matrix multiplications that handle those All of that also isn't very new. Magic key words to search for existing libraries would be LAPACK. >> BTW: The big break though the GeForce graphic cards brought, was that >> those operations went from the CPU to the GPU. > > Then again, WebGL is already exposing the GPU to JS programmers. IANA GPU > expert, but can you not already farm out matrix math to the GPU via GLSL? Of course you try to do much matrix math on the GPU and modern OpenGL (thus WebGL also) helps you with that, e.g. by using GLSL. But, it's mostly one way, i.e. you write the shader, load it to the GPU and from now on just feed it the data. If you need results back, it's not good anymore. GPUs are optimized for stream processing - if you use it interactively you'll loose. So you need the tools on the client to also work with the data. E.g. to prepare the data. Or to tell the GPU what to do exactly (example: to position an object in 3D you have to multiply a few matrices together till you have the final matrix that the GPU uses to multiply all vectors with). Or to do collision detection. Or ... And doing 2D work (Canvas, SVG) wouldn't give you access to the GPU. Just think of a totally different application: We've got a time series of data (e.g. profit per month for the last year) and want to display that (e.g. on a Canvas or with a SVG). That's currently easily possible. And now we want to show a trend line, i.e. a line that follows that data, to filter out the noise and give a bit of prediction of the future. The usual approach is to get a "least squares" line, i.e. a line where the squared error between the line position and the data position is minimal. If you do that now, it's quite tedious. If you've got the lib as outlined above, it's a piece of cake. > As I say, I'll look into this, but a standardized matrix library doesn't seem > as high priority to me as the rest of the binary data spec. The matrix library would need a good binary data structure to have full potential. And a binary data spec would soon raise the question for a matrix lib - as you've shown above, WebGL has already shown the need for one. CU, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREIAAYFAk1zag8ACgkQoWM1JLkHou2GKgCdEzK7vMJB3FPtOv8K/mJTfI7d 3bIAoJl/g3jkYDUNiy7KTzwVkRsQmElA =/OOX -----END PGP SIGNATURE----- _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
