Comparison works with one Decimal, but not two

[Kunibert]

Hi, 

I am trying to filter values to a range btw two numbers, which is working when I use only one decimal but not two

I have the follwoing table:

fact:

LOAD * INLINE [

  Id, Uplift, Price

  1,   0.5 ,    15

  2,    2,        12

  3,   4.2,      18

  4,   1 ,        11

  5,    0.9,     11

];

And want a set analysis like: Avg( {< Uplift={">=1.1<=3"}  >}  Price   )

When I change the 2nd restriction to a decimal it won't work anymore.  It works with one decimal, no matter the place, but not with two. A few examples: 

Avg( {< Uplift={">=1.1<=3"}  >}  Price   )                WORKS

Avg( {< Uplift={">=1.1<=3.1"}  >}  Price   )            DOESN'T WORK

Avg( {< Uplift={"<=3>=1.3"}  >}  Price   )                 WORKS

Avg( {< Uplift={"<=3.1>=1.1"}  >}  Price   )             DOESN'T WORK

Any help is appreciated. 

Cheers

Kuni

[swuehl]

Using an older version of QV (12.20) available here, your expressions work just fine.

Which exact software version are you using?

[Kunibert]

Really Sorry. Mixed up the forum. 

Using Qlik Sense 12.16 and not QlikView

[marcus_sommer · Accepted solution]

Using a really old QV release (11.2) I see the same behaviour. I assume an parsing-error of the set analysis because the following worked:

Avg( {< Uplift = {">=1.1<=$(=31/10)"} >} Price )

and maybe it's an alternatively for your case.

- Marcus

[Kunibert]

Yes it worked.  Seems indeed to be a parsing error. 

Thanks!

[marcus_sommer]

Another way to bypass it could be use a different number-notation like:

Avg({< Uplift={">=11e-1<=31e-1"} >} Price)

which avoids the use of . as the delimiter.

Stefan mentioned yesterday it worked for him with the normal number-notation like expected and it's the first time I see this as issue and even if I think that this kind of number-comparing isn't often used I doubt that's really a unique use-case.

Therefore I could imagine that this behaviour is caused from the number-formatting variables and/or the OS region-settings which might replace the point with a comma and the following calculation-steps fail on it because they interpret the comma as parameter-delimiter. Nevertheless it's a parsing-error ...

- Marcus