seeding the pot for 2.0 features [small vectors]

[Chad J]

Bill Baxter wrote:
> Mikola Lysenko wrote:
> 
>> Bill Baxter wrote:
>>
>>> Mikola Lysenko wrote:
>>>
>>>> 2. Low dimensional vectors as primitive types
> 
> 
> "Vectors are more common than complex, and complex is built-in".
> 
> This is a good argument.  Although, there seem to be a number of things 
> out there that are more common, or least as-common as 'complex'.  For 
> instance, there's a contingent here that wants to see decimal arithmetic 
> supported in the core.  There was a strong push for regexp to be in the 
> core for a while.
> 
> 
> "Most CPUs today have *some* kind of SSE/Altivec type thing"
> 
> That may be, but I've heard that at least SSE is really not that suited 
> to many calculations -- especially ones in graphics.  Something like you 
> have to pack your data so that all the x components are together, and 
> all y components together, and all z components together.  Rather than 
> the way everyone normally stores these things as xyz, xyz.  Maybe 
> Altivec, SSE2 and SSE3 fix that though.  At any rate I think maybe 
> Intel's finally getting tired of being laughed at for their graphics 
> performance so things are probably changing.
> 
> 
> "Library vs Core"
> 
> I think there's really not much that you can ask from the core.  A small 
> vector of 4 numbers can represent any number of things.  So I think your 
> best hope for the core is to support some very basic operations on small 
> vectors -- like component-wise +,-,*,/, and dot product -- to optimize 
> those kind of expressions as best as possible, and leave everything else 
> to libraries.  I guess that's pretty much how it works with HW shader 
> languages.  Except they add swizzles to the set of primitive ops.
> 
> 
> So what you're left with would be satisfied in large part by just having 
> vector math work on small static arrays (and be optimized well).
> 
>      float[4] v = a*b + c*d;
> 
> you can even make aliases if you like.
> 
>      alias float[4] float4;
> 
> But your 3D graphics library will still need to be a library on top of 
> that.

Yeah I mentioned static arrays earlier, but I realized that they can be 
a bit of a pain in the ass to work with.  This probably means that 
static arrays should be fixed, then they could be useful vectors. 
Consider trying to return a float4 from a function.  You can't return a 
float[4].  I remember talk on this ng about how static arrays were this 
kinda sucky inbetween-value-and-reference-type sort of thing.  I'd hope 
that at least gets fixed before static arrays are used for lo-D vectors.

> 
> Good news is that I think vector math like the above is something that 
> Walter is interested in adding to the language at some point.  Bad news 
> is that noone knows when that will be.   I'd guess though that a 
> kick-ass vector expression optimizer would be a long way off, judging by 
> how hard it's been for C++ compilers to get SSE type optimizations 
> implemented.
> 
> 
> "Getting it in the standard library"
> 
> I agree, though, that lo-D math is common enough that it should be 
> included in a standard library.  I wonder if the Tango developers would 
> be willing to include a vector math class...or if they already have one 
> in there.
> 
> I'd certainly like to be a contributor to that if so.
> 
> --bb