I've always had this dilemma in C++ when writing graphicsy methods, whether a function that takes a point should take separate components (float,float,float) or a vector (Vec3f), or perhaps a pointer (float*).  In D there's also the option of float[3].  Or just for convenience sake maybe overloads for all of the above.

I just realized today the coolness of tupleof for this kind of situation.  You can make the function takes the plain floats

   do_something_at_point(float x, float y, float z);

And still call it using a Vec3f via tupleof!

   Vec3f world_origin;
   ...
   do_something_at_point(world_origin.tupleof);

as opposed to

   do_something_at_point(
       world_origin.x,
       world_origin.y,
       world_origin.z);

It's a minor thing, but it rocks.


--bb

Bill Baxter wrote:
> I've always had this dilemma in C++ when writing graphicsy methods,
> whether a function that takes a point should take separate components
> (float,float,float) or a vector (Vec3f), or perhaps a pointer (float*).
>  In D there's also the option of float[3].  Or just for convenience sake
> maybe overloads for all of the above.
> 
> I just realized today the coolness of tupleof for this kind of situation.  You can make the function takes the plain floats
> 
>    do_something_at_point(float x, float y, float z);
> 
> And still call it using a Vec3f via tupleof!
> 
>    Vec3f world_origin;
>    ...
>    do_something_at_point(world_origin.tupleof);
> 
> as opposed to
> 
>    do_something_at_point(
>        world_origin.x,
>        world_origin.y,
>        world_origin.z);
> 
> It's a minor thing, but it rocks.
> 
> 
> --bb

I discovered the same thing, by roughly the same thinking.  I was working with DFL and cairo, and was using DFL's color structure. Problem was that DFL's stored using ubytes, and I wanted doubles.

So when I was writing my own colour structure, as I was defining the storage, I wrote

> union
> {
>     struct { double r, g, b, a; }
>     double[4] rgba;
> }

And it suddenly hit me: I could add a tuple!

Now, I have .tuple members for my colour structs, vectors, quaternions, matrices, and just about every other aggregate type I've written.

One thing that would make this an order of magnitude more useful would be the ability to return a tuple from a function.

But I agree: it's cool :)

	-- Daniel

P.S.  I use .tuple instead of .tupleof because I don't want to shadow the very-useful compile-time property :)

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> 
> I discovered the same thing, by roughly the same thinking.  I was
> working with DFL and cairo, and was using DFL's color structure.
> Problem was that DFL's stored using ubytes, and I wanted doubles.
> 
> So when I was writing my own colour structure, as I was defining the
> storage, I wrote
> 
>> union
>> {
>>     struct { double r, g, b, a; }
>>     double[4] rgba;
>> }
> 
> And it suddenly hit me: I could add a tuple!

How's that? You add an alias Tuple!(something ) to the union?

> Now, I have .tuple members for my colour structs, vectors, quaternions,
> matrices, and just about every other aggregate type I've written.
> 
> One thing that would make this an order of magnitude more useful would
> be the ability to return a tuple from a function.
> 
> But I agree: it's cool :)
> 
> 	-- Daniel
> 
> P.S.  I use .tuple instead of .tupleof because I don't want to shadow
> the very-useful compile-time property :)

I'm just using the compiler's .tupleof property directly.

--bb

Bill Baxter wrote:
> Daniel Keep wrote:
>>
>> I discovered the same thing, by roughly the same thinking.  I was working with DFL and cairo, and was using DFL's color structure. Problem was that DFL's stored using ubytes, and I wanted doubles.
>>
>> So when I was writing my own colour structure, as I was defining the storage, I wrote
>>
>>> union
>>> {
>>>     struct { double r, g, b, a; }
>>>     double[4] rgba;
>>> }
>>
>> And it suddenly hit me: I could add a tuple!
> 
> How's that? You add an alias Tuple!(something ) to the union?

Tuple!(double,double,double,double) tuple;

