Neville. My example was only to show that the sort command still maintains the ability to accept concatenated sort criteria. This allows a single line of code to do the work, and obviates the need for multiple sorts. In that sense it was a bad example to use character "places" in a string. This would not be an issue when using an explicit delimiter of some sort, typically what any sane coder would automatically do.
Padding with zeros or spaces is the sort of kludge even I would blanch at. Craig > On Sep 6, 2023, at 7:57 PM, Neville Smythe via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Ralph: Interesting. Your code works as you present it, sorting the given > items by the sortkey function f1 which adds 1 to each item. I do get the > “sorting failed” dialog. > > But if I try the same thing using myVal modified as you suggest, which adds > the first and second items of each line of data and then adds 1 to the global > s1, I get the bug I reported: the handler simply exits without showing either > the “sorting failed” or the “Done” answer dialog. > > I would have thought the two methods would generate the same error code, an > incorrect operand in a sum, so this is strange! The function definitely > returns on the error line, the value of s1 is not changed in the next line in > either your f1 or my myVal. So perhaps the bug occurs when the processing > returns to the sort code. Not something we can solve here, one for the > engineers to sort out (!) > > Mark Waddingham says the sortKey function is intended to be tolerant of > errors, simply returning the original value of ‘each’ - in your case each > item, in my case each line. So it should either > > 1. Continue with the (undocumented) sort order OR > > 2a. exit to top AND 2b. drop into the debugger/errorDialog. In my example it > is doing 2a but not 2b. > > Craig: The missing bit is that your method won’t work if the integers you are > sorting by having different string lengths > > The lines > 2,7 > 1,99 > > should, when sorted by numeric ascending (item 1 of each, item 2 of each) - > which would be the appropriate syntax for a multilevel sort tho not in LC - > result in > 1.99 > 2,7 > > But if sorted by (item 1 of each & item 2 of each) - which concatenates as > strings - gives sort keys 199 and 27 to result in > 2,7 > 1,99 > This can be fixed by formatting the numbers so they have the same length by > padding with 0s, as MW noted. Once they have the same length you could > actually sort lexically which may be a lot faster than sorting numerically > (although my guess is using 2 separate sorts may be faster still at least for > short lists). > > The concatenation method also won’t work if sorting real numbers: > 1.0,0.2 > 1.0,0.1 > since after concatenation the second decimal place would be ignored in a > numeric sort. > > > Neville Smythe > > > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
