Divisions of integers not converted to divisions of doubles in generated C++ code of nestml functions about nestml HOT 5 OPEN

@WillemWybo : thanks for reporting this. I will look into it, could you help in define the semantics of the division operator? Should we be Python-like and have / always represent floating point division, only (possibly) coercing the result to integer depending on the type of the variable we assign it to? I.e. (see especially x9):

parameters:
    x1 real = 4 / 7                   # expect 0.57..
    x2 real = 4
    x3 real = 7
    x4 real = x2 / x3                 # expect 0.57..
    x5 integer = 4
    x6 integer = 7
    x7 integer = x5 / x6              # expect 0
    x8 real = x5 / x6                 # expect 0.57..
    x9 real = x5 / x6 + x5 / x6       # expect 1 (C semantics would yield 0)
    x10 integer = x2 / x3 + x2 / x3   # expect 1

from nestml.

We could also introduce the Python // operator for integer (actually, "floor") division.

This means that a/b would always be rendered in C++ as something like ((float)a)/((float)b).

But note that in Python, -3//2 equals -2 ("floor division"), whereas in C -3/2 equals -1 ("true" integer division). So we should be diligent about defining the semantics.

from nestml.

@clinssen you raise an interesting point. My functions were returning real. It would make sense to make the division behaviour dependent upon the expected return type, as you propose.

Sympy seems to take the explicit approach, where sp.printing.ccode() returns floor(a/b) for a//b and (float)a/(float)b for a/b. I guess if the variable is assigned to an integer it would be reasonable to expect the behaviour (int)floor(a/b) or (int)((float)a/(float)b), the latter case being the true integer division.

Note that if the variable is part of some complex expression, i.e. exp(a/b + c), and then converted to an integer, I would still expect the behaviour (int)exp((float)a / (float)b + (float)c), but maybe this is personal taste.

from nestml.