eval method about xtensor HOT 8 CLOSED

Do you see a practical usecase for this? Would this be to create a temporary?

from xtensor.

well one practical use case was (or is) the BLAS linalg backend implementation as it needs contiguous memory blocks as input.

Also, it might be nice to write auto mat = xt::eval(xt::random::rand({3, 3}) + 5); and know that you'll get a "fixed" expression.
Or in other cases you might know that you need to access some values of some xexpression often, and you want to put the values into memory instead of recalculating them every time (use in a loop or whatever). Then just calling eval would do it, without having to think about xtensor vs xarray and the corresponding types.

I consider it more a goodie, not a necessity.

from xtensor.

OK, in a past work, we have a similar functionality called temporary which was returning an instance of the associated temporary_type.

from xtensor.

I don't see johan's comment anymore but what I recall is that he agreed to expand the temporary type mechanism to all expressions.

from xtensor.

The comment is in the PR #143.

from xtensor.

So the idea is to add temporary_type to all xexpressions? And then the eval method could use that information, and if necessary evaluate to the temporary_type? Or would you always return a copy after eval? The current mechanism returns a reference to the argument if the argument is an already evaluated 'xarray' or 'xtensor'.

from xtensor.

Actually I think eval and temporary are distinct functionalities:

• eval ensures the expression has been evaluated and further access to an element won't trigger a computation. You want to guarantee maximal performance, so calling eval on an xarray or an xtensor should return a reference to itself. You're not supposed to modify the evaluated container.
• temporary ensure you get the expression evaluated inside a temporary, that may be modified after the evaluation. So calling temporary on a xarray or xtensor MUST return a copy, not a reference.

@wolfv I think the eval function could leverage on the temporary_type while keeping the current mechanism (that is, evaluate to a temporary if the expression is not an xarray or an xtensor, return a reference otherwise). And you could add a temporary function that always returns a new instance of temporary_type.

from xtensor.

Implemented in #143.

from xtensor.