Make cube.exponentiate lazy

[DPeterK]

Changes the last line in iris.analysis.maths._math_op_common to use lazy data. This means iris.analysis.maths.exponentiate (providing cube ** exponent functionality) is now lazy.

As I was in the space, I've also added some tests for iris.analysis.maths.exponentiate. These do not follow the pattern of the other test modules in the directory as we do not make use of an operator attribute for cube exponentiation.

[pelson]

You missed the crucial step here. If you checked the data, I think you will find that it isn't correct.

[DPeterK]

Review actions. I've simplified maths._math_op_common and got maths.exponentiate using biggus.power. I've also updated the tests with more coverage. Note that the masked array test is fixed by biggus #167.

[pelson]

We don't really need to use real data here. We can just use the lazy_array method to get lazy data on the cube.

[pelson]

I think this is getting there. Is there documentation which needs updating? Is there in_place docs somewhere which describe the behaviour?

[DPeterK]

Is there documentation which [sic] needs updating?

I've taken a look; there is nothing in the cube mathematics section of the userguide about performing operations inplace. In the reference guide almost all of the mathematical operators have the in_place kwarg described as follows:

    in_place:
        Whether to create a new Cube, or alter the given “cube”.

It's pretty terse, which actually means it is still correct. I could update it:

    in_place:
        Whether to create a new Cube as a copy of the given "cube" and alter its data to be
        the result of applying the mathematical operation, or alter the data of the given
        “cube” to be the result of applying the mathematical operation.

But that's increased the length of the description, which has not necessarily helped its cause.

[pelson]

But that's increased the length of the description, which has not necessarily helped its cause.

Agree, that doesn't really help. Maybe just a what's new item then.

[pp-mo]

Is there documentation which needs updating?

++ whatsnew ??

[pelson]

@pp-mo - is this lined for 1.9?

[pp-mo]

@pelson pp-mo - is this lined for 1.9?

Not unless you want to push for it.
We will have lazy basic arithmetic (+-*/) covered in the 1.9 whatsnew, though

[DPeterK]

Rebase. Wonder whether the Biggus updates between when I opened this and now will have helped move this along?

[corinnebosley]

@dkillick Is there anything that can be done with this to get it moving again? The ticket is a year old. That's a bit ridiculous. Let me know if I can do something about this or bother someone who can.

[DPeterK]

Another six months, another rebase... thanks @corinnebosley

[corinnebosley]

@dkillick Well that sucks.

[corinnebosley]

@dkillick 'The build has been terminated'.... Must be because it's Friday afternoon. Travis is probably at the pub by now.

[corinnebosley]

If the license header is the only problem, we might be ok after all.

[DPeterK]

That is far from being our only problem I suspect... Is it really complaining about the license header??

[QuLogic]

So far, but the tests didn't complete, so...

[QuLogic]

I'd say see #2229.

[DPeterK]

@QuLogic this (and #2229) may be helped by #2240. I'll restart the build to see if that's the case.

[DPeterK]

Except, of course, we can't make use of the test runner changes in #2240 until the mergeback (#2236) is, well, merged back...

[marqh]

Except, of course, we can't make use of the test runner changes in #2240 until the mergeback (#2236) is, well, merged back...

@dkillick this is now merged, so if you would be knid enough to re-rebase, that would be helpful

[DPeterK]

if you would be knid enough to re-rebase

Done (and mercifully painless!) - thanks @marqh

[marqh]

there is now an explicit text failure that needs addressing:
FAIL: test_square_root (iris.tests.test_basic_maths.TestExponentiate)

[marqh]

Hi @dkillick

please could you review the test failures and see if this PR can be brought up to speed?

If successful, please consider targeting the 1.12.x branch for 1.12 release

thank you
mark

[pelson]

This PR is probably quite out of date with the recent dask work for v2. It might be worth checking to see if we have already go exp to be lazy at this point...

[pelson]

Update: it's ambiguous as to whether it is lazy, but there is certainly scope for it to be lazy with the current implementation. https://github.com/SciTools/iris/blob/master/lib/iris/analysis/maths.py#L542 has the line:

return operator.pow(data, exponent)

Which presumably means that if data is a dask array, and it has lazy exp, then iris does lazy exp... 🎉