Solr
  1. Solr
  2. SOLR-966

Enhance the map() function to take in a default value

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.4
    • Component/s: None
    • Labels:
      None

      Description

      The map function currently takes in only one min,max target and returns the field's value if it is not between min and max. This makes it very difficult to use it for scoring.

      This issue aims to add an optional fifth parameter to the map function query which will be a default value that is used if the field's value does not fall between min and max. If this parameter is not specified, the behavior is the same as before for back-compatibility.

      1. SOLR-966.patch
        3 kB
        Shalin Shekhar Mangar
      2. SOLR-966.patch
        2 kB
        Noble Paul

        Activity

        Hide
        Shalin Shekhar Mangar added a comment -

        I guess the problem (feature?) of map is that if the field value is not between min and max, it outputs the value of the field. That makes it difficult to use map for scoring on numeric field values.

        An alternative to Noble's approach can be to add an optional fifth argument for a default value. If value does not fall between min and max, map can output the default value. However, both these approaches are mutually exclusive.

        Thoughts?

        Show
        Shalin Shekhar Mangar added a comment - I guess the problem (feature?) of map is that if the field value is not between min and max, it outputs the value of the field. That makes it difficult to use map for scoring on numeric field values. An alternative to Noble's approach can be to add an optional fifth argument for a default value. If value does not fall between min and max, map can output the default value. However, both these approaches are mutually exclusive. Thoughts?
        Hide
        Ryan McKinley added a comment -

        For context, what class/component are you looking at?

        What use case are you trying to solve?

        Show
        Ryan McKinley added a comment - For context, what class/component are you looking at? What use case are you trying to solve?
        Hide
        Shalin Shekhar Mangar added a comment -

        I'm using the map function (FunctionQuery).

        Consider the following (hypothetical) use-case:
        I want to boost up listings of a certain category over listings of another category. Say for example, "SUV" and "Sedan". For each category, I've indexed a integer field, say "SUV" = 1 and "Sedan" = 2. Now I'm trying to boost SUVs over Sedans through function queries. This is just one of the many different boosts I need to apply.

        So I use q=val:map(category, 1, 1, 3) val:map(category, 2, 2, 1). The priorities of the categories are not fixed i.e. they change at runtime. I cannot use a sort because of the many different boosting criteria I have. I cannot use the normal boosts because I don't want TF/IDF influencing the scores.

        I hope the description makes sense.

        Show
        Shalin Shekhar Mangar added a comment - I'm using the map function (FunctionQuery). Consider the following (hypothetical) use-case: I want to boost up listings of a certain category over listings of another category. Say for example, "SUV" and "Sedan". For each category, I've indexed a integer field, say "SUV" = 1 and "Sedan" = 2. Now I'm trying to boost SUVs over Sedans through function queries. This is just one of the many different boosts I need to apply. So I use q= val :map(category, 1, 1, 3) val :map(category, 2, 2, 1). The priorities of the categories are not fixed i.e. they change at runtime. I cannot use a sort because of the many different boosting criteria I have. I cannot use the normal boosts because I don't want TF/IDF influencing the scores. I hope the description makes sense.
        Hide
        Noble Paul added a comment -

        However, both these approaches are mutually exclusive.

        It is still possible to have both these working together.

        For the no:of arguments 'n' if (n%3) == 0 then no default is used. if ((n%3)-1) =0 , then the last value can be used as default. Although it is more complex (to explain) it hopefully will meet most of the requirements of a switch - case - default

        Thoughts?

        Show
        Noble Paul added a comment - However, both these approaches are mutually exclusive. It is still possible to have both these working together. For the no:of arguments 'n' if (n%3) == 0 then no default is used. if ((n%3)-1) =0 , then the last value can be used as default. Although it is more complex (to explain) it hopefully will meet most of the requirements of a switch - case - default Thoughts?
        Hide
        Noble Paul added a comment -

        decided to go w/ shalin's suggestion . added just a default value. The last value is optional. if not present ,the field value is used as default.

        Show
        Noble Paul added a comment - decided to go w/ shalin's suggestion . added just a default value. The last value is optional. if not present ,the field value is used as default.
        Hide
        Shalin Shekhar Mangar added a comment -

        Changed equals and hashcode method to take the default value into consideration.

        I found a bug in the hashcode function:

        Float.floatToIntBits(min);

        which should have been

        h += Float.floatToIntBits(min);

        Since my knowledge of hashing is limited, it would be nice if someone can review this.

        Show
        Shalin Shekhar Mangar added a comment - Changed equals and hashcode method to take the default value into consideration. I found a bug in the hashcode function: Float .floatToIntBits(min); which should have been h += Float .floatToIntBits(min); Since my knowledge of hashing is limited, it would be nice if someone can review this.
        Hide
        Shalin Shekhar Mangar added a comment -

        Committed revision 740445.

        Thanks Noble!

        Show
        Shalin Shekhar Mangar added a comment - Committed revision 740445. Thanks Noble!
        Hide
        Grant Ingersoll added a comment -

        Bulk close Solr 1.4 issues

        Show
        Grant Ingersoll added a comment - Bulk close Solr 1.4 issues

          People

          • Assignee:
            Shalin Shekhar Mangar
            Reporter:
            Noble Paul
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development