Details
-
Type:
Story
-
Status: Invalid
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: afw
-
Labels:
-
Story Points:10
-
Epic Link:
-
Sprint:Science Pipelines DM-S15-4, Science Pipelines DM-S15-5
-
Team:Alert Production
Description
The user of an Approximate or Interpolate object doesn't care which of these they have, once the object has been constructed, and we should make these inherit from a common base class that only contains an interface for accessing the interpolated/approximated function while making no assumptions about its functional form.
The new class will represent a scalar field defined over an integer bounding box, and will have methods for evaluating the field at a point and creating an image of the field. We could also consider giving it arithmetic interoperability with Image. I don't have a strong candidate for the name; I've called it "BoundedField" on the HSC side but would like that to be revisited.
Adding derived classes to replace the functionality currently in the Approximate and Interpolate classes will be on a separate issue. The main work on this issue is tweaking the design on the HSC side and getting signoff on the final design from LSST developers; the actual coding should be minimal, as it's just an interface and we already have a good starting point for it.
The HSC-side issue (which also includes work that is part of DM-1124) is here:
https://hsc-jira.astro.princeton.edu/jira/browse/HSC-796
and the associated git commits are here:
https://github.com/HyperSuprime-Cam/afw/compare/releases/S14A_0...tickets/DM-796
Attachments
Issue Links
Activity
I think this issue has changed from being the implementation of the unifying code to proposing the unification and a process for completing it.
If I'm wrong, let me know.
That's correct; it's adding a new base class with an interface that will work for (future) Approximate and Interpolate subclasses, and adding a single derived class with a Chebyshev implementation. Now that I think about it, those should probably be two separate issues. I'm happy to do that, and change the title of this one at the same time, but I've got a couple of other things on my plate before I get back to doing planning stuff, so you're welcome to beat me to it.
Reviewing this ticket per DM-CCB request. Yusra AlSayyad, Jim Bosch — given that this has been “to do” for the better part of six years, do you think we care enough to ever actually do it?
At a high level this work is still relevant - Eli has very recently had to spend extra time working around the fact that this was never done for our background classes, and I still think we will need to deal with that someday. But given that all of the HSC ticket and code links above are broken, and I have no idea if they refer to the BoundedField ABC that did land on LSST master (we use it for aperture corrections and photometric calibrations) and is the way forward, I don't think this ticket is a useful way to capture that work.
Before (or, perhaps, as well as..) simply closing this as invalid, we should consider what it means for the other work associated with it. Are we withdrawing RFC-58 and similarly invalidating the other tickets it triggered?
Ah, sorry, I somehow missed that this was an RFC-triggered ticket. But given the dead links I still can't tell if that's an RFC we partly implemented and then abandoned, or if it was totally superseded by the work that actually landed BoundedField in afw. It seems like we did the parts that didn't actually require an RFC - adding a new class (perhaps as part of the big HSC port) - but that most of the RFC disussion actually revolved around. But we definitely didn't do the parts that would break more existing code. So I don't know what to do about the RFC.
I did take a glance at the tickets linked from the RFC, and none of them contain any actual useful information, so I think they're doing more harm than good at this point. But maybe others have different metrics for ticket value.
Given there is no work ongoing here, and no clear consensus about what needs to happen next, I propose to close the RFC as withdrawn and shut down the outstanding tickets as "won't fix". If we need to return to this in future, we can make a new plan, draw up new tickets, and file a new RFC as necessary.
Yusra AlSayyad, this was primarily your project (albeit several years ago now), so please shout if you disagree and we can reopen them/come up with a new plan.
Prototype for this unification class has been implemented on the HSC side on DM-796.