seeding the pot for 2.0 features [small vectors]

[Mikola Lysenko]

Bill Baxter wrote:
> Mikola Lysenko wrote:
>> 2. Low dimensional vectors as primitive types
>>
>> This would be exceptionally useful in many applications which require 
>> coordinate geometry.  Here is a very brief list:
>>
>> Scientific Programs
>> Physics Simulation
>> Computer Graphics
>> Video Games
>> User Interfaces
>> Computational Geometry
>> Robotics
>> Fluid Simulation
> 
> It's still a tiny fraction of the number of applications that use, say, 
> strings.  So the ubiquity argument for inclusion is pretty weak, I think.
> 

This was the same sentiment I felt several years ago, but overtime I 
have come to realize that vectors are probably one of the most widely 
used, yet least supported programming structures.  The thought 
eventually crystallized for me while learning ActionScript 3.  I was 
reading through the example projects they provided with the SDK, and was 
struck by the fact that each project used a custom 2-d vector class. 
Given the prevalence of such a construct, it seems that a language ought 
to provide a good common implementation.

Pretty much any application that eventually needs to produce graphical 
output requires the use of vectors somewhere down the line.  Be it a 
simple GUI reading in mouse clicks, a video game or a scientific GUI. 
The idea of low dimensional vectors is firmly rooted in geometry, which 
is one of the most basic branches of mathematics.  Vectors are easily 
used more often than complex numbers, which D already supports.

I would like to see some more detailed usage statistics on vectors, 
however this is difficult to reliably check.  A Google code search on 
vector vs. complex gives the following results, though this may be 
somewhat skewed given that vector is a loaded word in computer science:

Vector Math: 300k  results
http://www.google.com/codesearch?q=vector+math&hl=en&btnG=Search+Code

Complex Math: 100k results
http://www.google.com/codesearch?q=complex+math&hl=en&btnG=Search+Code


I suspect that there are probably better ways to measure the use of 
vectors, especially since the synonym Point is often used in C++ 
programs.  (std::vector creates name conflicts).  Also contractions like 
vec, vect, vecr are often used instead of a full word.  As a percentage 
of total applications containing vectors, it may be difficult to 
estimate.  From my personal experience, I would guess that they are used 
very frequently.

For such a widespread structure, there is remarkably little language 
support.  For example, the Java standard library contains hundreds of 
classes.  It has everything from a GregorianCalendar to a Midi 
synthesizer.  It does not have vector support.  Even in newer languages 
like Python, there is still an inordinate amount of time wasted on 
reimplementing vectors.

Part of the problem is that vectors are pretty easy to hack together, so 
everyone basically shlocks something that barely works and uses that. 
The other option is that they get hung up on the damn vector class 
before they even write the project and end up wasting all their time on 
that instead.  There are literally hundreds of vector libraries for C++ 
alone.  A Google search for vector library gives over 26 million 
results!  I've even contributed a few of my own, such as:

http://www.assertfalse.com/downloads/vecmat-0.1.zip

Moreover, interoperability is a big concern.  Many times I have tried to 
interface with some code online, perhaps a model loader or some 
numerical application.  Since so few languages have standard vectors, 
they all use custom formats for processing data.  In order to add them 
to my project, I typically have to do a find/replace on the vector type 
they are using and pray to god it compiles.  Even then, there are 
sometimes sneaking problems that only show up after I've finished 
importing and connecting everything.


> 
> As far as D is concerned, Helix has a pretty decent implementation.  See 
> http://www.dsource.org/projects/helix.  It lacks Vector2's but I've 
> added them to my own copy and I'd be happy to send it to you if you like.
> 
>> One option is to extend the standard library with a vector-types 
>> class, but this is not nearly as nice a compiler level implementation.
> 
> I'm not convinced that a compiler-level implementation of these things 
> is necessary.
> 

Helix is not a bad project, but in order for a standard vector to be 
useful it needs to come packaged with the compiler.  The temptation to 
roll your own is too great otherwise.  Even putting it in the standard 
library is not enough to prevent people from reinventing the wheel, as 
we have seen by the numerous variations on C++'s std::list.  Ideally, 
small vectors should be in the global namespace, right alongside complex 
numbers and dynamic arrays.

Effective vector code needs correct data alignment, instruction 
scheduling and register use.  Each of these issues is most effectively 
handled in the compiler/code gen stage, and therefore suggests that at 
the very least the compiler implementation ought to be aware of the 
vector type in some way.  By applying the "D Builtin Rationale," it is 
easy to see that vectors meet all the required criteria.

An optimal strategy would be to have the vector types builtin, with a 
simple per-component multiplication defined, and a separate standard 
math library for doing more complex operations.  Here is an example:

import std.vecmath;

float4 a = [1, 2, 3, 4];
float4 b = [2, 3, 4, 5];
float4 c = a * b;		//c = [2, 6, 12, 20]
float  d = dot(a, b);		//Defined in std.vecmath

-Mik