Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#218 Make everything picklable #655

Merged
merged 119 commits into from
Apr 17, 2015
Merged

#218 Make everything picklable #655

merged 119 commits into from
Apr 17, 2015

Conversation

rmjarvis
Copy link
Member

This is a really old issue that's been kind of irksome that we haven't gotten around to yet. So a few weeks ago, I decided to tackle it. I'm not actually 100% done yet, but it's close enough that I think it's worth having people take a look.

Almost all of our classes now have the following features:

  • Picklable. i.e. cPickle.loads(cPickle.dumps(obj)) gets you back an exact copy of the original
  • Copyable. i.e. copy.copy(obj) makes a copy of the object. Anything with an rng attribute won't be identical, since the RNG is just copied, not duplicated.
  • Deep copyable. i.e. copy.deepcopy(obj) makes an exact copy of the original. Things with an rng attribute are identical in this case.
  • Repr-able. i.e. eval(repr(obj)) makes an exact copy of the original. The usual recommendation for repr is that it be "unambiguous". A common way to make sure of that is to have the repr string be eval-able, at least in some context (e.g. after import galsim). However, in our case, this means the repr string in some cases is rather long, so I'm quite willing to reconsider whether this is a feature we really want.
  • String-able. i.e. str(obj) returns a reasonable looking string that describes the object.

Probably most people won't want to read through the code changes I made to make all this work, but I would encourage people to play around with printing str(obj) and repr(obj) to see how things look.

TallJimbo and others added 30 commits July 19, 2012 15:45
Conflicts:
	galsim/__init__.py
	galsim/image.py
	include/galsim/Random.h
	pysrc/Image.cpp
	pysrc/Random.cpp
… BaseNoise not construcable. (Too hard to pickle.)

(#218)
Conflicts:
	galsim/correlatednoise.py
Conflicts:
	galsim/correlatednoise.py
	galsim/interpolatedimage.py
	galsim/noise.py
	pysrc/Noise.cpp
	pysrc/Random.cpp
	pysrc/SBProfile.cpp
	tests/test_correlatednoise.py
self.original = obj
self._jac = jac
self._off = offset
self._frat = flux_ratio
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to call this self._flux_ratio? While skimming the code I didn't notice this line and only saw _frat later on, and wondered what it was (seems non-obvious to me).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just brevity. For private (implementation-detail) attributes, I don't feel as obliged to be verbose. But I can change it.

@@ -42,7 +42,15 @@ def __init__(self, omega_m=0.3, omega_lam=0.7):
self.omega_lam = omega_lam
self.omega_c = (1. - omega_m - omega_lam)
#self.omega_r = 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has nothing to do with this PR, but if we are ignoring radiation in most of the code, is there any reason to keep the two commented-out lines that involve omega_r?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume they were put in as a starter implementation in case we eventually wanted to enable radiation. I don't think it hurts to leave them here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are other places that would also have to change, but don't have comments. So it seemed a bit inconsistent to me. But I guess it doesn't matter, we can cross that bridge when/if we come to it. :)

@rmandelb
Copy link
Member

A random thought that occurred to me as I was going through this (not done yet):
It would be nice to show the use of __str__ and __eq__ for some of the objects for which this functionality is newly enabled in a demo or two.

return self._g.imag * self._g2e(abs(self._g)**2)

def getE(self):
"""Return the magnitude of the distortion |e1 + i e2| = sqrt(e1**2 + e2**2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to go back and forth in these docstrings between i and j for sqrt(-1). Should probably choose just one and stick with it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the reason is that for getShear() I thought it made more sense to use the python version of i, which is j. So I wanted to point out that getShear() was g1 + 1j * g2, which is how you would build the complex object in python. Then that idea carried over into some others like getG and getBeta.

But for these, it's probably better to just use i (like I did here), since they are all just describing the math, not python, and i is the more normal thing to use for that.

@rmandelb
Copy link
Member

So if we are being serious about having immutable types, then it should really return a different object.

OK.

@rmjarvis
Copy link
Member Author

A random thought that occurred to me as I was going through this (not done yet):
It would be nice to show the use of str and eq for some of the objects for which this functionality is newly enabled in a demo or two.

I couldn't think of any place to use __eq__, but demo7 seems like a good place to use the str functionality. See what you think about my latest commit: 9248b0d.

@rmandelb
Copy link
Member

See what you think about my latest commit:

Looks good to me.

Also, in case it wasn't clear, I did finish going over the diff yesterday and am happy for this to be merged once you're done with my comments (which I think may be the case already, based on the commits above that I glanced through).

@rmjarvis
Copy link
Member Author

Great. I did address all the other comments you had yesterday. Thanks for those!

I'll plan on merging tonight, and then do #644 on master. Then we can work on releasing v1.3.

@rmandelb
Copy link
Member

Sounds good to me.

rmjarvis added a commit that referenced this pull request Apr 17, 2015
@rmjarvis rmjarvis merged commit 7315168 into master Apr 17, 2015
@rmjarvis rmjarvis deleted the #218 branch April 17, 2015 23:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants