Sort IP List

Mike Bonner bonnmike at gmail.com
Fri Jun 29 13:29:09 EDT 2018


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
>



More information about the Use-livecode mailing list