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