On 30.09.2010 23:10, Trass3r wrote:

> Here's a basic D2 fixed-size vector implementation for you to study:
> http://sfml.svn.sourceforge.net/viewvc/sfml/branches/sfml2/DSFML/import/dsfml/system/vector.d?view=markup

Thanks a lot, I was already looking for an example like that!

-- 
Sebastian Schuberth

On 30.09.2010 22:04, Jonathan M Davis wrote:

> You could initialized it in a static constructor. e.g.
>
> static this()
> {
> 	X = Vector(1, 0, 0);
> }

I'll use that, thanks.

As a side note, I find the syntax quite unfortunate. It reads to me as if the static constructor will only be called if the default constructor is used (I know, this does not make sense as the static constructor will be called before main, and before any non-static constructor). Still, I wonder why not simply the Java syntax

static {
    // ...
}

was adopted.

-- 
Sebastian Schuberth

Sebastian Schuberth <sschuberth@gmail.com> wrote:

> As a side note, I find the syntax quite unfortunate. It reads to me as if the static constructor will only be called if the default constructor is used (I know, this does not make sense as the static constructor will be called before main, and before any non-static constructor). Still, I wonder why not simply the Java syntax
>
> static {
>      // ...
> }
>
> was adopted.

One reason could be that {} are used for grouping in D. e.g all methods
of this struct are static:

struct foo {
    static {
       void bar( ) {};
       string baz( ) {return "Ouch, you poked me!";}
    }
}


-- 
Simen

Trass3r <un@known.com> wrote:

> Here's a basic D2 fixed-size vector implementation for you to study: http://sfml.svn.sourceforge.net/viewvc/sfml/branches/sfml2/DSFML/import/dsfml/system/vector.d?view=markup

I can't help but wonder if those neat SSE functions are a waste.
Functions that use inline assembly cannot be inlined, and thus aren't
necessarily faster than using good old x87. Now, if only DMD had some
intrinsics for that...

-- 
Simen

Simen kjaeraas <simen.kjaras@gmail.com> wrote:

> Trass3r <un@known.com> wrote:
>
>> Here's a basic D2 fixed-size vector implementation for you to study: http://sfml.svn.sourceforge.net/viewvc/sfml/branches/sfml2/DSFML/import/dsfml/system/vector.d?view=markup
>
> I can't help but wonder if those neat SSE functions are a waste.
> Functions that use inline assembly cannot be inlined, and thus aren't
> necessarily faster than using good old x87. Now, if only DMD had some
> intrinsics for that...

Oh, and also (if you don't mind my nitpicking), have you profiled
invSqrt compared to 1/sqrt? Last time I did, I found that invSqrt
was about 50% slower than 1/sqrt.

The one thing I missed when looking at the code was swizzling, so
I implemented it. Feel free to include it if you want, I will
demand nothing for it:


    @property Vector!(T,n.length) opDispatch(string n)() const
        if (allCharsValid(n,"xyzw"[0..dim]))
    {
        static if (n.length == 2) return Vector!(T,n.length)(cell[n[0]-'x'], cell[n[1]-'x']);
        static if (n.length == 3) return Vector!(T,n.length)(cell[n[0]-'x'], cell[n[1]-'x'], cell[n[2]-'x']);
        static if (n.length == 4) return Vector!(T,n.length)(cell[n[0]-'x'], cell[n[1]-'x'], cell[n[2]-'x'], cell[n[3]-'x']);
    }

bool allCharsValid( string s, string valid )
{
    foreach ( e1; s )
    {
        bool b = false;
        foreach (e2; valid)
            b |= e1 == e2;
        if (!b)
            return false;
    }
    return true;
}

I also wanted to allow for swizzled setters, but apparently that's
currently not possible[1].

[1]: http://d.puremagic.com/issues/show_bug.cgi?id=620
-- 
Simen

Sebastian Schuberth:

> With tuples, would it still be that sizeof(Vector)==sizeof(T)*N?

Yes, I think it would (if the types of the tuple are all equal I think there is no padding), a TypeTuple doen't exist at runtime, only its parts exist. In similar situations you save time asking to the compiler.

Bye,
bearophile

On Fri, Oct 1, 2010 at 13:47, Simen kjaeraas <simen.kjaras@gmail.com> wrote:
> I also wanted to allow for swizzled setters, but apparently that's currently not possible

What would swizzled setters look like?

vec.yx = vec.xy ?

vec.xy = [1,0] ?

What about

vec.xxx = [0,1,2];

Would Vec.x be 2 after this?



Philippe

On Fri, Oct 1, 2010 at 08:35, Sebastian Schuberth <sschuberth@gmail.com> wrote:

> You're right, I want exactly N T's, but from reading the section about "Typesafe Variadic Functions" at [1], I thought I'm doing exactly that. The example "For static arrays" has a comment which says for a declaration like
(...)
> would not work, so I thought "...", if following a statically sized array, is a special syntax to allow the array to be initialized from exactly N scalar values.

> So I thought I'm doing the right thing :-)

Wow, I keep forgetting about this syntax. Looking at it in the light of your example, it seems quite useful.


Philippe

> What would swizzled setters look like?
> 
> vec.yx = vec.xy ?

Yes.

> vec.xy = [1,0] ?

Maybe. Or like

vec.xy = Vector!2(1,0);

> vec.xxx = [0,1,2];

No. To be an lvalue the swizzling must not contain duplicate components.

For more information see p65 in the GLSL Spec.

http://www.opengl.org/registry/doc/GLSLangSpec.4.00.8.clean.pdf

Frank

Am 01.10.2010, 13:47 Uhr, schrieb Simen kjaeraas <simen.kjaras@gmail.com>:

> Oh, and also (if you don't mind my nitpicking), have you profiled
> invSqrt compared to 1/sqrt? Last time I did, I found that invSqrt
> was about 50% slower than 1/sqrt.

Haven't profiled it yet.


> The one thing I missed when looking at the code was swizzling, so
> I implemented it. Feel free to include it if you want

Thx, I incorporated it :)


> I also wanted to allow for swizzled setters, but apparently that's
> currently not possible[1].
>
> [1]: http://d.puremagic.com/issues/show_bug.cgi?id=620

What a pity!