Actually, when using the multiple key sort, dont reverse the order since it does it all in one go.
On Fri, Jun 29, 2018 at 11:29 AM Mike Bonner <bonnm...@gmail.com> wrote: > Ok, now i'm curious about something.. I know its possible to designate > multiple keys to a single sort using the form.. > sort lines of plist by item 1 of each & item 2 of each & item 3 of each > & item 4 of each > which works fine. > But changing it to.. > sort lines of plist ascending numeric by item 1 of each & item 2 of > each & item 3 of each & item 4 of each -- reverse this for your desired > sort > doesn't sort numerically (even if each key is forced to numeric with a + 0) > > BTW, I had to go back to comments in an older version of LC to remember > how to do the multiple-key sorts. > > Since it ignores the "numeric" part, if one limits ips to all 3 digit > numbers, the sort works as expected despite sorting as alpha. > > So my question is this.. Would it be a reasonable feature request to > adjust sort so that its multiple key format respects the numeric sort type? > > > On Fri, Jun 29, 2018 at 10:46 AM Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> A realistic expectation of IP addresses for a given network might only be >> around 16,535 (class B network) assuming every address was in use, an >> unlikely scenario. I thought of way to do this for an extremely large >> number of addresses by reading a large file in 1000 line chunks into 4 >> columns of a SQL memory database, then querying using concatenation and >> sorts on the 4 columns, and using limit 1,1000 1001,1000 2001,1000 etc. and >> writing back to another file. The time to do this of course would be much >> longer, but it would avoid any memory constraints. >> >> Bob S >> >> >> > On Jun 29, 2018, at 09:35 , Mike Bonner via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> > >> > ## was writing this when your response showed up.. >> > Just did some tests. For reasonable size lists of IP numbers, your >> method >> > is clearly faster. As lines increase the disparity shrinks (due to 4 >> > processings of the same lines rather than 1) until around 35000 lines at >> > which point positions reverse and the disparity grows in favor of the >> > function(each) method. >> > >> > After just a bit more testing, the fastest method (for anything over >> 20000 >> > lines) is to run through the whole list first converting it to numeric >> and >> > then do a single simple sort, but that leaves you with a straight list >> of >> > numbers that would then have to be re-divided into triads, so the post >> > processing needed kills the whole idea. >> > >> > As for your response, >> > Yes the function is called by sort for each line and returns the >> numbers >> > to use to give that line its sort value. It isn't as fast as I had >> hoped >> > most likely because it has to call a function for each line in the list. >> > With the first method I posted, on my machine, the crossover point is >> right >> > around 35000 lines (at least on my system, at 35000 lines it takes 475 >> > millisec to 612 millisec vs the 4xsort) At 200,000 lines the disparity >> > grows to over 3 seconds difference, but i'm unsure what max length list >> > might be reasonably expected. The 4 sort method is by far the simplest >> to >> > code and is plenty fast for list under 100000. >> > The nicest part of your method is that if processing a huge list, its >> easy >> > to give visual feedback between each sort if need be. But again, all >> this >> > is likely moot unless the ip list is huge. >> >> >> _______________________________________________ >> 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