| > and < signs not interpreted in 6.0.0 [message #2097] |
Thu, 11 January 2024 12:19  |
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 #2100 is a reply to message #2098] |
Fri, 12 January 2024 12:03  |
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 |
nbehrnd
Messages: 211
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 |
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.
|
|
|
|
|
|
Search
Help
Members
Register
Login
Home
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.
