Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-534

Update naming of base_Blendedness fields

    XMLWordPrintable

Details

    • RFC
    • Status: Implemented
    • Resolution: Done
    • DM
    • 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:

      1. strip "_instFlux" from the base_Blendedness_raw_instFlux and base_Blendedness_abs_instFlux names (jbosch 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)
      2. 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

          Activity

            Parejkoj John Parejko added a comment -

            +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?

            Parejkoj John Parejko added a comment - +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 ?
            jbosch Jim Bosch added a comment - - edited

            +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).

            jbosch Jim Bosch added a comment - - edited +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.

            lauren Lauren MacArthur added a comment - 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.

            People

              lauren Lauren MacArthur
              lauren Lauren MacArthur
              Jim Bosch, John Parejko, John Swinbank, Lauren MacArthur, Yusra AlSayyad
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Planned End:

                Jenkins

                  No builds found.