Merging independently evolved code generally requires some care, thought, effort and testing (especially corner cases). One of the risks, for example, is that errors in one implementation will be propagated to the other, leaving people without any workaround. Another is lurking "moving parts".
Those error modes are probably not an issue here, but it's something to keep in mind. FYI, -- Raul 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
