Bad macro for semiLinear

[crupp@…]

In openmodelica.h the macro for semiLinear is defined as:
#define semiLinear(x,positiveSlope,negativeSlope) (x>=0?positiveSlope*x:negativeSlope*x)

If x is an expression such as x=-1+a/b then the macro evaluates it incorrectly.

It should be:
#define semiLinear(x,positiveSlope,negativeSlope) (x>=0?positiveSlope*(x):negativeSlope*(x))

The added parentheses fix the issue. I've attached a test case that illustrates the issue. In this test the expression is transformed into semiLinear(-1+d/L,k,0).

It turns out that this is a long-standing issue since it was implemented (2010). Maybe it will magically fix some test cases.

[Vitalij Ruge]

Thank you for the analysis!

[Vitalij Ruge]

your fixes was added with ​PR528

[crupp@…]

Looks like I was sloppy. The cpp version also needs it in:
OMCompiler/SimulationRuntime/cpp/Include/Core/Math/Functions.h

[Adrian Pop]

Added rfranke and niklwors to CC for the CPP runtime.

[crupp@…]

Also, vitalij was smart and caught the error in my fix, it should be:
#define semiLinear(x,positiveSlope,negativeSlope) (x>=0?(positiveSlope)*(x):(negativeSlope)*(x))

Is there any reason that the conditional x>=0 should be (x)>=0? The only reason I can think of is if there was some sort of bitwise operator. I don't know how that would get there, but it may be better to be safe than sorry.

[Martin Sjölund]

I think I would have preferred to make it a static inline function, or just inline it in the code generator for the simple reason that x is present in multiple places and could in some instances cause unexpected behaviour.

[Rüdiger Franke]

@crupp: can you be a bit more specific what you mean with "Looks like I was sloppy. The cpp version also needs it in: OMCompiler/SimulationRuntime/cpp/Include/Core/Math/Functions.h"?

The inline function should be ok:

inline static double semiLinear(double x,double positiveSlope,double negativeSlope)
{
 if(x>=0)
    return positiveSlope*x;
 else
    return negativeSlope*x;
}

[crupp@…]

Having not used them much in the past, I was assuming that inlined functions are treated similarly to macros in that it mixes the operations. After reading into it, it looks like I'm wrong and that it still behaves like a function. So, I retract my statement. Sorry for the trouble.

[Vitalij Ruge]

Replying to sjoelund.se:

I think I would have preferred to make it a static inline function, or just inline it in the code generator for the simple reason that x is present in multiple places and could in some instances cause unexpected behaviour.

I like the idea with inline function. ​PR 533

principally it work for DIVSION_SIM ​PR 534, too??