Support decimal time values

[tanneberger]

Bug

timer clock(1sec, 0.5sec);

throws the following error:

BankToMultiport-gcc-wrapper>   |
BankToMultiport-gcc-wrapper> 4 |     output out:unsigned;
BankToMultiport-gcc-wrapper> 5 |     timer clock(1sec, 0.5 sec);
BankToMultiport-gcc-wrapper>   |                       ^^^ Invalid time literal.
BankToMultiport-gcc-wrapper>   |
BankToMultiport-gcc-wrapper> 6 |     reaction (startup, clock) -> out {=
BankToMultiport-gcc-wrapper> lfc: error: extraneous input 'sec' expecting ')'
BankToMultiport-gcc-wrapper> --> ../../../nix/store/qn4vkn6400yi019h2c6agnlhnhyp96qy-source/test/Cpp/src/multiport/BankToMultiport.lf:5:27
BankToMultiport-gcc-wrapper>   |
BankToMultiport-gcc-wrapper> 4 |     output out:unsigned;
BankToMultiport-gcc-wrapper> 5 |     timer clock(1sec, 0.5 sec);
BankToMultiport-gcc-wrapper>   |                           ^^^ extraneous input 'sec' expecting ')'
BankToMultiport-gcc-wrapper>   |
BankToMultiport-gcc-wrapper> 6 |     reaction (startup, clock) -> out {=
BankToMultiport-gcc-wrapper> lfc: fatal error: Aborting due to 2 previous errors

[edwardalee]

I think this a feature, not a bug. You should say 500ms, not 0.5 sec. The reason is that floats and doubles are not assured of lining up. I don't have an example I am sure of right now, but it would go something like this: if you add 0.000001 sec one million times, the answer is not equal to 1.0 sec.

[cmnrd]

I was sure that we did support floating point times in the past and hence recommended @revol-xut to open the issue, but now I remember that actually we didn't... However, not supporting floating point times in LF seems like a bug to me. I understand the reasoning behind this, but I also believe that it should be up to the user to decide whether to write 0.5 sec or 500 msec. I believe its safe to assume that an educated programmers is aware of the quirks of floats. Of course it is a different question how we represent time in our runtimes. For the runtimes, I agree that integer representations are best. But surely we can convert 0.5 sec to the correct integer number in the code generator.

[edwardalee]

An example of the problems that can arise is given in this paper:

https://link.springer.com/content/pdf/10.1007/s10270-017-0633-6.pdf

The example is:

    double r = 0.8;
    double k = 0.7;
    k = k + 0.1;
    printf("%f,%f,%d\n",r,k,r==k);

The output of this program is 0.800000,0.800000,0. Both r and k appear to have value 0.800000, but due to rounding errors, the test for equality r==k evaluates to false, which is represented as a 0-value integer in C.

As long as float and double are not involved in the implementation (I.e., don't use built-in parsers), I have no objection to supporting this. Will you support all the syntaxes allowed, like scientific notation? This is certainly not a priority for me.

[cmnrd]

I agree that this isn't high priority, but I think it is one of the little things that makes a language more convenient to use. We already have a rule for floating point numbers in scientific notation. In order to implement floating point times, we would only need to update the grammar rule for Time and implement a function that maps floating point values (with units) to an integer value using a well defined rule for rounding.