Sort IP List

[Mike Bonner]

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 <bonnmike at 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 at 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 at 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 at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>