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.

I actually like * for dot product and matrix multiplication...

The issue is that if you use * for these, then you can't use it for element-wise multiplication. Numpy arrays (but not matrices) use * and / for element-wise multiplication and division. To do matrix multiplication with Numpy arrays, you used to have to use the dot function. This is they decided to introduce @ to the language, b/c users didn't want to write dot all over the place.

A very popular language with a wide range of uses had to introduce a new operator to the language because of design choices of its most popular linear algebra library. So it makes sense to think about these issues a bit.

> All other characters on the standard keyboard are used I think.

What about forward slash '\' (for inverse)? That is currently used for string literals, but I can't think of a binary use right now.

On Monday, 25 September 2017 at 03:22:01 UTC, user1234 wrote:
> 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.
>
> ̣̣§

That is not on mine.

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

I'd say yes.

Atila

On 26 September 2017 at 21:41, Atila Neves via Digitalmars-d < digitalmars-d@puremagic.com> 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
>>
>
> I'd say yes.
>
> Atila
>


Just remember, it's okay to vote no! Even if it makes you a bigoted dick ;)
In this case, I think 'no' is the only reasonable choice.
If this is going to seriously be considered, then ndslice should definitely
be renamed to 'matrix'.

An alternative solution might be to introduce a wrapper of ndslice called 'matrix' that supports matrix mul...?

On Wednesday, 27 September 2017 at 04:59:10 UTC, Manu wrote:
> On 26 September 2017 at 21:41, Atila Neves via Digitalmars-d < digitalmars-d@puremagic.com> 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
>>>
>>
>> I'd say yes.
>>
>> Atila
>>
>
>
> Just remember, it's okay to vote no! Even if it makes you a bigoted dick ;)
> In this case, I think 'no' is the only reasonable choice.
> If this is going to seriously be considered, then ndslice should definitely
> be renamed to 'matrix'.
>
> An alternative solution might be to introduce a wrapper of ndslice called 'matrix' that supports matrix mul...?

I would prefer outer operator overloading be added to D instead of type wrappers. So a user can import a library for operations, rather then library of wrappers. --Ilya

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

If it is for element-wise product, then possibly yes.
If it is for dot product (as suggested by the github issue), then definitely no.

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

Unless it's always just simple element-wise, make it a different type. N-dimensional rectangular data structures are only sometimes matrices.

Also, if you did two different types I have concerns about code that mixed the two, it would become quite unclear which ones were matrix operations and which were element-wise.

On Wednesday, 27 September 2017 at 04:59:10 UTC, Manu wrote:
>
> An alternative solution might be to introduce a wrapper of ndslice called 'matrix' that supports matrix mul...?

That's exactly how Numpy works with array and matrix types. It's confusing. That being said, mir has Contiguous/Universal/Canonical, which are also a little confusing...

On Wednesday, 27 September 2017 at 07:41:23 UTC, Ilya Yaroshenko wrote:
>
> I would prefer outer operator overloading be added to D instead of type wrappers. So a user can import a library for operations, rather then library of wrappers. --Ilya

This might be a step in the right direction. It doesn't need to be full-blown extension methods/partial classes. Just the ability to treat operator overloading like free-standing functions (with power of UFCS). Something like:

struct Foo
{
    int data;
}

Foo opBinary!(string op)(Foo x, Foo y)
{
    return mixin("x.data" ~ op ~ "y.data");
}

That would mean you could also do something like:
import lubeck : opBinary;

On 27 September 2017 at 17:41, Ilya Yaroshenko via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Wednesday, 27 September 2017 at 04:59:10 UTC, Manu wrote:
>
>> On 26 September 2017 at 21:41, Atila Neves via Digitalmars-d < digitalmars-d@puremagic.com> 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
>>>>
>>>>
>>> I'd say yes.
>>>
>>> Atila
>>>
>>>
>>
>> Just remember, it's okay to vote no! Even if it makes you a bigoted dick
>> ;)
>> In this case, I think 'no' is the only reasonable choice.
>> If this is going to seriously be considered, then ndslice should
>> definitely
>> be renamed to 'matrix'.
>>
>> An alternative solution might be to introduce a wrapper of ndslice called 'matrix' that supports matrix mul...?
>>
>
> I would prefer outer operator overloading be added to D instead of type wrappers. So a user can import a library for operations, rather then library of wrappers. --Ilya
>

I don't really think this will work in a reasonable way in D even if it
were added.
D does not have ADL, which will almost certainly lead to _very_ nasty
surprises in behaviour.