-
Notifications
You must be signed in to change notification settings - Fork 109
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
Conversation
Conflicts: galsim/__init__.py galsim/image.py include/galsim/Random.h pysrc/Image.cpp pysrc/Random.cpp
…ue using test-based design... :) (#218)
… 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 |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. :)
A random thought that occurred to me as I was going through this (not done yet): |
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
OK. |
…out python complex type (#218)
I couldn't think of any place to use |
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). |
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. |
Sounds good to me. |
#218 Make everything picklable
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:
cPickle.loads(cPickle.dumps(obj))
gets you back an exact copy of the originalcopy.copy(obj)
makes a copy of the object. Anything with anrng
attribute won't be identical, since the RNG is just copied, not duplicated.copy.deepcopy(obj)
makes an exact copy of the original. Things with anrng
attribute are identical in this case.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 beeval
-able, at least in some context (e.g. afterimport 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.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)
andrepr(obj)
to see how things look.