-
Notifications
You must be signed in to change notification settings - Fork 70
feat: add argument seed to topaz normalize #234
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
base: master
Are you sure you want to change the base?
Conversation
|
I removed the |
|
hi @tbepler thanks for the response! From my limited testing I do see the results are repeatable with multiprocessing, if the seed argument is given (np.random.RandomState should always return the same pseudo number generator no matter when and where in theory). heres a sample test code. I do notice for at least some mrcs using gpu will yield different results vs cpu, not sure if this variation also applies to different computers (perhaps that's what you meant?); but using the same computer/device the results are the same. |
|
@swan343 my main concern is actually about consistency between runs with different numbers of workers or no workers. With the same number of workers, the results should be the same, because each process's random number generator is independently seeded with the seed. However, if you change the number of workers the results will change, because, e.g. starting 2 workers and running them in parallel from the same state is not the same as running 1 worker through all the images from that same starting state. This is a pretty minor replicability issue, but would cause inconsistency between runs even when the seed is set which would be unexpected. |
|
@tbepler thanks for the reply, by workers are you referring to |
|
Ah, I see. You want to reset the random number generator to the same seed for every image. This means every image will start from the same random initialization. Is that what you want? Do you really need to set the random seed for this function? How much variability are you seeing in the results? I would expect there to be a little bit, but not major qualitative differences. If there are, setting the seed will lock that one solution but I'm not sure it addresses the core problem then, which is that the solution is unstable. I think this is fine, though. I put a few comments on your PR. We can merge it after those are fixed. |
|
yes that's exactly the intent. The variability isn't a lot per se - I do particle masking and can see about 2%-5% of difference depending on the detection technique and validation criteria. With a fixed seed the variation is eliminated completely. Appreciate the feedback! |
Hi!
I noticed here mentions the seed argument, which was present in v0.1.0, is no longer present in the latest version. This PR adds the seed arg back. With a specified non zero seed, I can now get the exact same output after multiple preprocess/normalize runs. Without it the outputs are not equivalent.