I have a Rule that pulls all customers where a field is greater than ".5" and less than or equal to ".9"
It's returning customers whose values are between ".50" and ".90"
I would expect it to return values between ".45" and ".94"
Page 1 / 1
Hi Seth,
Do you have some screen shots or examples? I'm a little confused as .45 is less than .5 and .94 is greater than .9, so I guess I'm not sure of the behavior you are expecting to see.
Do you have some screen shots or examples? I'm a little confused as .45 is less than .5 and .94 is greater than .9, so I guess I'm not sure of the behavior you are expecting to see.
Hi Dan,
0.45 is less than 0.50, but, when rounded to one digit, is equal to 0.5
0.45 is less than 0.50, but, when rounded to one digit, is equal to 0.5
I guess it might be dependent on where and when the rounding it taking place. Are you rounding the field containing the hundredths place (the .45 and .94 values) to tenths before the rule comparison takes place?
Reason I ask is because if you're comparing a hundredths place fraction against a tenth place value, then what usually happens in code is unless the hundredths place value is first converted to tenths (converting the .45 to .5) then the tenth place number is converted to hundredths (in this case the .5 would become a .50).
So I think this explains what you're seeing. Without an explicit conversion of the .45 to round to nearest tenth, the .5 is interpreted as .50.
To get around this - are you able to specify in the rule to look for customers where a field is greater than .45 and less than .95? This should solve your issue.
Reason I ask is because if you're comparing a hundredths place fraction against a tenth place value, then what usually happens in code is unless the hundredths place value is first converted to tenths (converting the .45 to .5) then the tenth place number is converted to hundredths (in this case the .5 would become a .50).
So I think this explains what you're seeing. Without an explicit conversion of the .45 to round to nearest tenth, the .5 is interpreted as .50.
To get around this - are you able to specify in the rule to look for customers where a field is greater than .45 and less than .95? This should solve your issue.
Hi Dan,
Yes, that's certainly a valid workaround, and I wanted to flag for you all that it's just not the behavior I would expect since the rule doesn't explicitly state "0.50" and "0.90"
Yes, that's certainly a valid workaround, and I wanted to flag for you all that it's just not the behavior I would expect since the rule doesn't explicitly state "0.50" and "0.90"
I'll see if anyone from engineering or product chimes in here as to how this is handled in the code, but my understanding is that subsequent zeros in rounding are implied - .5 = .50 = .500 = .5000 and the extra zeros are only expressly shown if the intent is to round to the nearest [tenth, hundredth, thousandth, etc].
It's been a few decades since I learned that in school, but I *think* (hope) it's still accurate.
Fair warning - when I was in school we had 9 planets, not 8, so maybe the education system changed this too. 😉
It's been a few decades since I learned that in school, but I *think* (hope) it's still accurate.
Fair warning - when I was in school we had 9 planets, not 8, so maybe the education system changed this too. 😉
Seth - If the decimal places of a particular field is set to 3 decimal places and the value you entered in the input box is one decimal place then the system automatically add the remaining zeros. This is done at the SOQL layer in SFDC or in SQL layer in other relational databases. There is minimal control on that from application layer perspective.
You have to enter the remaining decimal places in the input text box to avoid this issue as of now.
You have to enter the remaining decimal places in the input text box to avoid this issue as of now.
Reply
Sign up
If you ever had a profile with us, there's no need to create another one.
Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
Welcome to the Gainsight Community
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.