Thanks for sharing your analysis Marshall. It seems to explain why the other way around out-performance has not been observed (at least not yet).
On Wed, Jan 20, 2016 at 11:27 PM, Marshall Lochbaum <[email protected]> wrote: > Short answer: as far as I can tell, this is never the case. > > Special code identification for forks is handled in the function jtfolk > in cf.c, with the case of capped forks (but also some other cases!) > handled in the block that begins "switch(fi==CCAP?gi:hi){". Special code > for at (@:) and atop (@) constructs is identified in jtatop and jtatco, > in ca.c. These are quite difficult to read (and require constant > character lookups from jc.h), but I have figured out what all the capped > forks do and each of those is also handled in jtatco (@:). So unless > there is other special code hiding out someplace or I made a mistake, > the situation you describe can't happen. > > It's somewhat confusing that special code for (@:) is handled > differently from that for forks. I can't see any problems with using the > same verb for both, and it's not difficult to implement. A small amount > of code is shared between regular and capped forks, but it is far less > than would be eliminated by merging capped forks and (@:) statements. > There's also no performance hit in the case of non-capped forks. > > Marshall > > On Wed, Jan 20, 2016 at 06:09:11PM -0500, Jose Mario Quintana wrote: > > The experiment was for the specific performance of [: u v vs u @: v for > the > > given u, v, X and Y. However, there are other instances as well, for > > example, the reference [2]. I do not recall seen any instance of such > > discrepancy in performance the other way around; that is when [: u v > > clearly dominates u @: v but I would be grateful if you or anyone else > > points me in that direction. > > > > On Wed, Jan 20, 2016 at 5:40 PM, Henry Rich <[email protected]> > wrote: > > > > > The experiment you made is insufficient for the purpose. > > > > > > Usually when u@:v is fast, ([: u v) gets the same treatment. Since > > > /:@:/: is fast, I expected ([: /: /:) to be also. (It's not, > surprisingly). > > > > > > /:@:/: is handled same as /:@/: since they are equivalent. > > > > > > <.@% is fast, but there is no reason to expect ([: <. %~) to be fast, > for > > > two reasons: > > > > > > 1. They have different rank. But <.@:% is also fast, so it turns out > > > this is not the difference. > > > > > > 2. Since <.@:% is fast, so will <.@:%~ be, and normally ([: <. %) too; > > > but ([: <. %~) is totally different. It is equivalent to <.@:(%~) > which > > > is NOT fast. > > > > > > I have not been able to figure out what the verbs f are for which <.@f > is > > > fast. > > > > > > Henry Rich > > > > > > > > > On 1/20/2016 8:31 AM, 'Pascal Jasmin' via Programming wrote: > > > > > >> does [:/:/: not also benefit from special code? > > >>> > > >> I doubt it does, > > >> > > >> timespacex '123 ([: <. %~) 210293810238120398120398120398x + i.1000' > > >> 0.00241248 1.27885e6 > > >> timespacex '123 ( <.@%~) 210293810238120398120398120398x + i.1000' > > >> 0.000590399 836992 > > >> > > >> > > >> ----- Original Message ----- > > >> From: Mike Day <[email protected]> > > >> To: [email protected] > > >> Sent: Wednesday, January 20, 2016 7:50 AM > > >> Subject: Re: [Jprogramming] A Different Less? > > >> > > >> I wasn't advocating /:/: . I prefer using @ but the 13 : ' .... ' > > >> had produced [:/:/: . Conicidentally, Linda appears to > > >> favour the [:u v idiom to u@v . > > >> > > >> So, for Linda's benefit, does [:/:/: not also benefit from > > >> special code? > > >> > > >> Mike > > >> > > >> On 20/01/2016 12:29, Henry Rich wrote: > > >> > > >>> Note: /:@/: y is better than /: /: y (special code) > > >>> > > >>> Henry Rich > > >>> > > >>> On 1/20/2016 5:45 AM, Mike Day wrote: > > >>> > > >>>> Maybe simpler but it requires evaluation of /:/:y twice, whereas > > >>>> Raul's oc manages to make rank the right hand argument to (] - {) . > > >>>> > > >>>> This tacitisation might be what you're looking for: > > >>>> 13 :'r-(i.~ y){ r =./:/:y' > > >>>> > > >>>> i.~ (] - {) [: /: /: > > >>>> > > >>>> > > >>>> It reproduces oc except for using [: rather than @ ! > > >>>> > > >>>> Mike > > >>>> > > >>>> On 20/01/2016 10:27, Linda A Alvord wrote: > > >>>> > > >>>>> A simpler f: > > >>>>> > > >>>>> f=: 13 :'(/:/:y)-(i.~ y){/:/:y' > > >>>>> f > > >>>>> ([: /: /:) - i.~ { [: /: /: > > >>>>> > > >>>>> Linda > > >>>>> -----Original Message----- > > >>>>> From: Programming [mailto:[email protected] > ] > > >>>>> On Behalf Of Linda A Alvord > > >>>>> Sent: Wednesday, January 20, 2016 3:15 AM > > >>>>> To: [email protected] > > >>>>> Subject: Re: [Jprogramming] A Different Less? > > >>>>> > > >>>>> Here's another way to write the code that so far is the fastest. > How > > >>>>> does it compare? > > >>>>> > > >>>>> A=:'abcabbe' > > >>>>> B=:'babe' > > >>>>> f=: 13 :'(/:/:y)-(y i. y){/:/:y' > > >>>>> g=: 13 :'((f x)>: (( ~.y)i.x){(#/.~y),0: y)#x' > > >>>>> A g B > > >>>>> cab > > >>>>> f > > >>>>> ([: /: /:) - i.~ { [: /: /: > > >>>>> g > > >>>>> [ #~ ([: f [) >: ([ i.~ [: ~. ]) { ([: #/.~ ]) , [: 0: ] > > >>>>> > > >>>>> Linda > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Programming [mailto:[email protected] > ] > > >>>>> On Behalf Of Raul Miller > > >>>>> Sent: Monday, January 18, 2016 12:51 PM > > >>>>> To: Programming forum > > >>>>> Subject: Re: [Jprogramming] A Different Less? > > >>>>> > > >>>>> Hmm... > > >>>>> > > >>>>> A bugfixed version of my previous implementation (it broke when x > -. > > >>>>> y was empty) performs approximately the same, for me: > > >>>>> > > >>>>> cle=: ,~ #~ i.@#@,~ e. [: ; (2*#/.~@]) (}.&.>~ #@[ {. ])~ (]i.,~) > > >>>>> </. i.@#@,~ > > >>>>> > > >>>>> I say approximately, because timing variations mean that when I > test > > >>>>> on the same data, sometimes it's faster and sometimes it's slower > than > > >>>>> > > >>>>> oc=: i.~ (] - {) /:@/: > > >>>>> cless =: [ #~ oc@:[ >: (i.~~.) { (#/.~,0:)@] > > >>>>> > > >>>>> That said, Boss's implementation is clearly more concise... > > >>>>> > > >>>>> Thanks, > > >>>>> > > >>>>> -- > > >>>>> Raul > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Mon, Jan 18, 2016 at 12:17 PM, Marshall Lochbaum > > >>>>> <[email protected]> wrote: > > >>>>> > > >>>>>> That's a very cool solution, and much quicker than the one based > on > > >>>>>> progressive index-of. Instead of taking the occurrence count of > both x > > >>>>>> and y, it just takes the count for x and compares it to the total > > >>>>>> number of occurrences in y, given by (#/.~). > > >>>>>> > > >>>>>> Here's a comparison of the two methods. It turns out in the > version > > >>>>>> based on progressive index-of, the desired verb can be obtained > just > > >>>>>> from replacing (i.) with (-.) and then using the first column of > the > > >>>>>> result to select from x, so I've used that version. > > >>>>>> > > >>>>>> NB. Shared verb for occurrence count > > >>>>>> oc=: i.~ (] - {) /:@/: > > >>>>>> NB. Simplified form of what Roger and I posted > > >>>>>> cless1 =: [ {~ [: {."1 #@[ ({. -.&(,.oc) }.) [ i. , > > >>>>>> NB. Tacitized R.E. Boss solution > > >>>>>> cless2 =: [ #~ oc@:[ >: (i.~~.) { (#/.~,0:)@] > > >>>>>> > > >>>>>> NB. test data > > >>>>>> 'a b' =. 500 ({.;~}.) +&(1e5 ?@$ 26)&.(a.&i.) 'a' > > >>>>>> 10 (6!:2) 'a cless1 b' > > >>>>>> 0.0178952 > > >>>>>> 10 (6!:2) 'a cless2 b' > > >>>>>> 0.0063745 > > >>>>>> a (cless1 -: cless2) b > > >>>>>> 1 > > >>>>>> > > >>>>>> To summarize, here's the fastest solution so far: > > >>>>>> oc=: i.~ (] - {) /:@/: > > >>>>>> cless =: [ #~ oc@:[ >: (i.~~.) { (#/.~,0:)@] > > >>>>>> > > >>>>>> Marshall > > >>>>>> > > >>>>>> On Mon, Jan 18, 2016 at 03:49:46PM +0000, R.E. Boss wrote: > > >>>>>> > > >>>>>>> I'm getting old, but still remember my solution, improved by Hui: > > >>>>>>> > > >>>>>>> http://www.jsoftware.com/pipermail/general/2004-May/017503.html > > >>>>>>> > > >>>>>>> 'abcabbe' strikeb2 'babe' > > >>>>>>> cab > > >>>>>>> > > >>>>>>> Curious how it performs compared to the other solutions. > > >>>>>>> > > >>>>>>> > > >>>>>>> R.E. Boss > > >>>>>>> > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>>> From: Programming [mailto: > [email protected]] > > >>>>>>>> On Behalf Of June Kim (???) > > >>>>>>>> Sent: maandag 18 januari 2016 5:19 > > >>>>>>>> To: Programming forum <[email protected]> > > >>>>>>>> Subject: [Jprogramming] A Different Less? > > >>>>>>>> > > >>>>>>>> Hello > > >>>>>>>> > > >>>>>>>> I am looking for a verb(cless) that does something similar to > > >>>>>>>> Less(-.) but counting the elimination, for example: > > >>>>>>>> > > >>>>>>>> 'abcabbe' -. 'abbe' > > >>>>>>>> > > >>>>>>>> c > > >>>>>>>> > > >>>>>>>> 'abcabbe' cless 'babe' NB. get rid of y letters counting > the > > >>>>>>>> occurrences > > >>>>>>>> > > >>>>>>>> 'cab' > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> It is easier to define such a verb recursively: 'abcabbe' cless > > >>>>>>>> 'babe' > > >>>>>>>> equald to 'e' cless~ 'b' cless~ 'a' cless~ 'b' cless~ 'abcabbe' > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> I think recursive definition isn't a usual J-ic approach. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> How would you implement such a verb elegantly(with which I mean > > >>>>>>>> short)? > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> June > > >>>>>>>> > ------------------------------------------------------------------- > > >>>>>>>> --- 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 > > >>>>>> > > >>>>> > ---------------------------------------------------------------------- > > >>>>> 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 > > >>>>> > > >>>> > > >>>> --- > > >>>> This email has been checked for viruses by Avast antivirus software. > > >>>> https://www.avast.com/antivirus > > >>>> > ---------------------------------------------------------------------- > > >>>> For information about J forums see > http://www.jsoftware.com/forums.htm > > >>>> > > >>> > ---------------------------------------------------------------------- > > >>> For information about J forums see > http://www.jsoftware.com/forums.htm > > >>> > > >> > > >> --- > > >> This email has been checked for viruses by Avast antivirus software. > > >> https://www.avast.com/antivirus > > >> > > >> ---------------------------------------------------------------------- > > >> 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 > > > > > ---------------------------------------------------------------------- > > 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
