-
Notifications
You must be signed in to change notification settings - Fork 22
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
Optimize find bins fix issue 993 #1000
Conversation
Note that tests are failing due to some updates of numba and/or numpy in the github actions server (and are unrelated to the changes here) |
I think it's #1001. I'll have a look through all positions where this happens and will open another PR |
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.
looks good overall, see comments regarding definition of restframe grid. Will still need to work on fixing version issues, see #1002
w1 &= log_lambda >= log_lambda_grid[0] - half_pixel_step | ||
w1 &= log_lambda < log_lambda_grid[-1] + half_pixel_step | ||
w1 &= (log_lambda - np.log10(1. + z) >= | ||
log_lambda_rest_frame_grid[0] - half_pixel_step_rest_frame) | ||
log_lambda_rest_frame_grid[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.
Did we change the definition of the rest frame grid from pixel centers to edges or vice versa? Or was it the effect of different find_bins implementation?
Or is this part of the reason we're seeing slightly different outputs?
else: | ||
break | ||
step = grid_array[1] - grid_array[0] | ||
found_bin = ((original_array - grid_array[0]) / step + 0.5).astype(np.int64) |
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.
Wouldn't this give an array that is displaced by exactly half a pixel and then cast to int? Is this for avoiding numerical issues from the division? Why not just use (original - grid) // step
in that case?
3.01953334, 3.02453334, 3.02953334, 3.03453334, 3.03953334, | ||
3.04453334, 3.04953334, 3.05453334, 3.05953334, 3.06453334, | ||
3.06953334, 3.07453334 | ||
3.01703334, 3.02203334, 3.02703334, 3.03203334, 3.03703334, |
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 is a change by exactly 0.0025, i.e. one half pixel, did we want to change the definition? see other file
This PR fixes issue #993 and optimized function find_bins to use direct calculation. The results are different since I changed the binning of the wavelength grids in the computation of the expected flux. Thus, I updated the test suite. Below I provide a comparison of the results of this branch with those from master with a fugu run.
Timing comparison (over 3 runs):
Variance statistics comparison:
Delta stack comparison:
Quasar continuum comparison:
Fits metadata comparison:
Lya autocorrelation comparison: