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
| Rank | Ranked higher |
| Link | This issue relates to DM-796 [ DM-796 ] |
| Link | This issue is duplicated by DM-434 [ DM-434 ] |
| Rank | Ranked lower |
| Rank | Ranked higher |
| Labels | Measurement | AppsPlanning Measurement |
| Story Points | 4 | 2 |
| Team | UW [ 10300 ] | |
| 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, but I'll call it "BoundedField" for now. Ultimately, I'd like to go further and remove the Approximate and Interpolate classes in their current form; I think it makes more sense from a design perspective to have those be different factories for producing BoundedField instances. But that will not be a part of the work on this ticket, and I'll evaluate that proposal again after I see how this ticket goes. The immediate use case for this work is to store aperture corrections, which is why this has been filed with a "Measurement" label. I'm just using the Approximate class in HSC-side prototype of this code, but it's proving to be a bit messy, and I'd like to clean that up before implementing a longer-lived design on the LSST side. |
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 code on the HSC fork that is relevant to this ticket is here: https://github.com/HyperSuprime-Cam/afw/blob/master/include/lsst/afw/math/BoundedField.h https://github.com/HyperSuprime-Cam/afw/blob/master/src/math/BoundedField.cc https://github.com/HyperSuprime-Cam/afw/blob/master/python/lsst/afw/math/BoundedField.i |
| Summary | Unify Approximate and Interpolate interfaces | Abstract base class for approximated or interpolated fields |
| 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 code on the HSC fork that is relevant to this ticket is here: https://github.com/HyperSuprime-Cam/afw/blob/master/include/lsst/afw/math/BoundedField.h https://github.com/HyperSuprime-Cam/afw/blob/master/src/math/BoundedField.cc https://github.com/HyperSuprime-Cam/afw/blob/master/python/lsst/afw/math/BoundedField.i |
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 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 |
| Labels | AppsPlanning Measurement | SciencePipelines |
| Assignee | Jim Bosch [ jbosch ] |
| Story Points | 2 | 10 |
| Summary | Abstract base class for approximated or interpolated fields | Implement abstract base class for approximated or interpolated fields |
| Rank | Ranked lower |
| Assignee | Yusra AlSayyad [ yusra ] |
| Sprint | Science Pipelines DM-S15-2 [ 151 ] |
| Rank | Ranked higher |
| Remote Link | This issue links to "Page (Confluence)" [ 12518 ] |
| Sprint | Science Pipelines DM-S15-2 [ 151 ] | Science Pipelines DM-S15-3 [ 155 ] |
| Rank | Ranked lower |
| Sprint | Science Pipelines DM-S15-3 [ 155 ] |
| Rank | Ranked higher |
| Sprint | Science Pipelines DM-S15-4 [ 159 ] |
| Rank | Ranked lower |
| Labels | SciencePipelines | HSC SciencePipelines |
| Sprint | Science Pipelines DM-S15-4 [ 159 ] | Science Pipelines DM-S15-4, Science Pipelines DM-S15-5 [ 159, 162 ] |
| Rank | Ranked higher |
| Sprint | Science Pipelines DM-S15-4, Science Pipelines DM-S15-5 [ 159, 162 ] | Science Pipelines DM-S15-4, Science Pipelines DM-S15-5, Science Pipelines DM-S15-6 [ 159, 162, 165 ] |
| Rank | Ranked higher |
| Sprint | Science Pipelines DM-S15-4, Science Pipelines DM-S15-5, Science Pipelines DM-S15-6 [ 159, 162, 165 ] | Science Pipelines DM-S15-4, Science Pipelines DM-S15-5 [ 159, 162 ] |
| Rank | Ranked lower |
| Labels | HSC SciencePipelines | SciencePipelines |
| Remote Link | This issue links to "Page (Confluence)" [ 24519 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 24716 ] |
| Resolution | Done [ 10000 ] | |
| Status | To Do [ 10001 ] | Invalid [ 11005 ] |