Thank you for taking the time to help. Since I can't share my example due to sensitive information in the document, I will speak generally.
I'm using RangeMin( ) to find the lowest calculated value in a range. Generally my equation looks like this:
RangeMin(
Fabs(([Field1]*sum([Field2]))-sum($(Variable1))),
Fabs(([Field2]*sum([Field2]))-sum($(Variable1))),
Fabs(([Field3]*sum([Field2]))-sum($(Variable1))),
Fabs(([Field4]*sum([Field2]))-sum($(Variable1))),
Fabs(([Field5]*sum([Field2]))-sum($(Variable1))),
.....
Fabs(([FieldN]*sum([Field2]))-sum($(Variable1))),
)
This works perfectly for me elsewhere, just not in this particular instance. I do get a result. But that result obviously isn't the min of the range. I have a feeling it has to do with the use of $(Variable1). In the other instances where it does work for me, I just use a [Field] instead of a $(Variable). Do you agree that the problem is with the variable being used? If so, what characteristics of a variable would prevent this from working properly?
If your RangeMin() expression is itself a variable, and Variable1 is itself an expression, and you're running on a multi-core processor, that could cause the problem. QlikView isn't smart enough about how it partitions work across cores. It might, for instance, hand off Variable1 to one core and your RangeMin() variable to another core at the same time. Variable1 might finish calculating halfway through the calculation of the RangeMin(), causing some of the compared values to use the old Variable1, and others to use the new Variable1, and thus you would get an incorrect minimum.
I don't think this would be the cause if the RangeMin is just an expression in a chart, say. I think QlikView does the variables before their use in charts, but perhaps I'm wrong. I can't remember for sure.
I of course have no idea if that's the problem. It's just one way I can see a problem occurring that would be specific to variables. There may be a much more mundane answer.
Thanks for the very thoughtful answer. My RangeMin() expression is not a variable, but the variable within it is an expression. So based on your answer I could see why that might explain the odd result. Do you think if I fully wrote out the expression instead of using the variable that it might change things? Or are there other solutions you or the community might recommend?
Edit: Also worth noting... if I only put a few expressions in the rangemin(), still using the variable, then it works. That might also hint that your answer is pinpointing the problem. But I have no idea how to get around that.
Yeah, I would at least TRY repeating the expression over and over in your rangemin(). If it DOES fix it, I'd agree with your initial conclusion that it's at least SOME bug dealing with variables, whether or not it's the specific one I mentioned. If it doesn't, then we'll be searching for some other explanation. Either way we'll have learned something.
Writing out the full expression did not fix the issue.
It's a really long expression, although there are still a few variables in there that are true variables instead of just shortcuts for other expressions. Basically I wrote out the full expression in the "purest" form possible and it didn't change anything. However taking out enough of the rangemin() expressions still does eventually fix the issue - just not what I need. Back to the drawing board, thanks for the discussion thus far.
Hmmm, it's a mystery. If you want to post the application without the sensitive information concerns, you can go into Settings -> Document Properties -> Scrambling and scramble any fields with sensitive information. I've not actually ever done it, but it ought to work. Well, as long as the sensitive information is just the information, and not, say, the calculations themselves, or how the information is presented.
Since it's looking like a bug, you might also be able to get QlikTech's help on it. For them, I'd recommend trying to figure out the simplest random-data example that demonstrates the problem you're having. The process of trying to create such an example might also teach you more about the bug. Once you have a working (well, non-working) example, submit it with a bug report, and they should get back to you quickly with some sort of answer. It's at least one option you have, anyway.
I never noticed any irregular behaviour by dividing a calculation to n cores and merging the n intermediated parts to the final evaluation - regardless if variables were included or not. Therefore I think it's rather unlikely that there is a software-bug within the processing-order. I don't know if Qlik used any "smart" hardware-features respectively the processor itself is using advanced "guessing" features or similar stuff which may not always be correct. But again it seems not very likely - at least for me.
Much more likely would be that there are any syntax issues within your expression - not causing errors but wrong results and/or mistakes within the data-model and/or an unexpected poor data-quality. The first quick insights might be generated by removing the range-function and replacing the parameter comma-delimiter with & '|' & to concat everything within a string. Maybe there are some surprises.