Actually, I made a template called repeatT that lets me write that as
repeatT!(4, double) tuple, but you get the idea :)

>> Now, I have .tuple members for my colour structs, vectors, quaternions, matrices, and just about every other aggregate type I've written.
>>
>> One thing that would make this an order of magnitude more useful would be the ability to return a tuple from a function.
>>
>> But I agree: it's cool :)
>>
>>     -- Daniel
>>
>> P.S.  I use .tuple instead of .tupleof because I don't want to shadow the very-useful compile-time property :)
> 
> I'm just using the compiler's .tupleof property directly.
> 
> --bb

... *slaps forehead*.

In my defense, tho, I imagine it wouldn't have worked quite as well with the union there :P  Also means I can access the elements as individual variables, as an array *and* as a tuple.  The last one comes in handy for unrolling loops :)

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> 
> Now, I have .tuple members for my colour structs, vectors, quaternions,
> matrices, and just about every other aggregate type I've written.

Nice.

Now, I haven't checked in to the world of D in awhile...  I'm wondering if you've managed to get to the point of automagic unrolling, factoring, and vectorization with these sorts of things (quats, matrices, vectors, points)?

In other words.. can we do something along the lines of ..

  Vec3 A,B,C,D,E;
  Vec3 F = A + (Dot(B-A, C+D) * E);

.. and expect it to generate intelligent code, sans temporaries, time sucking construction, and so on???

This, minus any sort of vectorization, is doable in C++ through some *nasty* template-fu.

What's the state of the art in D?

--Steve

Reply to Stephen,

> Now, I haven't checked in to the world of D in awhile...  I'm
> wondering if you've managed to get to the point of automagic
> unrolling, factoring, and vectorization with these sorts of things
> (quats, matrices, vectors, points)?
> 
[...]
> 
> What's the state of the art in D?
> 
> --Steve
> 

http://www.dsource.org/projects/mathextra/browser/trunk/mathextra/Blade.d

BCS wrote:
> Reply to Stephen,
> 
>> Now, I haven't checked in to the world of D in awhile...  I'm
>> wondering if you've managed to get to the point of automagic
>> unrolling, factoring, and vectorization with these sorts of things
>> (quats, matrices, vectors, points)?
>>
> [...]
>>
>> What's the state of the art in D?
>>
>> --Steve
>>
> 
> http://www.dsource.org/projects/mathextra/browser/trunk/mathextra/Blade.d
> 
>

Seems to have moved slightly, try http://www.dsource.org/projects/mathextra/browser/trunk/blade

David Gileadi wrote:
> BCS wrote:
>> Reply to Stephen,
>>> What's the state of the art in D?
> http://www.dsource.org/projects/mathextra/browser/trunk/blade

What version of DMD should be used to make it compile? At least 1.009 - 1.013 report that they cannot evaluate several functions on compile time.

David Gileadi wrote:
> Seems to have moved slightly, try http://www.dsource.org/projects/mathextra/browser/trunk/blade

Thanks guys.  Looks bitchin.

--Steve

This feature is also really cool for generic programming.  Code that was nearly impossible to write in C++ can be implemented almost trivially.

Bill Baxter wrote:
> I've always had this dilemma in C++ when writing graphicsy methods, whether a function that takes a point should take separate components (float,float,float) or a vector (Vec3f), or perhaps a pointer (float*).  In D there's also the option of float[3].  Or just for convenience sake maybe overloads for all of the above.
> 
> I just realized today the coolness of tupleof for this kind of situation.  You can make the function takes the plain floats
> 
>    do_something_at_point(float x, float y, float z);
> 
> And still call it using a Vec3f via tupleof!
> 
>    Vec3f world_origin;
>    ...
>    do_something_at_point(world_origin.tupleof);
> 
> as opposed to
> 
>    do_something_at_point(
>        world_origin.x,
>        world_origin.y,
>        world_origin.z);
> 
> It's a minor thing, but it rocks.
> 
> 
> --bb