simd comparison operator?

[tn]

On Tuesday, 19 February 2013 at 16:28:15 UTC, John Colvin wrote:
> On Tuesday, 19 February 2013 at 16:03:58 UTC, bearophile wrote:
>> Don:
>>
>>> Simd comparison generally doesn't return a bool, it returns a 
>>> bool array,
>>> one per element.
>>>
>>> Does  (arr[] < 10) mean "is every element in arr less than 
>>> 10" OR "is any element of arr less than 10" OR "create a bool 
>>> array which is true for each element which is less than 10" ?
>>>
>>> All make sense. That's the problem.
>>
>> Right, it's a design problem.
>> I think the right thing to do is to take a look at what's an 
>> efficient operation to do in hardware (and then look at what's 
>> the most commonly useful operation for users). I think the 
>> right design here is to return a bool[N].
>> So in this case monarch_dodra has to add some more code to 
>> test all/any.
>>
>> Bye,
>> bearophile
>
> There is significant opposition to any simd operators that 
> allocate. The reasoning is that they appear fast but are in 
> actual fact slow (for most normal size vectors, the allocation 
> would be much slower than the calculation itself).
>
> I love the features of numpy and matlab etc. when it comes to 
> array operations, many of which allocate implicitly, but Walter 
> and others were quite adamant they they do not belong in D, a 
> position I've come to agree with.

In many cases it would be nice, if "arr[] < x" translated to 
"map!(a => a < x)(arr)" and similarly "arr1[] < arr2[]" 
translated to "map!((a, b) => a < b)(arr1, arr2)" or equivalent 
(*). Then for example, if "all" and "any" had "a => a" as a 
default predicate, it would be possible to write for example "if 
(any(arr[] < 10)) ...". As far as I understand, this does not 
allocate.


(*) Also, it would be nice if "map!((a, b) => a < b)(arr1, arr2)" 
was a valid syntax. (Or if it is, then it should be documented.)