lvalue semantic for diag

[SylvainCorlay]

It would make sense for diag to return an assignable view.

[JohanMabille]

In that case let's do the same for triu, tril, and flipud/flipr. This has be mentioned in #158.

[SylvainCorlay]

The flip versions should be doable with views ans dynamic views eventually as mentioned by @wolfv in the original implementation.

Diag probably requires a specific view.

[wolfv]

But diag is actually not a view in NumPy.
To be honest I don't even know if it is a good idea to make the flips views. This might be just an artifact on how it's implemented in NumPy. I wouldn't really expect the source array to change after assigning something to the flipped thing on a NumPy array.

[SylvainCorlay]

This raises the question of how much we want to stick to numpy. I guess that in the context of jet or pythran, the answer is *more*. I don't have perspective on the sort of problematics you encounter in this context and how you can handle semantic differences like this.

…

On Mar 9, 2017 6:57 PM, "Wolf Vollprecht" ***@***.***> wrote: But diag is actually not a view in NumPy. To be honest I don't even know if it is a good idea to make the flips views. This might be just an artifact on how it's implemented in NumPy. I wouldn't really expect the source array to change after assigning something to the flipped thing on a NumPy array. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#161 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACSXFpSLj5RTZnA4IceYw2ZpRoPuXVgaks5rkD1sgaJpZM4MXwgB> .

[wolfv]

But thinking about it, the case of diag is really quite unclear, isn't it?

For example:

a = xarray({1,2,3});
b = diag(a);
// = {{1, 0, 0}, {0, 2, 0}, {0, 0, 3}};
b += 123;
// = {{124, 123, 123}, ...
// and now a = {{124, 125, 126}}?

Or did you mean diagonal? I agree, for diagonal it makes a lot of sense, even though NumPy doesn't seem to allow it.

[SylvainCorlay]

Yes I meant diagonal.

[wolfv]

by the way, the numpy docs mention

In some future release, it will return a read/write view and writing to the returned array will alter your original array. The returned array will have the same type as the input array.

So I guess it would be a good move to overtake NumPy on this feature! :)

[SylvainCorlay]

Good catch.

[wolfv]

This was an experiment hijacking the xindexview (and using a functor instead of a container).

However, the xindexview currently can only have a 1D shape, so the more advanced diags don't work.

    struct diag_indices
    {
        diag_indices(std::size_t sz) : m_size(sz)
        {
        }

        template <class... Args>
        xindex operator() (std::size_t idx, Args... args) {
            return xindex(idx, idx);
        }

        xindex operator[](std::size_t idx) const
        {
            return xindex({idx, idx});
        }

        std::size_t size() const {
            return m_size;
        }
    private:
        std::size_t m_size;
    };

    template <class E>
    inline auto diagview(E&& e) noexcept
    {
        using view_type = xindexview<xclosure_t<E>, diag_indices>;
        auto sz = e.shape()[1];
        return view_type(std::forward<E>(e), diag_indices(sz));
    }

[wolfv]

Maybe the proposed functor view could also be used for diagonal?