Should we add `a * b` to ndslice for 1d vectors?
Discussion at https://github.com/libmir/mir-algorithm/issues/91

On Friday, 22 September 2017 at 17:11:56 UTC, Ilya Yaroshenko wrote:
> Should we add `a * b` to ndslice for 1d vectors?
> Discussion at https://github.com/libmir/mir-algorithm/issues/91

My position is still that it can't hurt to add a dot product function and other arithmetic or linear algebra functions that might be used in the future with operator overloading. Ideally they could switch to other mir implementations at compile time if those have been imported.

On 23 September 2017 at 03:11, Ilya Yaroshenko via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> Should we add `a * b` to ndslice for 1d vectors?
> Discussion at https://github.com/libmir/mir-algorithm/issues/91
>

I often ponder this sort of question... and while the nerdy bit of my would
love to see this, I can never get past the fact that `is(typeof(a) !=
typeof(a * b))`... I feel that's a big enough reason to put a bullet in the
idea. D has array operations, which look just like 1d ndslices, also SIMD
vectors usually implement operators, but they do element-wise operation, so
now there's a confusion.
Consider, a generic function receives some T; if T is a slice or simd, it
does element-wise stuff, if T is an ndslice, it behaves differently. That
doesn't seem right.

On Sunday, 24 September 2017 at 05:24:57 UTC, Manu wrote:
> On 23 September 2017 at 03:11, Ilya Yaroshenko via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> Should we add `a * b` to ndslice for 1d vectors?
>> Discussion at https://github.com/libmir/mir-algorithm/issues/91
>>
>
> I often ponder this sort of question... and while the nerdy bit of my would
> love to see this, I can never get past the fact that `is(typeof(a) !=
> typeof(a * b))`... I feel that's a big enough reason to put a bullet in the
> idea. D has array operations, which look just like 1d ndslices, also SIMD
> vectors usually implement operators, but they do element-wise operation, so
> now there's a confusion.
> Consider, a generic function receives some T; if T is a slice or simd, it
> does element-wise stuff, if T is an ndslice, it behaves differently. That
> doesn't seem right.

Python has a dedicated matrix multiplication operator, that is not used by the standard library, but is implemented for e.g. numpy arrays.

https://www.python.org/dev/peps/pep-0465/

On Friday, 22 September 2017 at 17:11:56 UTC, Ilya Yaroshenko wrote:
> Should we add `a * b` to ndslice for 1d vectors?
> Discussion at https://github.com/libmir/mir-algorithm/issues/91

Generally I expect that a binary operation denoted by + or * would produce an element from the original domain, e.g. multiplying two matrices yields a matrix, concatenating two strings yields a string, etc. So personally I don't like this notation.

Note that in the case of 3-dimensional vectors, people might confuse this for the cross product. I would go with dot(a,b) and cross(a,b) (if you support it).

On Sun, Sep 24, 2017 at 06:18:38PM +0000, Mark via Digitalmars-d wrote:
> On Friday, 22 September 2017 at 17:11:56 UTC, Ilya Yaroshenko wrote:
> > Should we add `a * b` to ndslice for 1d vectors?
> > Discussion at https://github.com/libmir/mir-algorithm/issues/91
> 
> Generally I expect that a binary operation denoted by + or * would produce an element from the original domain, e.g. multiplying two matrices yields a matrix, concatenating two strings yields a string, etc. So personally I don't like this notation.
> 
> Note that in the case of 3-dimensional vectors, people might confuse this
> for the cross product. I would go with dot(a,b) and cross(a,b) (if you
> support it).

With UFCS, you have the slightly nicer notation a.dot(b) and a.cross(b).


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine

On Sunday, 24 September 2017 at 18:18:38 UTC, Mark wrote:
>
> Generally I expect that a binary operation denoted by + or * would produce an element from the original domain, e.g. multiplying two matrices yields a matrix, concatenating two strings yields a string, etc. So personally I don't like this notation.

This is true of element-wise operators. + works, - works, but * (and by implication /) only has that property for Hadamard/Schur products. It also would work for inverse. Even matrix multiplication could have A*B produce a matrix, but if A is 1XN and B is MX1, then you may as well return the scalar.

>
> Note that in the case of 3-dimensional vectors, people might confuse this for the cross product. I would go with dot(a,b) and cross(a,b) (if you support it).

I assure you, no one would confuse dot for cross. No language or linear algebra library does this. The typical option is matrix multiplication for *, but languages like Python and Matlab can't do things like have a special version that is dot for vectors and matrix multiplication for matrices.

On Sunday, 24 September 2017 at 22:33:48 UTC, H. S. Teoh wrote:
>
> With UFCS, you have the slightly nicer notation a.dot(b) and a.cross(b).
>
>
> T

Below is a link to the operators in Matlab and associated functions. mir can include all of those functions, but not all of them can be implemented as operators (because D doesn't have things like .*). I think it would be annoying to constantly have to write plus or mtimes in writing formulas for a linear algebra library.

https://www.mathworks.com/help/matlab/matlab_prog/matlab-operators-and-special-characters.html

On Sunday, 24 September 2017 at 23:59:59 UTC, jmh530 wrote:
> On Sunday, 24 September 2017 at 22:33:48 UTC, H. S. Teoh wrote:
>>
>> With UFCS, you have the slightly nicer notation a.dot(b) and a.cross(b).
>>
>>
>> T
>
> Below is a link to the operators in Matlab and associated functions. mir can include all of those functions, but not all of them can be implemented as operators (because D doesn't have things like .*). I think it would be annoying to constantly have to write plus or mtimes in writing formulas for a linear algebra library.
>
> https://www.mathworks.com/help/matlab/matlab_prog/matlab-operators-and-special-characters.html

There's nothing stopping someone writing a DIP to include `@` (and possibly `#`) as overloadable binary operators. All other characters on the standard keyboard are used I think.

On Monday, 25 September 2017 at 01:08:35 UTC, Nicholas Wilson wrote:
> There's nothing stopping someone writing a DIP to include `@` (and possibly `#`) as overloadable binary operators. All other characters on the standard keyboard are used I think.

̣̣§