It'd be really cool if I could do this:

	void func(int[] vector, int[] bounds) {
		assert(vector[] >= 0 && vector[] < bounds[]);
		...
	}

Is there any reason why we shouldn't implement this?


T

-- 
He who laughs last thinks slowest.

On 03/06/2012 09:30 PM, H. S. Teoh wrote:
> It'd be really cool if I could do this:
>
> 	void func(int[] vector, int[] bounds) {
> 		assert(vector[]>= 0&&  vector[]<  bounds[]);
> 		...
> 	}
>
> Is there any reason why we shouldn't implement this?
>
>
> T
>

Comparing arrays already does lexical-style comparison (which makes sense).

On 3/6/2012 2:30 PM, H. S. Teoh wrote:
> It'd be really cool if I could do this:
>
> 	void func(int[] vector, int[] bounds) {
> 		assert(vector[]>= 0&&  vector[]<  bounds[]);
> 		...
> 	}
>
> Is there any reason why we shouldn't implement this?
>
>
> T
>

This same problem exists for making proper syntactical sugar for simd comparison functions.

!= ==  (opEquals is required to return a bool)

and

<= >= < > (opCmp is required to return an int)


Granted its possible to live without the sugar but the code looks more like asm, and reading the code takes longer without the operators in it.

On Tue, 06 Mar 2012 21:35:11 +0100, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 03/06/2012 09:30 PM, H. S. Teoh wrote:
>> It'd be really cool if I could do this:
>>
>> 	void func(int[] vector, int[] bounds) {
>> 		assert(vector[]>= 0&&  vector[]<  bounds[]);
>> 		...
>> 	}
>>
>> Is there any reason why we shouldn't implement this?
>>
>>
>> T
>>
>
> Comparing arrays already does lexical-style comparison (which makes sense).

Comparing two arrays makes sense, absolutely. Comparing one T[] and
one T currently does not. Also, foo[] already changes the behavior of
operators on foo, making it do a per-element compare would be in line
with this pattern.

This is also already in bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=5636

On Tuesday, 6 March 2012 at 20:28:40 UTC, H. S. Teoh wrote:
> It'd be really cool if I could do this:
>
> 	void func(int[] vector, int[] bounds) {
> 		assert(vector[] >= 0 && vector[] < bounds[]);
> 		...
> 	}
>
> Is there any reason why we shouldn't implement this?
>
>
> T

Would this be possible with UFCS?

int opCmp(T)T([] array, T element) { ... }
int opCmp(T)(T[] array1, T[] array2) { ... }

On 7 March 2012 10:58, Kapps <opantm2+spam@gmail.com> wrote:
> On Tuesday, 6 March 2012 at 20:28:40 UTC, H. S. Teoh wrote:
>>
>> It'd be really cool if I could do this:
>>
>>        void func(int[] vector, int[] bounds) {
>>                assert(vector[] >= 0 && vector[] < bounds[]);
>>
>>                ...
>>        }
>>
>> Is there any reason why we shouldn't implement this?
>>
>>
>> T
>
>
> Would this be possible with UFCS?
>
> int opCmp(T)T([] array, T element) { ... }
> int opCmp(T)(T[] array1, T[] array2) { ... }

I like this idea, at least adding an opSliceCmp operator-overload would do as a start, I think thats the correct name for it. I can't be bothered to check.

--
James Miller

On Tuesday, 6 March 2012 at 23:57:07 UTC, James Miller wrote:
> On 7 March 2012 10:58, Kapps <opantm2+spam@gmail.com> wrote:
>> On Tuesday, 6 March 2012 at 20:28:40 UTC, H. S. Teoh wrote:
>>>
>>> It'd be really cool if I could do this:
>>>
>>>        void func(int[] vector, int[] bounds) {
>>>                assert(vector[] >= 0 && vector[] < bounds[]);
>>>
>>>                ...
>>>        }
>>>
>>> Is there any reason why we shouldn't implement this?
>>>
>>>
>>> T
>>
>>
>> Would this be possible with UFCS?
>>
>> int opCmp(T)T([] array, T element) { ... }
>> int opCmp(T)(T[] array1, T[] array2) { ... }
>
> I like this idea, at least adding an opSliceCmp operator-overload
> would do as a start, I think thats the correct name for it. I can't be
> bothered to check.
>
> --
> James Miller

It has to be done as vector operations.

a[] < b[] should equal [a[0] < b[0], a[1] < b[1], ... ]

What the OP has asked for is not a vector operation, so it shouldn't use the vector op syntax.

