-
-
Notifications
You must be signed in to change notification settings - Fork 132
Implent NotImplemented case in Spectrum1D subtraction #988
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
Conversation
|
Thanks! I think the arithmetic handling is due for a bit of a larger overhaul to ensure good handling, but this is a good start. I do think that this would be good to apply to the other operators that try to turn the |
|
It looks like the change to Would you rather troubleshoot the failure here or just apply this change to all operations except multiplication? |
pllim
left a comment
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 that when you return NotImplemented, it will look for the operator in other, I don't grok the codebase here so just want to make sure that is really what you want, because it might return something surprising.
specutils/spectra/spectrum1d.py
Outdated
| try: | ||
| other = u.Quantity(other, unit=self.unit) | ||
| except TypeError: | ||
| return NotImplemented |
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.
Shouldn't multiplication and division only be allowed if other is unitless (like a bandpass). Otherwise, the resultant flux unit will be nonsense.
Yup, that's exactly what was wanted here, so that it will fall back to the |
If multiplication is causing errors (and given the thoughts @pllim had about multiplication and division), let's just apply this to addition and subtraction for now where we know it makes sense and isn't causing errors. The arithmetic handling in Spectrum1D is due for a refresh/improvements soon, I can think more deeply about these questions when I get a chance to work on that. |
rosteen
left a comment
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.
Test failure looks like an unrelated remote data download timeout. Thanks!
| try: | ||
| other = u.Quantity(other, unit=self.unit) | ||
| except TypeError: | ||
| return NotImplemented |
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.
You don't really need the __add__ for specreduce, right? I only found __rsub__ in specreduce.
Hello, this is an update to
Spectrum1D's subtraction operator. I'm coming from astropy/specreduce#144, where we are improving specreduce's compatibility withSpectrum1Dobjects.A feature we'd like to support is the ability to subtract a
Spectrum1Dobject by a specreduceBackgroundobject. That currently fails sinceSpectrum1D.__sub__tries to callu.Quantity()on operands that aren't of typeNDCubeand that causes aTypeErrorwithBackground.My proposal catches the error and returns
NotImplementedin order to pass the operation to the other operand's__rsub__method. If the other object lacks this operator, a generalTypeErroris raised saying that subtraction isn't supported between the two types. If there's an error in the other object's__rsub__method, only that is reported (no mention ofNotImplementedinSpectrum1D.__sub__).Is this relevant enough to mention in the documentation? We only need subtraction for specreduce, but should this behavior extend to other operators?