Your humble implementer tries to be thorough, but sometimes luck out
without being very thorough or being all that clever.
In the interpreter, there is a typedef A which is the array type, and:
A f(A y){...} // monad
A f(A x,A y){...} // dyad
If there is special code for phrases of the form f~, typically what it does is:
#define R return
A grade2(A x,A y){if(x==y)R sort(y); ...}
A sort(A y){...}
A indexof(A x,A y){
if(x==y){
// special code for indexof-self
}
...
}
In other words, the interpreter checks that the left and right
arguments are the same not by doing an expensive match (-:) but by
comparing C pointers, a very fast operation. Therefore, you should be
able to code the grade/sort in various ways, /:~ or /:~ : /: or x/:x
or ..., and still be able to take advantage of the special code for
sort. (Indeed, it's hard to avoid it!)
Having said that, I checked the J source to confirm that that's what it does.
Timings:
x=: 1e6 ?@$ 0
timer=: 6!:2
10 timer '/:~~x'
0.139437
10 timer '/:~x'
0.139534
10 timer '(/:~ : /:) x'
0.139256
10 timer 'x/:x'
0.148128
These are essentially the same times. In contrast:
y=: 0+x
10 timer 'x/:y'
0.4622
So even though x and y are the same, because x and y are different
arrays internally the x==y check in C is false, and the special code
is not invoked.
Sorting is faster than grading.
http://www.jsoftware.com/jwiki/Essays/Sorting%20versus%20Grading
2011/10/29 Henry Rich <[email protected]>:
> It is true, as I said, that /:~~ produces the same result as /:~ :/: but
> it might not perform the same. The monad /:~ is backed by special code,
> but when you execute /:~~ you are not executing that monad. Unless
> Roger was being unusually thorough, /:~~ would go through dyad /: which
> is a different algorithm. You'd have to check timings to see.
>
> Since what you are executing here is always a monad, /:~ is preferable.
>
> Henry Rich
>
> On 10/29/2011 5:00 AM, Linda Alvord wrote:
>> This helped me with this problem, but I still want write a n b as Roger
>> suggested. I do not have any idea what the author had in mind for a monadic
>> version so I'll save monad/dyad : for a later problem.
>>
>> m=: 13 : '/:~ :/:@":&.>y'
>> ------T-----┐
>> │01123│01123│
>> L-----+------
>> mm=: 13 : '(/:~ :/:)@":&.>y' NB. Here is where I started wrong (/:@":&.>)
>>
>> mm a,b
>> ------T-----┐
>> │01123│01123│
>> L-----+------
>> mmm=: 13 : '(/:~~)@":&.>y'
>> mmm a,b
>> ------T-----┐
>> │01123│01123│
>> L-----+------
>> mmmm a,b
>> ------T-----┐
>> │01123│01123│
>> L-----+------
>> m
>> /:~ :/:@":&.>
>> mm
>> /:~ :/:@":&.>
>> mmm
>> /:~~@":&.>
>> mmmm
>> ([: /:~~ ":)&.>
>>
>> 5!:4<'mmmm'
>>
>> -- [:
>> ----+- ~ --- ~ --- /:
>> -- &. -+ L- ":
>> L->
>>
>> Thanks, you got me off the wrong track.
>>
>> Linda
>>
>>
>>
>>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Henry Rich
>> Sent: Thursday, October 27, 2011 4:35 PM
>> To: Programming forum
>> Subject: Re: [Jprogramming] problem with under
>>
>> I just noticed that
>>
>> /:~ : /:
>>
>> can replaced by
>>
>> /:~~
>>
>> bivalently.
>>
>> Henry Rich
>>
>> On 10/27/2011 4:03 PM, Kip Murray wrote:
>>> I like especially your second form I =: ([:< [: /: ":)"0
>>>
>>> For the third form I =:< @ /: @ ": " 0 note that [: f g and f @: g are
>>> always equivalent, but f @: g and f @ g are not when g has rank 0 --
>>> conjunction @: always uses sequential processing, but conjunction @ uses
>>> parallel processing when g has rank 0, as shown below.
>>>
>>>
>>> (+/ @: *:) 3 4
>>> 25
>>>
>>> (+/ @ *:) 3 4
>>> 9 16
>>>
>>>
>>> In the first case above the right to left flow chart is
>>>
>>> 25<-- +/<-- 9 16<-- *:<-- 3 4 (sequential processing)
>>>
>>> while in the case involving @ the flow chart is
>>>
>>> <-- 9<-- *:<-- 3
>>> 9 16<-- +/ (parallel processing because *: is rank 0)
>>> <-- 16<-- *:<-- 4
>>>
>>>
>>> As I nearly always want sequential processing I use
>>>
>>> [: f [: g h (read "the f the g h")
>>>
>>> or
>>>
>>> f @: g @: h (read math's "f o g o h")
>>>
>>>
>>> Check:
>>>
>>> ([: +/ *:) 3 4
>>> 25
>>>
>>>
>>> On 10/27/2011 5:21 AM, Raul Miller wrote:
>>>> Also, for the domain in question, we are not using> for anything but
>> its rank.
>>>>
>>>> Thus we could simplify:
>>>>
>>>> I =: ([:< [: /: [: ": ])"0
>>>>
>>>> Also, since we are always using this as a monad, we could further
>> simplify:
>>>>
>>>>
>>>> I =: ([:< [: /: ":)"0
>>>>
>>>> Though, personally, I find myself comfortable using @
>>>>
>>>> I =:<@/:@":"0
>>>>
>>>> Or, going back to the original message, and applying @ to achieve what
>>>> the dictionary was talking about:
>>>>
>>>> <@([: /: ":)@>a,b
>>>>
>>>> Or, using "0 to replace @>
>>>>
>>>> <@([: /: ":)"0 a,b
>>>>
>>>> But if you are using trains in boxes, maybe it's better to state that
>>>> explicitly, and that could also get rid of any of the @ conjunctions:
>>>>
>>>> ([: /: ":) L:0<"0 a,b
>>>>
>>>> That said, when you replace a shorter expression with a longer one, I
>>>> think you should expect the longer one to lose some of the grace of
>>>> the original.
>>>>
>>>> I hope this helps.
>>>>
>>> ----------------------------------------------------------------------
>>> 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
