5 Replies Latest reply on Aug 14, 2018 10:14 AM by Sara Stark

# Calculations: > & < comparisons not working correctly

I have a dimension field containing a factor. I created a calculated field that essentially buckets those factors into groups. However, I'm finding that some factors aren't ending up with the correct group value assigned. Any ideas what I need to do differently?

Example: I want the factor of 0.9 to be assigned a value of "-5.1% to -10%", but it ends up with a value of "-10.1% to -15%":

Thanks!
Sara

• ###### 1. Re: Calculations: > & < comparisons not working correctly

Hi Sara

Hard to tell without seeing the other calculations involved

the sch mod factor in particular - could be a result of the aggregation or a rounding issuing in the calculation

Jim

If this posts assists in resolving the question, please mark it helpful or as the 'correct answer' if it resolves the question. This will help other users find the same answer/resolution.  Thank you.

• ###### 2. Re: Calculations: > & < comparisons not working correctly

Hi Sara,

Please Check the Number of Decimal Places..Your Value  Here Could be 0.899999999564 and not 0.9

So It will fall in That Bucket only. Just Go to Formatting and Increases Decimal Places to check it.

Thnaks

Deepak

• ###### 3. Re: Calculations: > & < comparisons not working correctly

Jim - thanks for your response. It shouldn't be an issue with an aggregation or rounding issue in the calculation. The Sch Mod Factor field just looks at two other fields and pulls a factor from them - no calc, just an IF/THEN statement. The value shown is the value as it appears in the database, where it is stored as DECIMAL(8,5).

• ###### 4. Re: Calculations: > & < comparisons not working correctly

Deepak - thanks for your response. The values are stored as DECIMAL(8,5). I checked this value and it is 0.90000 so I don't think that is the case.

• ###### 5. Re: Calculations: > & < comparisons not working correctly

I was able to resolve this by having a trace run to see what was going on in the underlying SQL. For some reason, some of the values were coming through in the SQL with numbers other than zero way out in the decimals even though those weren't the actual values in the data.