Sorry, looks like I forgort to mention important thing:
f"0 ips - its just to test f function with _one_ argument, because I
am waiting that other system will sent IP one-by-one, not in packet.
And f speed is most important thing.

Regards,

On Thu, Dec 15, 2011 at 4:11 PM, Mike Day <[email protected]> wrote:
> If you're still using
>
>    pip =: (256 #. (-&128 @: {.) , }.) @: (".;._2@:,&'.')
>
> to encode your input data,  giving eg
>
>    pip"1 ] 3{.ipst
> 1590633180 365671447 69450821
>
> you should find an improvement in time by deferring the
> _128 offset,  eg
>
>    ((_2147483648  * * )<.@+])256 #.  (".;._2@:,&'.')"1 ] 3{.ipst
> 1590633180 365671447 69450821
>
> This gives the same results as my suggested stuff with
> shift,  provided the same offset is used.
>
> Mike
>
> On 14/12/2011 1:30 PM, Alexander Epifanov wrote:
>> I was trying to make shift, but i does not work correct, bacause first
>> bit is sign,  that is why 255.255.255.255 is -1, and 0.0.0.0 is 1 and
>> it is not correct to compare them.
>> 0.0.0.0 should be minint, 255.255.255.255 - maxint.
>>
>> Regards,
>>
>> On Wed, Dec 14, 2011 at 1:22 PM, Mike Day<[email protected]>  wrote:
>>> Your problem with deal is easily dealt (!) with:
>>> The vocabulary entry for dyadic ?,  "deal" is
>>>
>>>     "x ? yis a list ofxitems randomly chosen/without repetition/fromi.y"
>>>
>>> So in particular,  5?5 is a random permutation of i.5  .
>>>
>>> The way to get what I think you want is
>>>
>>>     ?10#5    NB. eg roll 10  5-sided dice
>>> 4 2 0 0 2 0 3 1 4 1
>>>
>>> Though why you should want to generate ips when you
>>> have so many already escapes me!
>>>
>>> As for "pip" etc,  you _can_ use 32-bit integers in this fashion:
>>>
>>> NB. encode, ie shift the 4 elements left 3 2 1 0 bytes
>>>     24 16 8 0 +/@:(33 b.) 148 99 57 121
>>> _1805436551
>>>
>>> NB. you presumably need to be able to recover the input
>>> NB. so you need this
>>>     mask =: 24 16 8 0 (33 b.) 255
>>>
>>> NB. to decode, ie unpack the 32-bit integer
>>>     _24 _16 _8 0 (33 b.) mask (17 b.) _1805436551
>>> 148 99 57 121
>>>
>>> This is sort of equivalent to pip:
>>>     pip '148.99.57.121'
>>> 2489530745
>>>     x:1805436551 + 2489530745
>>> 4294967296
>>>     2x^32
>>> 4294967296
>>>
>>> If you're content to use such integers,  you might find
>>> some more improvement by avoiding the use of extended
>>> integers.
>>>
>>> It's surely surprising that J significantly outperforms K .
>>> Have you asked the K-gurus what they think, in the k4
>>> forum?
>>>
>>> Mike
>>>
>>> On 14/12/2011 10:14 AM, Alexander Epifanov wrote:
>>>> Hello again,
>>>> Here my optimized version with ints, its 1.5 faster then float solution.
>>>> http://dl.dropbox.com/u/34917039/ip.j
>>>>
>>>> The main thing: it is much faster than K!
>>>>
>>>> Could you let me know, is it possible to optimize time of "f" function?
>>>> I tryed to represent IP like 4 ints: 192 168 1 1, but this solution
>>>> works much slower.
>>>>
>>>> ips.txt: file with ip addresses
>>>> ipr.txt: file with ip ranges: ip,ip
>>>>
>>>> And the other thing I cannot understand:
>>>>      5?5
>>>> 4 1 0 2 3
>>>>      10?5
>>>> |domain error
>>>> |   10    ?5
>>>> ???
>>>>
>>>> Thank you,
>>>>
>>>>
>>> [snipped the rest]
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
>>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm



-- 
Regards,
  Alexander.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to