SLIDERS DON'T WORK

[christian77]

Hi.

I have a simple table with a calculated dimension.

That dimension shows a list of records that fulfill some conditions. There is only one condition in the example.

That condition depends on a numeric variable. When I enter a numeric value for the variable with an input box, it works. When I enter the same value with the slider, it does not work.

Also, it does it randomizely; works fine with 85%, but not with 95%.

Does anybody knows how to fix the problem, keeping the sliders as inputs?

Thanks

[christian77]

Hi.

It's a bug.

I made the calculation in the script and fails again.

I set the static increment to 0.009 an it does it even worse. 95.40 % and it fails to work properly.

I have tried with SR6, SR7, SR8, SR9 and SR10. None works.

I'm forced to use input boxes.

Document attached.

Slider is not longer an object to trust nor to offer to clients, who at the same time, lose confidence seing this sort of failures.

I don't have time to place a ticket, neither I know where to place it.

[christian77]

Big misteries like the slider and the 95% number, (Only fails with 95%, not with 96%), are sometimes solved with a very big ÑAPA that we put on top and then we don't see misteries anymore.

So, a very big mistery underlies every big ÑAPA.

[flipside]

Hi Christian,

Not sure this is a bug but a rounding error as described in this ...

http://community.qlik.com/blogs/qlikviewdesignblog/2013/12/17/rounding-errors

Try this as your calculated dimension ...

=if( num(AGGR(
sum(F3)*100/SUM(F2)
,F1))
>=
vLimit*100,
F1
)

flipside

[christian77]

Hi, thanks for your reply.

I've already lost much time with this matter.

If it is a rounding problem, why it does it with 95% and not with 85%?

Have you seen the doc.?

In the last version, I do the calculation in the script and it's the same result.

What is abot with 19/20 = 0.95. What is the difference with 17/20 = 0.85?

Is 0.95 a mistery number?

Let me tell you my ÑAPA.

Since I know much more, 100% sure and even more sure that the flaw is in the slider, I go like, check it out,

num#(num(vLimit)), and it works.

It is not about the calculation, it's about the slider, and the way slider treats the number.

I tried before taking away the static step, but then, I can't make it to be .95, because, I had to adjust the slider to have some fixed measure, so everytime you clik on it, it advances a 0.01 points.

Thanks.

[flipside]

The slider is set up with a range of 0 to 1 to represent 0% to 100%, therefore it is storing 85% as 0.85 and 95% as 0.95. If you create a text box and type =ceil(0.85,0.01) you will get 0.86, so you will see that the values are not being stored as expected but this is due to the limitations as described in Henric's article. 0.85 is being calculated by the system as ever so slightly higher than 0.85 so rounds upwards.

If you are allowing users to choose values for comparison, try to only use whole numbers, so change the slider to range 0 to 100 and alter the calculated dimensions to compare against the whole number only.

flipside

[christian77]

Thanks again.

It works fine with num#(num(vLimit)). It reconverts, rounds, the number and places a format on it.

What amazes me, is, why it does with 95, and not with 75. Also, why it works good when I set the value with the input box, and it does not with the slider? Only for that value. Is 19/20 a difficult to round number, but only when you do it in the slider?

I've seen the rounding article. Very good.

Yes, it works fine with whole numbers.

Thanks flipside.