Feature Request: >= and <= operators in filter function box

As far as I am aware, for an unexplained reason, "greater than or equal to" and "less than or equal to" are two operators that are not supported in the filter function formula. In all the software development I've done in my 20 year career every system has supported the 6 basic operators and 3 logical operators.

> Greater than
< Less than
>= Greater than or equal
<= Less than or equal
!= Not equal
== Equal

It does support logical operators such as AND and OR but curiously not NOT.
It would be nice if HP Tuners also implemented the standard logical operators

&& AND
|| OR
! NOT

The reason for the need should be self-explanatory but I will provide a typical situation. Suppose you wish to graph a variable in a certain region you would add a filter function of [var]>5 and [var]<10. And in another graph you want to graph that variable [var]>=10 and [var]<15. This provides full coverage, however the greater than or equal conditional operator doesn't exist, so if you use [var]>10 then you have actually skipped over all values that are equal to 10.

Thank you for this consideration

And to expose the enum index so flags can be included in the filter.

I just looked into this.

There's no quick and easy way to add >=, etc.. but we can add it to the list. I agree these basics should be supported.

For now I think you should be able to do (left > right OR left = right) for >=.

Quote:

---

Originally Posted by Keith@HPTuners

I just looked into this.

There's no quick and easy way to add >=, etc.. but we can add it to the list. I agree these basics should be supported.

For now I think you should be able to do (left > right OR left = right) for >=.

---

Yes, but then the formulas start getting really long and the scanner REALLY starts to bog. Just this formula -

" ABS([50040.71]-[50040.71.shift(-10)]) < ([50040.71]/[50040.71.shift(-10)])*0.1 & ABS([2311.71]-[2311.71.shift(-10)]) < ([2311.71]/[2311.71.shift(-10)])*0.1 OR [50090.156] > 95 "

being used in a couple of locations is enough to just about kill it so once you start adding in this -

" [14.161] > 25 and [14.161] < 35 and [2172.161] > 4 and [2172.161] < 11 "

plus the other part, well it literally takes 5 minutes sometimes to open 20 or 30 minute logs. Then you might as well forget other functions.

How would the equations you listed be improved with new operators?

The big CPU sinks you have are ABS and the .shift(). I can look into seeing if parts of the expression are being calculated multiple times. IE: You have 50040.71.shift(-10) listed twice, but it should only need to be calculated once per function evaluation.

Also, can you explain what this expression does in more detail?
" ABS([50040.71]-[50040.71.shift(-10)]) < ([50040.71]/[50040.71.shift(-10)])*0.1 & ABS([2311.71]-[2311.71.shift(-10)]) < ([2311.71]/[2311.71.shift(-10)])*0.1 OR [50090.156] > 95 "

You might be able to take advantage of the slope() function.

Please submit a ticket with a log that takes a long time to open. Please include a layout that opens the log fast, and a layout that opens the log slow.

Thanks!

Thanks Keith you're the best!

I am really hoping this feature request gets added.

Can you elaborate on the specific challenges you face with the current formula limitations and how the suggested operators would significantly improve your tuning process?