Split GreaterThan constraint into Inequality and ScalarInequality

[amontanez24]

Problem Description

As a user, it is sometimes confusing to use the GreaterThan constraint because the parameters can take many different types of values.

For example, low and high can be either a column name, a scalar, or a list of column names. If it is a list, then it isn't clear what the behavior is. If both high and low are lists, then the values are compared by their indices (ie. the first value of low must be less than the first value of high, the second value of low must be less than the second value of high, etc.). If only one is a list, then each value in the list is compared to the other value. If they are both lists and the lengths don't match, there will be an error.

To remove all of this confusion, we propose splitting the GreaterThan constraint into two different constraints: Inequality and ScalarInequality. The first will compare two columns and the second will compare a column to a scalar. There will no longer be support for lists of columns.

Expected behavior

• Remove GreaterThan constraint class
• Add Inequality class
  • Init params should be:
    • low_column_name: String that is the name of the lower column
    • high_column_name: String that is the name of the higher column
    • strict_boundaries: Boolean on whether or not to be inclusive with the inequality
  • Logical changes
    • Since there is no longer a drop parameter, we should just pick one of the columns to drop and one to use
• Add ScalarInequality class
  • Init params should be:
    • column_name: String that is the name of the column to compare
    • value: Scalar value to compare to
    • relation: String that is either '>', '>=', '<', '<='

[amontanez24]

@kveerama Is there ever a case where we would not want to drop either column?

[fealho]

@npatki Any reason the Inequality class doesn't have the relation parameter instead of strict_boundaries? So Inequality would have the following parameters: column_name1, column_name2, relation.

I think it would be slightly more consistent, although I don't think it matters too much either way.

[kveerama]

@kveerama Is there ever a case where we would not want to drop either column?

@kveerama ia still thinking ): @amontanez24