openmolecules.org

 
Home » DataWarrior » Bug Reports » > and < signs not interpreted in 6.0.0
> and < signs not interpreted in 6.0.0 [message #2097] Thu, 11 January 2024 12:19 Go to next message
mcmc
Messages: 18
Registered: April 2018
Junior Member
I noticed that 6.0 treats values like <2 and >10 differently from 5.5
In the old version these were treated as numbers, and a column would be correctly assigned as numeric if it would contain entries like these. Allowing for rounding, colouring scales etc.
Now columns with >2 are interpreted as text, generating errors on all my old macros.
Manually setting the columns to floating point generates errors too (image attached).

EDIT: there seems to be an overarching phenomenon, which is the treatment of spaces (notably the lack thereof) in cells.
'>2' seems to be recognized as text, while
'> 2' is treated as a number.
This was different in 5.5

Likewise, multiple numbers without spaces, are treated as text:
'4.5;4.8' is text, while
'4.5; 4.8' are two consequetive numbers.

Clearly it would be great it this could be backwards compatible to 5.5 again.

[Updated on: Thu, 11 January 2024 16:36]

Report message to a moderator

Re: > and < signs not interpreted in 6.0.0 [message #2098 is a reply to message #2097] Thu, 11 January 2024 23:42 Go to previous messageGo to next message
nbehrnd is currently offline  nbehrnd
Messages: 208
Registered: June 2019
Senior Member
Hello mcmc,

in a small library of random molecules generated by DW 6.0, I observe a close `<2`(example metal atom count), or `>30` (example nonH atom count) to be recognized as a comparison against a number; just as anticipated and just as the pattern experience prior to the transient to the new version.

Regards,

Norwid
Re: > and < signs not interpreted in 6.0.0 [message #2100 is a reply to message #2098] Fri, 12 January 2024 12:03 Go to previous messageGo to next message
mcmc
Messages: 18
Registered: April 2018
Junior Member
Unfortunately, I cannot test this anymore, as I have rolled back to 5.5 now.
I had a DW file, with only a few rows, where one column consisted of these values
>2000
55.6
20
Right-clicking on the column heading indicated that these were not numbers. No option to round, for example.
As soon as I introduced the space by editing the cell to '> 2000', the column reverted to numbers and I could round.
This dwar file was not created from scratch with 6.0. Not sure if that could have been part of the problem, but one would still expect backwards compatibility to open older files.

The issue with the multiple numbers was reported by a colleague of mine, so we are at least two people observing space issues.
Re: > and < signs not interpreted in 6.0.0 [message #2101 is a reply to message #2100] Sat, 13 January 2024 20:18 Go to previous messageGo to next message
nbehrnd is currently offline  nbehrnd
Messages: 208
Registered: June 2019
Senior Member
In continuation with DW 06.00.00, I created a new array: the first column with three random molecules (DW generated), the second column added with Data -> Add empty columns, where I selected "text" as category. Manually, I added the strings `>2000`, `55.6`, and `20` to the cells as a test property (cf. attached .dwar and `dw_screenphoto_01.png`). The subsequent addition of a third column by Data -> Add Calculated Values used a function of

if(test_property>20, "big", "small")

proceed smoothly. In your case application, do you equally have the automatic assignment of the column type enabled? This is based on the observation the intended computation is going to fail if the second column (still/accidentally) is set to the level of `text` -- regardless if `force categories` is activated, or not. Subsequent adjustment of the second column, then re-run by right-click on the third column and "update formula and recalculate" adjusted the results.

However: I assumed a right-click on the third column and subsequent "Re-Calculate All Columns" would be more helpful for a global update of the array of maybe multiple columns of calculated values. Hélàs no, it replaced the original entries in the second column by the results of my formula, and yielded the "NaN" indicator in the third column (dw_screenphoto_03.png). This observation is less intuitive to me.

Regards,

Norwid

[Updated on: Sat, 13 January 2024 20:19]

Report message to a moderator

Re: > and < signs not interpreted in 6.0.0 [message #2102 is a reply to message #2101] Wed, 17 January 2024 10:18 Go to previous messageGo to next message
mcmc
Messages: 18
Registered: April 2018
Junior Member
Hi Norwid, all columns are set to automatic type. The same .dwar file behaves differently in 5.5 and 6.0 in terms of interpretation of these spaces. Numbers become text - presumably due to the automatic type.
Re: > and < signs not interpreted in 6.0.0 [message #2105 is a reply to message #2102] Sat, 20 January 2024 15:02 Go to previous message
thomas is currently offline  thomas
Messages: 648
Registered: June 2014
Senior Member
To mcmc: DataWarrior 6.0.0 should be compatible with earlier versions regarding the interpretation of numbers with modifiers like '>2000'. I tested your example (>2000, 55.6, 20) which correctly recognized the column as numerical. Thus, I assume there is something else fishy. Which OS do you use? Possibly the OS localization setting has some influence. Do you use decimal points '.' or ','? If I can reprodice, I may be able to update the numerical recognition circumvent the problem.

To Norvid: Many thanks for your comments on this. I could reproduce your phenomenon with writing into the 'test_property' column instead of the 'Calculated' column. This happened when clicking 'overwrite' twice. When changing the overwrite setting, DataWarrior was adapting the target column setting in a strange way: when choosing to overwrite, it hanged the setting to an existing column ('test_property'Wink and when unchecking again, it was not updating the target column. It was also not perceiving that 'not to overwrite' an existing target column is not really compatible. I updated the behaviour to be more meaningful.
Previous Topic: Change default structure copy option
Next Topic: Bizarre behavior with macos Sonoma
Goto Forum:
  


Current Time: Thu Apr 18 12:47:46 CEST 2024

Total time taken to generate the page: 0.04834 seconds