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

Add Quantization effect #308

Merged
merged 3 commits into from
Dec 13, 2023
Merged

Add Quantization effect #308

merged 3 commits into from
Dec 13, 2023

Conversation

teutoburg
Copy link
Contributor

@teutoburg teutoburg commented Dec 13, 2023

Add a new effect electronic.Quantization, which does the "flooring" previously performed within ShotNoise and also sets the data type to unsigned integer (32 bit) by default. This can be changed by passing the dtype keyword argument to any dtype accepted by Numpy. A warning will be logged if the selected data type is not an integer, since usually the outcome of flooring should be some kind of integer.

Warning

As this takes the flooring out of ShotNoise, it will probably (slightly) change (increase) any previous output unless the new Quantization effect is added in the corresponding IRDB YAML file.

@teutoburg teutoburg self-assigned this Dec 13, 2023
@teutoburg teutoburg added enhancement New feature or request tests Related to unit or integration tests effects Related to a ScopeSim effect labels Dec 13, 2023
Copy link

codecov bot commented Dec 13, 2023

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (0510a49) 80.28% compared to head (c400805) 80.34%.

Files Patch % Lines
scopesim/effects/electronic.py 92.85% 1 Missing ⚠️
Additional details and impacted files
@@              Coverage Diff               @@
##           dev_master     #308      +/-   ##
==============================================
+ Coverage       80.28%   80.34%   +0.06%     
==============================================
  Files             147      148       +1     
  Lines           14844    14898      +54     
==============================================
+ Hits            11917    11970      +53     
- Misses           2927     2928       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@teutoburg teutoburg changed the title Fh/quant Add Quantization effect Dec 13, 2023
@teutoburg teutoburg marked this pull request as ready for review December 13, 2023 14:36
@teutoburg teutoburg requested a review from hugobuddel December 13, 2023 14:36
@teutoburg teutoburg merged commit 1759dae into dev_master Dec 13, 2023
22 checks passed
@teutoburg teutoburg deleted the fh/quant branch December 13, 2023 23:10
@hugobuddel
Copy link
Collaborator

Awesome! Can't wait to add these to the IRDB.

Specifying a signed dtype will 'wrap around' on overflow to negative values. Having a positive flux value be converted to negative values is probably never what the end users wants, as no detector works this way:

my_data = np.array([3.8, 8.1, 130000.2])

np.floor(my_data).astype("uint16")
# Works fine, overflow capped to maximum value:
# array([    3,     8, 64464], dtype=uint16)

np.floor(my_data).astype("int16")
# Works against users intentions, overflow wraps around to negative values:
# array([    3,     8, -1072], dtype=int16)

Note that the non-linearity effect should have already replaced values that are larger than what the detector can measure with the maximum value (that is, the saturation value). However, the non-linearity effect is not always turned on.

The simplest change would be to simply disallow using signed integer types completely.

Another option would be to explicitly replace values with the maximum and minimum, e.g.

real_dtype = np.dtype(new_dtype)
max_value = np.iinfo(real_dtype).max
min_value = np.iinfo(real_dtype).min
np.clip(obj._hdu.data, min_value, max_value, out=obj._hdu.data)

The default is uint32, so by default things will work fine, so perhaps this issue is not that important.

@teutoburg
Copy link
Contributor Author

Thanks for considering these edge-cases! Maybe for now it would be fine to log a warning when a signed integer type is used?

@hugobuddel
Copy link
Collaborator

A warning would be good as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effects Related to a ScopeSim effect enhancement New feature or request tests Related to unit or integration tests
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants