05 comparison methods

© 2019 - State of Utah - Department of Technology Services
Jump to navigation Jump to search

Comparison Methods

Once you have established which field you want to test, you must define what kind of test to perform against it. The basic tests that can be performed are: comparing against a constant, comparing to a value list (a series of one-byte constants), comparing within a range, comparing outside a range, comparing to another field, or a field comparison with an “add-on”. Some comparisons need to use an ‘equal or not-equal’ comparison code, while some must have a less-than-or-greater-than type of comparison, and others can have any type of comparison code. Each type of testing is described below:

  • Compare to a Constant - This type of comparison is the simplest, and the most universal. It can use any comparison code (=, <>, >, <=, etc.). A constant is also the only means of comparison when the contains (CT / () ) comparison code is used. The only requirement here is that the constant be of the same type as the field you are testing (i.e., it doesn’t work to see if a tax rate is equal to “Tom” or that the EIN is less than “425 Spruce Street”). Examples of a constant comparison can be “AME-C > 200”, “MSA = Q0001”, or “PHN7 NE 5551212”.


  • Compare to a Value List - This feature is only valid for use with fields that use a single character (such as the MEEI, type-of-coverage, edit flag, employment or wage indicators, status code or mailing indicator). This type of comparison cannot use a greater-than or less-than comparison code, only equal or not-equal. The values are listed in the comparison field, separated by commas. If the comparison code is “=” (or “EQ”), then the employer will be eligible for selection when the field has any one of the values in the list. When the comparison code is “<>” (or “NE”), the establishment is eligible only when the field is not equal to any of the values in the list. For example, if we wanted to find out whether the total wages had been machine estimated or had an estimation failure, we could check the total-wage indicator field for any of the machine-generated codes (i.e., “TOTW C = E,N,P,S”). If we wanted to find corporations and partnerships, we could test the organization type code with “ORG = C,P”. On the other hand, if we needed to find employers with an unusual type of coverage, we could use a statement like “TCOV 2 NE 0,1,8,9”. This will identify any employer that is not listed as standard experience-rated, reimbursable, Federal, or non-covered.


  • Comparing Within a Range - Range checking can be employed with any type of field, but it is most often used with numeric fields, such as employment, wages, tax rates, etc. A range uses both the comparison and the ending portion of the parameter line to identify the two endpoints of the range. The equal (‘=’ or ‘EQ’) comparison code is used to look for establishments that are within the range. As an example, to search for an employer with an EIN starting with ‘61’, ‘62’, or ‘63’, you could enter “EIN = 61 63”. The range is an inclusive bounding, which means that the end points are included as “in the range”. In this example, any EIN from 610000000 to 639999999 is valid. If you use a text-type field, such as finding a trade name beginning with G – K, the entry would be “TRADE = G K”. Note that in both cases, you only need to specify the number of characters (or leading digits) as are necessary to define the range. Even though the EIN field is numeric, it is not used for computation, etc. Therefore, it is treated as though it were a text field for comparisons. Locating a current-quarter average quarterly wage value between $7500 and $9000 would be shown as “AQW C = 7500 9000”, since fields used in computations are compared in a right-justified manner (i.e, you don’t want to look for AQW between ‘00000007’ and ‘00000009’ to look for the text equivalent of the 11-digit number).


  • Comparing Outside a Range - This works the same way as the within-a-range comparison, except that the comparison code must be not-equal (‘<>’ or ‘NE’). Everything below the minimum or above the maximum will be eligible for selection. For instance, if you look for exceptionally high or low tax rates, you could have a parameter that looks for anything below 0.5% or above 9.4% via the command: “TAXRT C NE 0.5 9.4”. Since the in-range check is inclusive, the out-range check is exclusive. In this example, establishments with tax rates of 0.499% or lower would be eligible, along with those with tax rates of 9.401% and higher.


  • Comparing Field to Field - The field-to-field comparison method is pivotal to the 040D job run. The only requirement is that similar types of fields be compared (i.e., don’t compare a date to an address, or a tax rate to a total wage figure). You can compare for equal, not equal, greater-than, less-than, etc., between the two fields. Although field comparisons are most often used with numeric data, they can be used with text fields as well. Text comparisons will measure where the two fields fall alphabetically relative to each other.


