Equations with Complex numbers should always be flattened to scalar components by the NF

[Francesco Casella]

Please consider the attached test case. If I run TestComplex.Basic with the old FE and -d=dumpdaelow, I get

1/1 (1): q.re = time   [binding |0|0|0|0|] 
2/2 (1): q.im = 2.0   [binding |0|0|0|0|] 
3/3 (1): x = 2.0 * time   [dynamic |0|0|0|0|] 
4/4 (1): z.im = 0.0   [dynamic |0|0|0|0|] 
5/5 (1): z.re = time   [dynamic |0|0|0|0|] 
6/6 (1): w.re = time   [dynamic |0|0|0|0|] 
7/7 (1): w.im = 1.0   [dynamic |0|0|0|0|] 
8/8 (1): v.im = z.re * w.im + z.im * w.re   [dynamic |0|0|0|0|] 
9/9 (1): v.re = z.re * w.re - z.im * w.im   [dynamic |0|0|0|0|] 
10/10 (1): y.im = time * w.im   [dynamic |0|0|0|0|] 
11/11 (1): y.re = time * w.re   [dynamic |0|0|0|0|] 
12/12 (1): p.im = 1.732050807568877 * w.im   [dynamic |0|0|0|0|] 
13/13 (1): p.re = 1.732050807568877 * w.re   [dynamic |0|0|0|0|] 
14/14 (1): r.re = q.re   [dynamic |0|0|0|0|] 
15/15 (1): r.im = q.im   [dynamic |0|0|0|0|] 
16/16 (1): s.im = x * w.im   [dynamic |0|0|0|0|] 
17/17 (1): s.re = x * w.re   [dynamic |0|0|0|0|] 

With the NF, I currently get an error because of #4971; if I run TestComplex.Reduced, which doesn't have the offending equation, the output of dumpdaelow is

1/1 (1): x = 2.0 * time   [dynamic |0|0|0|0|] 
2/2 (1): z.im = 0.0   [dynamic |0|0|0|0|] 
3/3 (1): z.re = time   [dynamic |0|0|0|0|] 
4/4 (1): w.im = 1.0   [dynamic |0|0|0|0|] 
5/5 (1): w.re = time   [dynamic |0|0|0|0|] 
6/6 (1): v.im = z.re * w.im + z.im * w.re   [dynamic |0|0|0|0|] 
7/7 (1): v.re = z.re * w.re - z.im * w.im   [dynamic |0|0|0|0|] 
8/8 (2): y = Complex.'*'.multiply(Complex(time, 0.0), w)   [dynamic |0|0|0|0|] 
9/10 (1): r.im = q.im   [dynamic |0|0|0|0|] 
10/11 (1): r.re = q.re   [dynamic |0|0|0|0|] 
11/12 (2): s = Complex.'*'.multiply(Complex(x, 0.0), w)   [dynamic |0|0|0|0|] 
12/14 (1): q.re = time   [binding |0|0|0|0|] 
13/15 (1): q.im = 2.0   [binding |0|0|0|0|] 

where it shows that the equations for y and s have not been flattened down to their scalar components. This is not acceptable, as it hampers futher optimizations by the backend.

Please make sure TestComplex.Basic and TesComplex.Test are fully transformed into scalar equations also when processed by the NF.

[Per Östlund]

This might be something that should be fixed in the backend, since it looks like an inlining issue.

Note that the old frontend flattens the Reduced model incorrectly, because for e.g. w = Complex(time, 1) it selects the default record constructor for Complex. This is wrong, since the default record constructor should never be used if any overloaded constructors exist for the type. This happens to work for Complex since the default and overloaded constructors are functionally the same, but will of course not work in general.

It's also implemented incorrectly in the NF since it will fall back on the default constructor if none of the overloaded constructors match, but at least it seem to prefer the overloaded one.

[Francesco Casella]

Replying to perost:

This might be something that should be fixed in the backend, since it looks like an inlining issue.

Yes, I guess so. I added @vitalij in cc:, maybe he's willing to have a look, as he has already worked on a similar issue. We can discuss this today in the devmeeting.

[Per Östlund]

Fixed in 2dc3bec6, this turned out to be the same isse as #4971 in that the operators weren't marked as inline. Both the Basic and Reduced models now give equivalent equation systems in the dumpdaelow output.