Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:None
Description
The current names of the "flux" fields in the base_Blendedness measurement algorithm are causing mild headaches due to somewhat unconventional/misleading naming. We currently have:
name="base_Blendedness_raw_instFlux", doc="measure of how instFlux is affected by neighbors: (1 - instFlux.child/instFlux.parent)"
|
name="base_Blendedness_raw_instFlux_child", doc="instFlux of the child, measured with a Gaussian weight matched to the child", units="count"
|
name="base_Blendedness_raw_instFlux_parent", doc="instFlux of the parent, measured with a Gaussian weight matched to the child", units="count"
|
name="base_Blendedness_abs_instFlux", doc="measure of how instFlux is affected by neighbors: (1 - instFlux.child/instFlux.parent)"
|
name="base_Blendedness_abs_instFlux_child", doc="instFlux of the child, measured with a Gaussian weight matched to the child", units="count"
|
name="base_Blendedness_abs_instFlux_parent", doc="instFlux of the parent, measured with a Gaussian weight matched to the child", units="count"
|
First the base_Blendedness_raw_instFlux and base_Blendedness_abs_instFlux are not actually fluxes, so this breaks attempts to identify flux keys based on a search on “*_instFlux”. I also note that all raw vs abs entries have exactly the same doc strings, so it’s not obvious what the difference between them is. Second, for the fields that are fluxes, their names don’t end with _instFlux, but rather _parent or _child. This is a minor annoyance since all (or at least most) of the other flux fields in our schemas have names that end with _instFlux.
Thus, the specific proposal for this RFC is to:
- strip "_instFlux" from the base_Blendedness_raw_instFlux and base_Blendedness_abs_instFlux names (Jim Bosch points out that those fields are often referred to as just "blendedness" outside of this context, so this would "feel" natural to most users in that regard)
- move "_instFlux" to the end of the name in the fields with actual flux units, thus
- base_Blendedness_raw_instFlux_child --> base_Blendedness_raw_child_instFlux
- base_Blendedness_raw_instFlux_parent --> base_Blendedness_raw_parent_instFlux
- base_Blendedness_abs_instFlux_child --> base_Blendedness_abs_child_instFlux
- base_Blendedness_abs_instFlux_parent --> base_Blendedness_abs_parent_instFlux
Finally, I would also suggest an update to the doc strings to make a clear distinction/description between "raw" and "abs".
Attachments
Issue Links
- is triggering
-
- Done
Activity
+1. I think just "base_Blendedness_raw" and "base_Blendedness_abs" are fine; if we wanted to do more than that, the best approach would probably to go a bit further by inverting these (subtracting them from one) and making the suffix "_purity"; that's the other word that's already in use for [something like] this quantity. (I'm not suggesting that we do that here, but I'm also not opposed if others like the idea).
I'm going to adopt this as written. Adding a term like "fraction" I think would require also removing the "ness" of blendedness (as the "ness" is really meant to imply that), so I think it's best just to maintain/use the currently accepted concept. Also, while I'm not opposed to the "purity" concept, I think this would cause too much disruption for current users of these fields.
+1 Yes, please clean this up!
The only addition I could make to this would be to suffix the "blendedness" fields with something more identifiable than raw and abs: maybe base_Blendedness_raw_fraction?