I have been using this construction (0.0 + string) in some of my scripts for several years. This particular construct fails on the 20221101-121c245d5d-win_x64-devprev and one preceding devprev release, but NOT on the main release on the same machine with the same script and the same data. Has anything changed in the way LUA is interpreted since the last Main release ?
I read about a new feature in LUA 5.3 regarding floating point numbers. Might this also be related to the atom issue being in integer form ? Ths website mentions a compilation option for LUA 5.2 compatibility when compiling for LUA 5.3:
https://q-syshelp.qsc.com/Content/Control_Scripting/Lua_5.3Reference_Manual/8-_Incompatibilities_with_the_Previous_Version.htm#1
"
Changes in the Language
The main difference between Lua 5.2 and Lua 5.3 is the introduction of an integer subtype for numbers.
Although this change should not affect "normal" computations, some computations
(mainly those that involve some kind of overflow) can give different results.
You can fix these differences by forcing a number to be a float (in Lua 5.2 all numbers were float),
in particular writing constants with an ending .0 or using x = x + 0.0 to convert a variable.
(This recommendation is only for a quick fix for an occasional incompatibility;
it is not a general guideline for good programming.
For good programming, use floats where you need floats and integers where you need integers.)
"
@rmoretti @bkoep There seems to be a difference between the notation in the script for floating point numbers ( a DOT) and the processing of floats in the program (a COMMA). I have tested this by doing simple arithmatic on floats (which work when entered as dots)
a = 0.1 (zero DOT one)
b = 0.2 (zero DOT two)
astring = "123.456" (one two three DOT four five six)
a+b is valid
print(a+b) yields 0,3 (zero COMMA three)
a+astring yields an error saying arithmatic is being performed on a string.
Replacing the DOT in astring however yields a valid coercion and computes to 123,556
This is not in line with LUA documentation in my understanding which states:
"
A string is converted to an integer or a float following its syntax and the rules of the Lua lexer. The string may have also leading and trailing whitespaces and a sign. All conversions from strings to numbers accept both a dot and the current locale mark as the radix character. (The Lua lexer, however, accepts only a dot.) If the string is not a valid numeral, the conversion fails. If necessary, the result of this first step is then converted to a specific number subtype following the previous rules for conversions between floats and integers.
@jflat06 In the latest devprev this issue is not observed anymore. What was the cause if you fixed it ? A fix for this is not mentioned in the release notes.
Hi @"Bletchley Park" - We think we may have found the underlying bug behind both this and the strange unideal pose loading issue from one of your other reports.
It seems to be related to the locale settings used by C++. Manually setting the locale to a locale that uses 0,0 notation instead of 0.0 will result in all atom coordinates being truncated down into integers, resulting in the wacky poses you've shared with us.
We believe you are seeing this because your system locale uses the 0,0 notation, and there is a bug in one of the drug design libraries. The library sets the locale to the proper 'C' locale, and then restores it back to the original after it is done. However, the bug results in it restoring the system locale instead of the original, leading to this behavior.
We think we have a fix for this, but in the meantime, you can avoid the bug by either setting your system locale to one which uses 0.0, or by avoiding the Small Molecule Design puzzles. Note that the wacky solutions might persist if they make it into your autosaves, so you may need to clear those out.
Thanks for all the debug info on this and your observations - they were extremely helpful! Hopefully our fix will squash both of these bugs.
Thank you @jflat06 , I hope it indeed solves the issue. Strange is that it has not occurred since I got a devprev update one or two updates ago if you have not posted a fix for it yet.