On 7 March 2012 15:35, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> On Tuesday, 6 March 2012 at 23:57:07 UTC, James Miller wrote:
>>
>> On 7 March 2012 10:58, Kapps <opantm2+spam@gmail.com> wrote:
>>>
>>> On Tuesday, 6 March 2012 at 20:28:40 UTC, H. S. Teoh wrote:
>>>>
>>>>
>>>> It'd be really cool if I could do this:
>>>>
>>>>        void func(int[] vector, int[] bounds) {
>>>>                assert(vector[] >= 0 && vector[] < bounds[]);
>>>>
>>>>                ...
>>>>        }
>>>>
>>>> Is there any reason why we shouldn't implement this?
>>>>
>>>>
>>>> T
>>>
>>>
>>>
>>> Would this be possible with UFCS?
>>>
>>> int opCmp(T)T([] array, T element) { ... }
>>> int opCmp(T)(T[] array1, T[] array2) { ... }
>>
>>
>> I like this idea, at least adding an opSliceCmp operator-overload would do as a start, I think thats the correct name for it. I can't be bothered to check.
>>
>> --
>> James Miller
>
>
> It has to be done as vector operations.
>
> a[] < b[] should equal [a[0] < b[0], a[1] < b[1], ... ]
>
> What the OP has asked for is not a vector operation, so it shouldn't use the vector op syntax.

What? I'm assuming you mean that you expect an array of `bool`s? While I agree that most vector operations should return a vector, comparison makes more sense as returning a straight bool, most of the time you aren't going to want to just have an array of bools. The only use case i can think of is this:

auto c = a[] < b[]
foreach (i : c) {
    if (i) doSomething();
    else doSomethingElse();
}

Which can be easily re-written as

for (int i; i < a.length; i++) {
    if (a[i] < b[i]) doSomething();
    else doSomethingElse();
}

(ignoring things like proper checking etc.)

Of course most vector ops should return vectors, but most other ops return proper types too, comparison ops tend to be the exception to the rule.

--
James Miller

James Miller:

> What? I'm assuming you mean that you expect an array of `bool`s?

Right. Vector operations like a[]<b[] are meant to return an array of bools. To see how this is useful you probably must think in terms of vector-style programming. In NumPy the use of arrays of booleans is common:

>>> from numpy import *
>>> a = array([3,6,8,9])
>>> a == 6
array([False,  True, False, False], dtype=bool)
>>> a >= 7
array([False, False,  True,  True], dtype=bool)
>>> a < 5
array([ True, False, False, False], dtype=bool)
>>> # count all the even numbers
>>> sum( (a%2) == 0 )
2
>>> b = array([2,6,7,10])
>>> a == b
array([False,  True, False, False], dtype=bool)
>>> a < b
array([False, False, False,  True], dtype=bool)


They are sometimes used as masks, it's useful if you have a Vector type that supports multi-index syntax:

i = scipy.array([0,1,2,1]) # array of indices for the first axis
j = scipy.array([1,2,3,4]) # array of indices for the second axis
a[i,j] # return array([a[0,1], a[1,2], a[2,3], a[1,4]])
b = scipy.array([True, False, True, False])
a[b] # return array([a[0], a[2]]) since only b[0] and b[2] are True


Using the new CPU AVX registers you are able to perform a loop and work on the items of an array in parallel until all the booleans of an array are false. See this, expecially Listing 5:

http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions/

http://www.cs.uaf.edu/2011/spring/cs641/lecture/04_12_AVX.html

Vector comparisons have a natural hardware implementataion with AVX/AVX2 instructions like _mm256_cmp_ps.

Bye,
bearophile

On 7 March 2012 17:03, bearophile <bearophileHUGS@lycos.com> wrote:
> James Miller:
>
>> What? I'm assuming you mean that you expect an array of `bool`s?
>
> Right. Vector operations like a[]<b[] are meant to return an array of bools. To see how this is useful you probably must think in terms of vector-style programming. In NumPy the use of arrays of booleans is common:
>
>>>> from numpy import *
>>>> a = array([3,6,8,9])
>>>> a == 6
> array([False,  True, False, False], dtype=bool)
>>>> a >= 7
> array([False, False,  True,  True], dtype=bool)
>>>> a < 5
> array([ True, False, False, False], dtype=bool)
>>>> # count all the even numbers
>>>> sum( (a%2) == 0 )
> 2
>>>> b = array([2,6,7,10])
>>>> a == b
> array([False,  True, False, False], dtype=bool)
>>>> a < b
> array([False, False, False,  True], dtype=bool)
>
>
> They are sometimes used as masks, it's useful if you have a Vector type that supports multi-index syntax:
>
> i = scipy.array([0,1,2,1]) # array of indices for the first axis
> j = scipy.array([1,2,3,4]) # array of indices for the second axis
> a[i,j] # return array([a[0,1], a[1,2], a[2,3], a[1,4]])
> b = scipy.array([True, False, True, False])
> a[b] # return array([a[0], a[2]]) since only b[0] and b[2] are True
>
>
> Using the new CPU AVX registers you are able to perform a loop and work on the items of an array in parallel until all the booleans of an array are false. See this, expecially Listing 5:
>
> http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions/
>
> http://www.cs.uaf.edu/2011/spring/cs641/lecture/04_12_AVX.html
>
> Vector comparisons have a natural hardware implementataion with AVX/AVX2 instructions like _mm256_cmp_ps.
>
> Bye,
> bearophile

Hmm, I see your point, I think that with D's current operator overloading you could implement most of that. Other than the comparison syntax.

If vector comparison gets added, then there should be some very clear documentation that it returns a vector, because I can imagine using it in an if statement and then wondering why it always went through...