digitalmars.D - Extend vector ops to boolean operators?

H. S. Teoh (9/9) Mar 06 2012 It'd be really cool if I could do this:

Timon Gehr (2/9) Mar 06 2012 Comparing arrays already does lexical-style comparison (which makes sens...

H. S. Teoh (14/25) Mar 06 2012 What I wanted is not lexicographic comparison, but per-element

Timon Gehr (3/26) Mar 07 2012 I know. You asked for reasons why it shouldn't be implemented. The main

=?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= (7/22) Mar 06 2012 Comparing two arrays makes sense, absolutely. Comparing one T[] and

Timon Gehr (6/30) Mar 07 2012 No, it does not change their behavior, it is just required to allow

Sean Cavanaugh (8/15) Mar 06 2012 This same problem exists for making proper syntactical sugar for simd
Kapps (4/11) Mar 06 2012 Would this be possible with UFCS?

James Miller (7/24) Mar 06 2012 I like this idea, at least adding an opSliceCmp operator-overload

Peter Alexander (5/34) Mar 06 2012 It has to be done as vector operations.

James Miller (24/63) Mar 06 2012 the

bearophile (20/31) Mar 06 2012 array([False, True, False, False], dtype=bool)

James Miller (14/45) Mar 06 2012 ls. To see how this is useful you probably must think in terms of vector...

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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.

Mar 06 2012

Timon Gehr <timon.gehr gmx.ch> writes:

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).

Mar 06 2012

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Tue, Mar 06, 2012 at 09:35:11PM +0100, Timon Gehr 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?


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

What I wanted is not lexicographic comparison, but per-element
comparison:

	v[]>=0   means  v[0]>0 && v[1]>0 && v[2]>0 && ...
	v[]<b[]  means  v[0]<b[0] && v[1]<b[1] && v[2]<b[2] && ...

as opposed to lexicographical:

	v < b  means  (v[0]!=b[0]) ? v[0]<b[0] :
			(v[1]!=b[1]) ? v[1]<b[1] :
			(v[2]!=b[2]) ? v[2]<b[2] :
			...


T

-- 
This is not a sentence.

Mar 06 2012

Timon Gehr <timon.gehr gmx.ch> writes:

On 03/06/2012 09:58 PM, H. S. Teoh wrote:
 On Tue, Mar 06, 2012 at 09:35:11PM +0100, Timon Gehr 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?


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

 What I wanted is not lexicographic comparison, but per-element
 comparison:

 	v[]>=0   means  v[0]>0&&  v[1]>0&&  v[2]>0&&  ...
 	v[]<b[]  means  v[0]<b[0]&&  v[1]<b[1]&&  v[2]<b[2]&&  ...

 as opposed to lexicographical:

 	v<  b  means  (v[0]!=b[0]) ? v[0]<b[0] :
 			(v[1]!=b[1]) ? v[1]<b[1] :
 			(v[2]!=b[2]) ? v[2]<b[2] :
 			...


 T

I know. You asked for reasons why it shouldn't be implemented. The main 
reason is that it is already valid code with different semantics.

Mar 07 2012

=?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:

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

Mar 06 2012

Timon Gehr <timon.gehr gmx.ch> writes:

On 03/06/2012 10:10 PM, Simen Kjærås wrote:
 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,


No, it does not change their behavior, it is just required to allow 
them. Array slices have value semantics, and foo[] is currently 
shorthand for foo[0..$].


 making it do a per-element compare would be in line
 with this pattern.

Making array slicing change the behavior of some operator wouldn't have 
any precedent.

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

Mar 07 2012

Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:

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.

Mar 06 2012

"Kapps" <opantm2+spam gmail.com> writes:

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) { ... }

Mar 06 2012

James Miller <james aatch.net> writes:

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:

 =C2=A0 =C2=A0 =C2=A0 =C2=A0void func(int[] vector, int[] bounds) {
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assert(vector[] >=


=3D 0 && vector[] < bounds[]);
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

 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

Mar 06 2012

"Peter Alexander" <peter.alexander.au gmail.com> writes:

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.

Mar 06 2012

James Miller <james aatch.net> writes:

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:

 =C2=A0 =C2=A0 =C2=A0 =C2=A0void func(int[] vector, int[] bounds) {
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assert(vector[]=



=3D 0 && vector[] < bounds[]);
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

 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 =3D 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

Mar 06 2012

bearophile <bearophileHUGS lycos.com> writes:

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)

 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:




b = scipy.array([True, False, True, False])



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

Mar 06 2012

James Miller <james aatch.net> writes:

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 boo=

ls. To see how this is useful you probably must think in terms of vector-st=
yle programming. In NumPy the use of arrays of booleans is common:
 from numpy import *
 a =3D array([3,6,8,9])
 a =3D=3D 6



 array([False, =C2=A0True, False, False], dtype=3Dbool)
 a >=3D 7



 array([False, False, =C2=A0True, =C2=A0True], dtype=3Dbool)
 a < 5



 array([ True, False, False, False], dtype=3Dbool)

 sum( (a%2) =3D=3D 0 )



 2
 b =3D array([2,6,7,10])
 a =3D=3D b



 array([False, =C2=A0True, False, False], dtype=3Dbool)
 a < b



 array([False, False, False, =C2=A0True], dtype=3Dbool)


 They are sometimes used as masks, it's useful if you have a Vector type t=

hat supports multi-index syntax:



 b =3D scipy.array([True, False, True, False])



 Using the new CPU AVX registers you are able to perform a loop and work o=

n 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-v=

ector-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...

Mar 06 2012

D Programming

C/C++ Programming

Other

digitalmars.D - Extend vector ops to boolean operators?