January 13, 2012
On 1/13/12 3:08 PM, Manu wrote:
> On 13 January 2012 22:57, bearophile <bearophileHUGS@lycos.com
> <mailto:bearophileHUGS@lycos.com>> wrote:
>
>     Walter:
>
>      > What's our vector, Victor?
>      > http://www.youtube.com/watch?v=fVq4_HhBK8Y
>
>     Thank you Walter :-)
>
>
>      > If int4 is out, I'd prefer something like vint4. Something short.
>
>     Current names:
>
>     void16
>     double2
>     float4
>     byte16
>     ubyte16
>     short8
>     ushort8
>     int4
>     uint4
>     long2
>
>     Your suggestion:
>
>     vvoid16
>     vdouble2
>     vfloat4
>     vbyte16
>     vubyte16
>     vshort8
>     vushort8
>     vint4
>     vuint4
>     vlong2
>
>
>     My suggestion:
>
>     void16v
>     double2v
>     float4v
>     byte16v
>     ubyte16v
>     short8v
>     ushort8v
>     int4v
>     uint4v
>     long2v
>
>     Bye,
>     bearophile
>
>
> I think I'd vote for leaving it as it is, swayed by the fact that the
> more ambiguous types are super-rarely used. float4/int4 has a nice
> familiarity with HLSL/Cg.

All names should have a __ prepended, and then the library defines names for them such as vec!(int, 4) that obey module lookup and all. Dumping a wheelbarrow of confusable new keywords doesn't sound right at all.

Andrei
January 13, 2012
On 14 January 2012 00:31, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> wrote:

> On 1/13/12 2:41 PM, Walter Bright wrote:
>
>> On 1/13/2012 12:27 PM, Peter Alexander wrote:
>>
>>> On 13/01/12 8:02 PM, Mehrdad wrote:
>>>
>>>> Er... is there any reason why we're using such a cryptic PXOR value instead of operator overloading?
>>>>
>>>
>>> I imagine Walter will add the operator overloads later.
>>>
>>
>> Right. simd() is just the bottom layer building block. It's a compiler intrinsic, and I don't want to make every overload a compiler intrinsic.
>>
>
> People will want to pass a variable for op. Would that work?


...I really don't think they will.
and most people would never dive this deep if the standard lib does its job
properly.


January 13, 2012
On 01/13/2012 11:36 PM, Andrei Alexandrescu wrote:
> On 1/13/12 3:08 PM, Manu wrote:
>> On 13 January 2012 22:57, bearophile <bearophileHUGS@lycos.com
>> <mailto:bearophileHUGS@lycos.com>> wrote:
>>
>> Walter:
>>
>> > What's our vector, Victor?
>> > http://www.youtube.com/watch?v=fVq4_HhBK8Y
>>
>> Thank you Walter :-)
>>
>>
>> > If int4 is out, I'd prefer something like vint4. Something short.
>>
>> Current names:
>>
>> void16
>> double2
>> float4
>> byte16
>> ubyte16
>> short8
>> ushort8
>> int4
>> uint4
>> long2
>>
>> Your suggestion:
>>
>> vvoid16
>> vdouble2
>> vfloat4
>> vbyte16
>> vubyte16
>> vshort8
>> vushort8
>> vint4
>> vuint4
>> vlong2
>>
>>
>> My suggestion:
>>
>> void16v
>> double2v
>> float4v
>> byte16v
>> ubyte16v
>> short8v
>> ushort8v
>> int4v
>> uint4v
>> long2v
>>
>> Bye,
>> bearophile
>>
>>
>> I think I'd vote for leaving it as it is, swayed by the fact that the
>> more ambiguous types are super-rarely used. float4/int4 has a nice
>> familiarity with HLSL/Cg.
>
> All names should have a __ prepended, and then the library defines names
> for them such as vec!(int, 4) that obey module lookup and all. Dumping a
> wheelbarrow of confusable new keywords doesn't sound right at all.
>
> Andrei

All of those are library types defined in core.simd.

For example, float4 is declared as

alias Vector!(float[4]) float4

And Vector simply hides what is built-in.

template Vector(T){
    alias __vector(T) Vector;
}

I think this is a very clean design.



January 13, 2012
On 14 January 2012 00:36, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> wrote:

