Floating point numbers in target functions

[hallba]

Bug from Yuxin Sun

Recently I tried to use target functions with floats in BMA but received errors/unexpected results when operating with floats rather than fractions.

As a reproducible example, I attach a 5-node network: with one node (e) being activated by two nodes (a & b) as well as being inhibited by two nodes (c & d), as shown in the attached .json file. All nodes ranged from 0 to 6. The four parent nodes took values as a = b = 6, c = d = 2. I tried a few target functions at node e, their results are as below:

1. var(a)/2+var(b)/2-var(c)/2-var(d)/2: correct result e = 4
2. var(a)*0.5+var(b)*0.5-var(c)*0.5-var(d)*0.5: incorrect result e = 0 (should be 4)
3. var(a)*0.7/2+var(b)*0.5/2-var(c)*0.3/2-var(d)*0.1/2: incorrect result e = 0 (should be 3.2 and round to 3)
4. avg(var(a)*0.7, var(b)*0.5)-avg(var(c)*0.3, var(d)*0.1): "Service error. The status is neither Stabilising or NotStabilising; result error: 2 failed to parse e’s transfer function”
   float_tf.zip

Examples 1 and 2 are equivalent, and examples 3 and 4 are equivalent, but only 1 received the expected result.

[hallba]

Testing highlights that this is an issue in the parsing. I suspect that the problem is that floating point numbers are being misinterpreted as an integer from the floor of the float.

[hallba]

Some more simple examples; if the float parses, its floored (e.g. 0.1 becomes 0), but sometimes it just won't parse. Suggested fixes
FPParserBugs.zip

• fix the parser in the backend to accept floats (ParsecExpr.fs, line 44)
• use intellisense in the front end to prevent users from writing anything with floats

[Rachel-Alcraft]

Both or either of the above suggestions?

2 questions:

1. How should this look to the user? There are 2(?) methods of causing the front end parser to action - uploading a file and entering from the screen. When entering in the screen it calls the parser continuously with every key stroke so checking and sending messages with every key stroke would be a problem. Although it could stop any character other than an int I guess. But uploading from a file is less clear in this case.

2. Are the use-cases for decimals as factors and ceil(0.1) a different handling case? ceil(0.12) should be parsable to an int so perhaps let that through? Or should there be no decimals at all?

One possibility (maybe short term) is to return the error as above, but make it clear - ie instead of the obscure error simply say "service error, you cannot use decimals in the formulae, see link to documentation for more info", or something like that.

[Rachel-Alcraft]

e.g. I could make an explicit message from the server like below

(note I made a quick icon for it and the message maybe could be improved - "2" at the start refers to the second variable but it is not completely meaningful when you can't see them all, maybe remove it so it is just "Input error ... ").

[hallba]

The icon should be the default error (!) icon similar to when formulas don't parse