Caution: Text data are stored in EBCDIC (Extended Binary Coding Decimal Interchange Code) format, which is significantly different than ASCII (American Standard Coding for Information Interchange) sequence.  Alphabetic characters appear before numeric characters in EBCDIC, but the reverse is true for ASCII; so “ABC” < “AB3” for EBCDIC, while “ABC” > “AB3” for ASCII.


Date comparisons use chronological comparisons (2016/12/31 < 2017/01/01, even though the latter month and day-of-month sub-fields are smaller than the first date’s values). Numeric fields can be compared without regard to their field lengths; for example, an employment field could be compared against total wages or an AQW value. Most of these checks, however, are of little value (e.g., “MON1 C LE TOTW-C” will be true for almost all establishments, unless all employment and wage data are zeroes).


The screen will reformat a comparison field ID when it is entered. The field ID will be shifted over to the right-hand edge of the field. If it is a quarter-specific field, the quarter index will be listed after a separating hyphen (e.g., “TAXWI-3” would represent the prior-quarter taxable wage indicator). Some of these can look somewhat confusing as well, such as “MIN-E-4”, which carries its own hyphen within the field ID, so it is necessary to distinguish the “MIN-E” (minimum employment) portion from the “-4” portion (for quarter #4 – fourth occurrence of the quarterly table).


  • Comparing Fields with an Offset - This is the “by” comparison, which often comes in handy. The add on can be thought of as a plus sign (“+”) inserted after the compared-to field ID. For a less-than comparison, it would be a minus sign (“-”) instead. As an example, if you were to see “AME C > AME P by 50”, it is the same as writing “AMEC > (AMEP + 50)”. To satisfy the condition, the current quarter Average Monthly Employment (AME) can’t just be higher than the previous quarter’s AME, but it has to be more than 50 employees higher. This is also useful for wage comparisons; if you wanted to find employers that had lost over $1,000,000 in wages since the same quarter of last year, you could type in “TOTW 2 < TOTW-6 1000000”, which says the same thing as “TOTWC < (TOTWY - $1,000,000)” (where the “Y” subscript represents last year’s current quarter). When the line is redisplayed by the program, the word “by” is inserted just before the offset value (e.g., “TOTW 2 < TOTW-6 by $1,000,000”).


Note: A greater-than or less-than type of comparison (‘>’, ‘>=’, ‘<’, ‘<=’, ‘GT’, ‘GE’, ‘LT’, ‘LE’) needs to be used when an offset is included (it makes no sense to see if employment, for instance, has gone up by exactly 27 between two quarters).


  • Comparing Fields with a Percentage Offset - This is the same as the “absolute” offset that was just described, except that it uses a percentage value for how much the two fields need to differ. A sample problem might be to look for accounts with employment variation of more than 75% through the quarter. This could be checked with an equation such as “MAX-E C GE MIN-E C 75%”. While the absolute offset can be thought of as an add-or-subtract function, the percentage can be thought of as though it were a multiplication. The example is equivalent to “MAX-EC ≥ (MIN-EC x (100% + 75%))” (or MAX-EC ≥ MIN-EC x 1.75).


You can still think of a less-than comparison as a multiplication, but the multiplied percentage is subtracted from 100%. For instance, if you sought AQW values that had dropped by more than 60% from the previous quarter, you could specify the equation- “AQW C < AQW-3 60%”, which says “AQWC < (AQWP x (100% – 60%))”; but the (100% - 60%) can be replaced by 40%, so the comparison can be stated more simply as “AQWC < AQWP x 0.4”.


Warning: You cannot specify a percentage of 100 or higher for a less-than comparison; it makes no sense to say “this company’s employment dropped by 150% last quarter,” since that would mean they would go from, say 10 employees to –5 employees (i.e., they have five “anti-employees”).


All of these methods of parameter entry are used in sample problems that appear in the following pages. Even though some of the methods may seem unclear or even weird, the process should become much clearer as you experiment with your own parameter entry.


Related Links