I am using version 22.20.0.36 of UltraEdit for Windows and I am trying to do a numeric sort on a very simple list of 20 rows. The sort works if I do NOT use numeric sort, so this is not a need right now, but clearly I am doing something wrong. Here is the list:
If I open File - Sort - Advanced Sort/Options and set Sort order to Ascending, put a check mark in Numeric sort, and Sort columns from 1 to -1, and click the Sort button, nothing happens. It works this way whether I select the rows or not, whether I have Remove duplicates selected or not, and whether I have Ignore case selected or not.
This is basic stuff, so I am the wild card here. What did I do wrong?
The numeric sort feature is designed to sort lines containing anywhere inside the lines a number (integer) with different number of digits, i.e. 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20, 21, 3, 4, 5, 6, 7, 8. There is no need to use numeric sort if the numbers have all the same number of digits because of leading zeros. But it should be nevertheless possible to use numeric sort on numbers with equal number of digits even if not really needed by all means.
The numeric sort requires that Key 1 contains a determined column range specification. Those columns (better character index in line string with taking tab stop width into account) should contain just digits and spaces/tabs. The string in this column range in every line must be converted to an integer for numeric sort which explains why there should be no other characters than digits and (preceding/appended) spaces/tabs. Well, non whitespace characters after the digits are also no problem because ignored by string to number conversion routine. But there should be never non whitespace characters at beginning of string in specified column range as this results in string to integer conversion fails completely.
It looks like the developers of UltraEdit have never thought that a user specifies -1 for end column as the result is obviously an undefined behavior. Most likely the string extraction from line fails with -1 as end column index producing finally on sort unexpected results.
Okay, replacing -1 for end column by 4 is no real problem here. Running now a numeric sort with 1 for start column and 4 for end column to let numeric sort evaluate the digits in first 3 columns of each line converted internally to integers should produce now the expected result, i.e. same result as doing a simple character based sort. But the result is still not as expected.
But after appending any character at end of each line and running numeric sort with 1 and 4 defined for Key 1 produces the correct sort result.
I have no other explanation for this behavior than a coding error, i.e. a bug of UltraEdit. It looks like with end column for numeric sort being equal the column containing (first) line terminator character, the existing code does not work. From a programmers point of view this looks like a typical "internal character index in string starts with 0, visible column index starts with 1, and length of string/line without line terminators is +1 of index of last character in line" coding mistake issue.
Please report to IDM support by email that a numeric sort with 1 for start column and 4 for end column produces the wrong result for lines containing all just numbers with 3 digits because of a bug. Or let me know if I should report this issue by email to IDM support.
By the way: If the sort does not work at all with the specified options, in prompt area on left side of the status bar at bottom of UltraEdit main window the message "Unable to sort file. Please try alternate sort option." is displayed indicating the error. The mouse pointer should be moved over any icon in toolbar to get this error message removed from status bar before starting a new sort with alternated sort options because the prompt area in status bar is not updated on a successful sort. Otherwise the error message from failed sort could lead to wrong assumption that new searched failed again even if new sort was executed with success producing an expected or unexpected result.
Best regards from an UC/UE/UES for Windows user from Austria