Additional language features

Christian Mayer mail at
Sun Mar 6 03:03:44 PST 2011

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:
- - Intel MKL:
- - GotoBLAS:

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.

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


Version: GnuPG v1.4.10 (GNU/Linux)


More information about the es-discuss mailing list