update logic of REST_StringHelper::isAExpression()

[nkx111]

Previously pure number will also be regarded as an expression. In this case long numbers are processed by TFormula and converted into scientific notation, and loses precision.

For example, in the old logic, the parameter:

<parameter name="seed" value="123456789"/>

will be processed by REST_StringHelper::EvaluateExpression(). It will be converted firstly into (double)1.2345789e+08, and then converted into (string)"1.23457e+08", and then back to (int)123457000. This is problematic for seed definition.

So this PR updates the logic of expression identification, inside REST_StringHelper::isAExpression(). The simulation results may be different.

restG4 pipeline for branch nkx111-patch-3 :

[jgalan]

It is better to wait for pipeline is green to ask for review. There is a risk the review will be forgotten, because if it is running or red I will change to do something else, and I do not have a new notificiation to remind me I have to review this PR.

[jgalan]

Which is the nature of the error at the main framework pipeline? @lobis

In restG4 why the 08.alphas is not present at latest commit at master?

[jgalan]

Should not be simply used Int_t REST_StringHelper::isANumber(string in) inside the implementation?

[jgalan]

We could perhaps implement IsAnInteger that it will be true when the number contains no letters and no ..

[lobis]

Which is the nature of the error at the main framework pipeline? @lobis

In restG4 why the 08.alphas is not present at latest commit at master?

What do you mean? I see it on master https://github.com/rest-for-physics/restG4/tree/master/examples/08.Alphas.

[lobis]

REST_StringHelper::isAExpression(const string& in)

[jgalan]

Ok, it is there at master. Probably I was looking at a branch.

[lobis]

for (const auto& item: funcs){
        if (in.find(item) != std::string::npos) {
            symbol = true;
            break;
        }
    }

[jgalan]

But my question to you was "Which is the nature of the error at the main framework pipeline? How do we debug that?" @lobis

[lobis]

But my question to you was "Which is the nature of the error at the main framework pipeline? How do we debug that?" @lobis

It looks very similar to what I was encountering due to startup.cpp when implementing testing. It looks that the error comes from unit testing targets.

The main cause of the problem is still not understood by me and the dirty fix was the ignore some code on startup.cpp, this issue #169 is still opened for whoever wants to fix this.

My bet for this failure is that maybe some of the changes I made to avoid startup.cpp on testing have been reverted perhaps? Or something similar.

But the small changes in this PR doesn't suggest how this could end up affecting unit testing...

[jgalan]

But it says time out perhaps is trying to connect to a server and gets no response?

[lobis]

But it says time out perhaps is trying to connect to a server and gets no response?

Today this has happened a few times, maybe there is an issue with the gitlab or our network

[lobis]

I am still not sure why pipeline is failing, but in this PR #189 something similar seems to be taking place...

Locally everything works but in the pipeline fails.

[jgalan]

Should not be simply used Int_t REST_StringHelper::isANumber(string in) inside the implementation? Perhaps a new method isAnInteger would be handy?