Is this C code portable? Will it run on Window and Mac?
You need to compile C sources for each supported platform,
etc, etc.
Also interesting, what is time time comparison of these
C or J solutions with grep? Since it's a trivial task.
> From: Robert Cyr <[EMAIL PROTECTED]>
>
> Roger Hui wrote:
> >I would be interested to see the C routine. J Forum msgs
> >do not seem to permit attachments, so you may have to
> >post the code in a J wiki page.
>
> I may not have write permission in J wiki pages. It may be of interest to
> some that:
>
> - J code extracts its IPs in 5 lines. I read un a bit on mapped files and
> ti took about 1/2 hour to write the code. It executes in 0.67 seconds
> after
> loading J.
> - C code was writen as an exercise in 6-8 hours including a revision. It
> was cleanly written in 150 lines and executes in 0.35 secondss.
>
> The author of this C code had studied languages as ML before, but my
> demonstration did not persuade him to give J a try.
>
>
> On Fri, Oct 3, 2008 at 6:41 PM, Dan Bron wrote:
>
> > Robert wrote:
> > > The difference is not dramatic
> >
> > Interesting, it was in my tests. However, the speedup is more a function
> > of the number of IPs (i.e. matches found by 'rhost=
> > '&E. ) than the total size of the file, and obviously my test data differs
> > from yours.
> >
> > > I need to ignore all characters from the first blank
> > > on each IP address, in case the IP is shorter than 14
> > > characters and is followed by something else.
> >
> > Ah, of course. Didn't think of that. Given this constraint, I believe the
> > majority of the time is going to be spent in trimming
> > and reassembling this array. (Again, provided your list of IPs is large.)
> >
> > One potential optimization would avoid trimming the large list of IPs.
> > Take the nub of the "dirty list", then trim, then nub
> > again. Trimming and reassembling this (presumably) smaller array might
> > save you more than the cost of the second nub.
> >
> > Another potential optimization (which again improves with the size of the
> > IP list) is to avoid manifesting the entire addition
> > table. Instead of
> >
> > ip =: ] {~ I.@:E. +/ '255.255.255.255' (+i.)&#~ [
> >
> > you could try
> >
> > ip =: ] ];.0~ (#'255.255.255.255') ,:"0/~ #@:[ + I.@:E.
> >
> > I haven't tested any of these proposed changes, so they may be broken,
> > buggy, or even slower than the current solution. And
> > improvements, if any, are likely to be even less dramatic than the first
> > round.
> >
> > Also, I believe your solution currently completes in less than a second,
> > which is not such a burden. So it might not be worth
> > rewriting, particularly since optimized code tends to be less familiar
> > (hence, less readable/maintainable).
> >
> > The real value of J in this instance is that it's (A) [more than]
> > competitive with the equivalent C code and (B) it was much
> > faster to write (correct?) and very likely easier to change. The more time
> > spent optimizing, the smaller the benefit of (B).
> >
> > > to be as efficient as possible in J, then tacit is the way to go
> >
> > Since one of my two optimizations was a non-starter, the entire speedup can
> > be attributed to the replacement of I. x E. y with
> > x I.@:E. y . That construct is supported by special code, and happens
> > to be tacit. So in this case the efficiencies were a
> > result of using special code, rather than tacit code, per se.
> >
> > -Dan
> >
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
