The FLOAT datatype isn't based on the DECIMAL numbering system although the result is displayed as such. FLOAT is based on BINARY representations of DECIMAL numbers and, when you do things such as division, BINARY division can raise some hell with the "accuracy" that a lot of people expect from a 4 function calculator. Most 4 function calculators to the math behind the scenes using 15 places to the right of the decimal place and only display/use up to 13 places as a result.

FLOAT "only" has 15 places of precision including all places. If you have used 4 places to the left of the decimal point, only 11 places will be used to the right of it.

FLOAT can be useful but it takes a lot of folks by surprise because of things like BINARY division and because certain decimal expectations can't be accurately represented by BINARY fractions. It also doesn't help that MS tried to satisfy folks complaints about FLOAT by sometimes changing the display of the numbers rather than displaying the actual "imprecise" number.

When I need to be as accurate as possible for DIVISION and similar "decimal place intensive" calculations, I'll generally just use DECIMAL(38,xx) where 38-xx represents the largest number of digits to the left of the decimal point that I expect. For values within the range of the INTEGER datatype, I'll use DECIMAL(38,28), which leaves 10 digits to the left of the decimal point.

Also, since the DIVISOR in the given problem is the same for both sides of the subtraction, why not simplify the formula to (@PROMOTER-@DETRACTOR)/@COUNT?