> On 1/13/12 3:08 PM, Manu wrote:
>
>> On 13 January 2012 22:57, bearophile <bearophileHUGS@lycos.com <mailto:bearophileHUGS@lycos.**com <bearophileHUGS@lycos.com>>> wrote:
>>
>>    Walter:
>>
>>     > What's our vector, Victor?
>>     > http://www.youtube.com/watch?**v=fVq4_HhBK8Y<http://www.youtube.com/watch?v=fVq4_HhBK8Y>
>>
>>    Thank you Walter :-)
>>
>>
>>     > If int4 is out, I'd prefer something like vint4. Something short.
>>
>>    Current names:
>>
>>    void16
>>    double2
>>    float4
>>    byte16
>>    ubyte16
>>    short8
>>    ushort8
>>    int4
>>    uint4
>>    long2
>>
>>    Your suggestion:
>>
>>    vvoid16
>>    vdouble2
>>    vfloat4
>>    vbyte16
>>    vubyte16
>>    vshort8
>>    vushort8
>>    vint4
>>    vuint4
>>    vlong2
>>
>>
>>    My suggestion:
>>
>>    void16v
>>    double2v
>>    float4v
>>    byte16v
>>    ubyte16v
>>    short8v
>>    ushort8v
>>    int4v
>>    uint4v
>>    long2v
>>
>>    Bye,
>>    bearophile
>>
>>
>> I think I'd vote for leaving it as it is, swayed by the fact that the more ambiguous types are super-rarely used. float4/int4 has a nice familiarity with HLSL/Cg.
>>
>
> All names should have a __ prepended, and then the library defines names for them such as vec!(int, 4) that obey module lookup and all. Dumping a wheelbarrow of confusable new keywords doesn't sound right at all.


These ARE the library defined types we're talking about, defined in simd.d


January 13, 2012
On 1/13/2012 11:06 AM, Peter Alexander wrote:
> Also, slight bikeshedding issue: I'm not so sure on using names like int4 for
> vectors. You see things like int32 a lot to mean a 32-bit integer, or int8 to
> mean an 8-bit integer. Using this notation for vectors may be confusing.

Consider also that the int8 is an alias, not a keyword. This means that the compiler will inform you of any ambiguities, as well as allow:

   core.simd.int8

to disambiguate.
January 13, 2012
On 13/01/12 10:31 PM, Andrei Alexandrescu wrote:
> On 1/13/12 2:41 PM, Walter Bright wrote:
>> On 1/13/2012 12:27 PM, Peter Alexander wrote:
>>> On 13/01/12 8:02 PM, Mehrdad wrote:
>>>> Er... is there any reason why we're using such a cryptic PXOR value
>>>> instead of operator overloading?
>>>
>>> I imagine Walter will add the operator overloads later.
>>
>> Right. simd() is just the bottom layer building block. It's a compiler
>> intrinsic, and I don't want to make every overload a compiler intrinsic.
>
> People will want to pass a variable for op. Would that work?

Why would people want to do that?

Also, no, it can't possibly work. It just makes no sense.

January 13, 2012
On 01/13/2012 11:29 PM, Andrei Alexandrescu wrote:
> On 1/13/12 2:37 PM, Walter Bright wrote:
>> If int4 is out, I'd prefer something like vint4. Something short.
>
> Something short must compensate its potential for confusion with
> frequent usage and well-established convention. Arguably neither applies
> here.
>
> Andrei
>

Both apply.

Frequent usage: Under the precondition that core.simd is imported, of course.
Well-Established convention: See GLSL/HLSL/OpenCL/...
January 13, 2012
On 1/13/2012 2:31 PM, Andrei Alexandrescu wrote:
> People will want to pass a variable for op. Would that work?

It'll currently fail miserably - it has to be a constant. Otherwise, we have runtime code generation. While not impossible, it is a large increase in scope.
January 13, 2012
On 1/13/2012 2:36 PM, Andrei Alexandrescu wrote:
> All names should have a __ prepended, and then the library defines names for
> them such as vec!(int, 4) that obey module lookup and all. Dumping a wheelbarrow
> of confusable new keywords doesn't sound right at all.

They're not keywords, they are (literally) simple aliases:

   alias Vector!(int[4]) int4;

As aliases, they obey all scoping and disambiguation rules, which I think is superior to using __ prefixes.

You could use Vector!(int[4]) everywhere instead, but I submit it's a bit klunky to do that and might as well provide a set of aliases (or else people will produce their own aliases and they'll all have different spellings).
January 13, 2012
On 13/01/12 10:55 PM, Walter Bright wrote:
> On 1/13/2012 11:06 AM, Peter Alexander wrote:
>> Also, slight bikeshedding issue: I'm not so sure on using names like
>> int4 for
>> vectors. You see things like int32 a lot to mean a 32-bit integer, or
>> int8 to
>> mean an 8-bit integer. Using this notation for vectors may be confusing.
>
> Consider also that the int8 is an alias, not a keyword. This means that
> the compiler will inform you of any ambiguities, as well as allow:
>
> core.simd.int8
>
> to disambiguate.

I realize that. It's just that I mentally associate the identifier int8 with an 8-bit integer as it is something I regularly see in C++ code.

However, I'm willing to drop my position. After a quick Google, I discovered that it's not as common as I thought. I'm happy to keep float4 etc. since it is simple and is already used in a couple of shader languages.