Cache bug ylimit (fix: deepcopy instead of shallow copy)

[dtnguyen2]

Release Note

The function cache_model makes shallow copy of the cached function values, this PR added a couple of ```.copy()`` to make sure deep copies are made instead. This PR is a fix to issue #673

Note

In re-reading the code I also noticed that the setting of the _use_caching member of the class ArithmeticModel was not set consistently in the member function __set_state__

[dtnguyen2]

Not sure why there are five file changes in this PR. The only expected changes should be in file: sherpa/models/model.py

[dtnguyen2]

perhaps the following code

    def teardown(self):
        self._use_caching = False

in the file models/model.py should be changed to:

   def teardown(self):
       self._use_caching = True

also

[DougBurke]

I would like the commit history to be cleared up before I review this.

I think either rebasing onto a clean, up to date master branch or cherry-picking the commit onto a clean, up to date, master branch should work.

[DougBurke]

perhaps the following code

    def teardown(self):
        self._use_caching = False

in the file models/model.py should be changed to:

   def teardown(self):
       self._use_caching = True

also

I personally don't have a good feel for how the cache code and the setup/teardown methods are meant to interact. Previously I think the cache was only used for models with no free parameters, and then only within the context of a "setup/teardown" call - e.g. as done by a fit call. This is presumably why there is a unilateral "turn off cacheing" in the teardown method, in case it had been turned on by the setup method.

We've now changed things so that cacheing is expected to be on, so turning it off in teardown isn't very useful. However, I am not convinced that always turning it on is a great idea either. My current feeling would be that the teardown method shouldn't change the _use_caching attribute. In that case we may also want to remove the "turn on caching if there are no free parameters" logic in the setup method as well (since we expect the cache support to already be on), but I think this is getting to the point that we should be reviewing the cache code.

[DougBurke]

Can the history be cleaned up before this gets merged?

[wmclaugh]

@dtnguyen2 - Can you please rebase this so that it only touches the expected file (models.py) instead of 5 files?

[DougBurke]

The code and test look fine. I thought you were going to clean up the history before I was to sign off?

[dtnguyen2]

It was easier to clean up by issuing a new PR #705, so will close this PR