Oh, that is clever but not too mysterious. I also went down the path
of trying to get the linear representation of u but got stuck because
5!:5 expects a name. I didn't think to assign a local name.
This was also cool and the piece I was missing to gerundify u
(+: + -:) (1 : '0{:: u`[')
┌─┬─────────┐
│3│┌──┬─┬──┐│
│ ││+:│+│-:││
│ │└──┴─┴──┘│
└─┴─────────┘
Thanks
On Thu, Dec 10, 2015 at 1:35 PM, Raul Miller <rauldmil...@gmail.com> wrote:
> Here's a draft implementation of what I think you mean by a "smart fork":
>
> NB. draft
> sfork=:1 :0
> impl=. 0 {:: u`-
> if. (<,'3')-:{.impl do.
> d=. 5!:1@<
> e=. 5!:0
> '`a b c'=. 1 {:: impl
> (d'a')e@[ (d'b')e (d'c')e@]
> end.
> )
>
> Example use:
> (+-*)sfork
> +@[ - *@]
>
> Hopefully that's not too mysterious?
>
> Basically, it's taking the gerund of its argument (which it assumes is
> a verb or an atomic representation of a verb), and if that represents
> a fork, it's extracting the three verbs from the fork and slapping a
> @[ on the left tine and a @] on the right tine.
>
> Anyways, I've occasionally also itched for something like this. But
> the definition is big enough that I never bother.
>
> Thanks,
>
> --
> Raul
>
>
> On Thu, Dec 10, 2015 at 1:15 PM, Joe Bogner <joebog...@gmail.com> wrote:
>> Interesting. I'm not sure if M is worth it over @] due to potential
>> naming conflicts and ambiguity in the code .@] is very clear
>>
>> It got me thinking that it might be interesting (albeit probably not
>> overly useful) to have a 'smart fork' adverb that could figure out
>> that its arguments are monadic and bind them appropriately
>>
>> This starts to show what I mean
>> fork=:(2 : 'u@[ + v@]')
>>
>> 3 4 (+: fork -:) 2 4
>> 7 10
>>
>> The + would need to be extracted, so it would need to be
>>
>> 3 4 (+: + -:) fork 2 4
>>
>> I don't think that's possible without using gerunds..
>>
>> fork=: (1 :'(0{:: u);''@'';''['';(1&{::u);(2{:: u);''@'';'']''') (1 : 'u
>> `:6')
>>
>> +:`+`-: fork
>> +:@[ + -:@]
>>
>> 3 4 +:`+`-: fork 2 4
>> 7 10
>>
>> fork could be enhanced to detect whether the tines are monadic and
>> only apply the @[ and @] if so
>>
>> not sure how useful it is, but fun to play with
>>
>>
>>
>>
>> On Thu, Dec 10, 2015 at 12:11 PM, 'Pascal Jasmin' via Programming
>> <programm...@jsoftware.com> wrote:
>>> Here is another approach to simplifying J and meeting dyadic J goals
>>> without verb definitions:
>>>
>>> M =: @]
>>>
>>>
>>> 3 4 (+:M~ + -:M) 2 4
>>> 7 10
>>> (+: M~ + -: M) 2 4
>>> 5 10
>>>
>>>
>>>
>>> ~ (swap) basically works like @[ on a monad that is defined to ignore x
>>> rather than return error.
>>>
>>> M or M~ is easier to type than @:] or @:[ too.
>>>
>>>
>>> T =: &{(>@)
>>> NB. double adverb version of @:
>>> at =: 1 : 'u 1 :''2 : ''''u (v@:) '''' u'''
>>>
>>>
>>>
>>>
>>> 3 2 (1 T M~ + 0 1 T M +: at) 2 3 4
>>> 6 8
>>>
>>> ----- Original Message -----
>>> From: Jose Mario Quintana <jose.mario.quint...@gmail.com>
>>> To: Programming forum <programm...@jsoftware.com>
>>> Sent: Thursday, December 3, 2015 11:04 AM
>>> Subject: Re: [Jprogramming] dyadic J
>>>
>>> Pascal wrote:
>>>
>>> "There is a addon called general/primitives that provides shadow names for
>>> everything."
>>>
>>> However, trying to provide a shadow name for $: is futile.
>>>
>>>
>>> Pascal wrote:
>>>
>>> 'A recent point of conversion of mine is that u@:v is both easier to read
>>> and edit/expand and easier to see subresults by cutting out parts of an @
>>> train "s@t@u@v" even if its u@:(v) compared to [: u v.'
>>>
>>> Welcome to a very exclusive club ;)
>>>
>>>
>>> Linda wrote:
>>> "
>>> Pascal and others. I am curious to know if you find tacit code easy to read.
>>>
>>> cr=:([ = [: +/ [: |: #~ #: [: i. ^) #"2 #~ #: [: i. ^
>>> divy=:([: ,. [: <"1 '*' $~ ] ,~ [: <. %) , [: < '*' $~ [ - ] * [: <. %
>>>
>>> Those two tacit lines seem hard to translate for me. Instead I find the
>>> expressions below are quite easy to follow.
>>>
>>> cr=: 13 :'(x= +/ |:(y#x)#:i.x^y) #"2 (y#x)#:i.x^y'
>>> divy=: 13 :'(,.<"1((<.x%y),y)$''*''),<(x-y*<.x%y)$''*'''
>>> "
>>>
>>> I submit that it is a matter of familiarity. Granted, forum members are
>>> likely more familiar with explicit rather than tacit reading and writing
>>> (then again, most programmers are more familiar with one element at a time
>>> as opposed to array processing).
>>>
>>> Personally, armed with the boxed representation of a verb, I can typically
>>> see effortlessly how the data flows given a tacit verb and its
>>> argument(s). This does not surprise me since the interpreter’s
>>> representation of a verb is closely related to the boxed representation (if
>>> I recall correctly).
>>>
>>> Moreover, tacit forms facilitate the manual, or automatic, symbolic
>>> manipulation and simplification of tacit forms. For example,
>>>
>>> cr=:([ = [: +/ [: |: #~ #: [: i. ^) #"2 #~ #: [: i. ^
>>>
>>> cr
>>> ([ = [: +/ [: |: #~ #: [: i. ^) #"2 #~ #: [: i. ^
>>> ┌─────────────────────────────────────────────┬───────┬────────────────────┐
>>> │┌─┬─┬───────────────────────────────────────┐│┌─┬─┬─┐│┌─────┬──┬─────────┐│
>>> ││[│=│┌──┬─────┬────────────────────────────┐│││#│"│2│││┌─┬─┐│#:│┌──┬──┬─┐││
>>> ││ │ ││[:│┌─┬─┐│┌──┬──┬────────────────────┐│││└─┴─┴─┘│││#│~││ ││[:│i.│^│││
>>> ││ │ ││ ││+│/│││[:│|:│┌─────┬──┬─────────┐││││ ││└─┴─┘│ │└──┴──┴─┘││
>>> ││ │ ││ │└─┴─┘││ │ ││┌─┬─┐│#:│┌──┬──┬─┐│││││ │└─────┴──┴─────────┘│
>>> ││ │ ││ │ ││ │ │││#│~││ ││[:│i.│^││││││ │ │
>>> ││ │ ││ │ ││ │ ││└─┴─┘│ │└──┴──┴─┘│││││ │ │
>>> ││ │ ││ │ ││ │ │└─────┴──┴─────────┘││││ │ │
>>> ││ │ ││ │ │└──┴──┴────────────────────┘│││ │ │
>>> ││ │ │└──┴─────┴────────────────────────────┘││ │ │
>>> │└─┴─┴───────────────────────────────────────┘│ │ │
>>> └─────────────────────────────────────────────┴───────┴────────────────────┘
>>>
>>> NB. Regardless of the nature of the arguments...
>>>
>>> NB. Automatically,
>>>
>>> cr f. decap ala NB. Wicked Jx adverbs for decapitating and associating
>>> @:s to the left
>>> ([ = +/@:|:@:(#~ #: i.@:^)) #"2 #~ #: i.@:^
>>> ┌─────────────────────────────────────────────┬───────┬────────────────────┐
>>> │┌─┬─┬───────────────────────────────────────┐│┌─┬─┬─┐│┌─────┬──┬─────────┐│
>>> ││[│=│┌─────────────┬──┬────────────────────┐│││#│"│2│││┌─┬─┐│#:│┌──┬──┬─┐││
>>> ││ │ ││┌─────┬──┬──┐│@:│┌─────┬──┬─────────┐│││└─┴─┴─┘│││#│~││ ││i.│@:│^│││
>>> ││ │ │││┌─┬─┐│@:│|:││ ││┌─┬─┐│#:│┌──┬──┬─┐││││ ││└─┴─┘│ │└──┴──┴─┘││
>>> ││ │ ││││+│/││ │ ││ │││#│~││ ││i.│@:│^│││││ │└─────┴──┴─────────┘│
>>> ││ │ │││└─┴─┘│ │ ││ ││└─┴─┘│ │└──┴──┴─┘││││ │ │
>>> ││ │ ││└─────┴──┴──┘│ │└─────┴──┴─────────┘│││ │ │
>>> ││ │ │└─────────────┴──┴────────────────────┘││ │ │
>>> │└─┴─┴───────────────────────────────────────┘│ │ │
>>> └─────────────────────────────────────────────┴───────┴────────────────────┘
>>>
>>> NB. Manually,
>>>
>>> [ (([ = +/@:|:@:]) #"2 ]) #~ #: i.@:^ NB. Distributing (#~ #: i.@:^)
>>> [ (([ = +/@:|:@:]) #"2 ]) #~ #: i.@:^
>>> ┌─┬──────────────────────────────────────┬────────────────────┐
>>> │[│┌──────────────────────────┬───────┬─┐│┌─────┬──┬─────────┐│
>>> │ ││┌─┬─┬────────────────────┐│┌─┬─┬─┐│]│││┌─┬─┐│#:│┌──┬──┬─┐││
>>> │ │││[│=│┌─────────────┬──┬─┐│││#│"│2││ ││││#│~││ ││i.│@:│^│││
>>> │ │││ │ ││┌─────┬──┬──┐│@:│]│││└─┴─┴─┘│ │││└─┴─┘│ │└──┴──┴─┘││
>>> │ │││ │ │││┌─┬─┐│@:│|:││ │ │││ │ ││└─────┴──┴─────────┘│
>>> │ │││ │ ││││+│/││ │ ││ │ │││ │ ││ │
>>> │ │││ │ │││└─┴─┘│ │ ││ │ │││ │ ││ │
>>> │ │││ │ ││└─────┴──┴──┘│ │ │││ │ ││ │
>>> │ │││ │ │└─────────────┴──┴─┘││ │ ││ │
>>> │ ││└─┴─┴────────────────────┘│ │ ││ │
>>> │ │└──────────────────────────┴───────┴─┘│ │
>>> └─┴──────────────────────────────────────┴────────────────────┘
>>>
>>> [ (( = +/@:|: ) #"2 ]) #~ #: i.@:^ NB. Hook form
>>> [ ((= +/@:|:) #"2 ]) #~ #: i.@:^
>>> ┌─┬─────────────────────────────┬────────────────────┐
>>> │[│┌─────────────────┬───────┬─┐│┌─────┬──┬─────────┐│
>>> │ ││┌─┬─────────────┐│┌─┬─┬─┐│]│││┌─┬─┐│#:│┌──┬──┬─┐││
>>> │ │││=│┌─────┬──┬──┐│││#│"│2││ ││││#│~││ ││i.│@:│^│││
>>> │ │││ ││┌─┬─┐│@:│|:│││└─┴─┴─┘│ │││└─┴─┘│ │└──┴──┴─┘││
>>> │ │││ │││+│/││ │ │││ │ ││└─────┴──┴─────────┘│
>>> │ │││ ││└─┴─┘│ │ │││ │ ││ │
>>> │ │││ │└─────┴──┴──┘││ │ ││ │
>>> │ ││└─┴─────────────┘│ │ ││ │
>>> │ │└─────────────────┴───────┴─┘│ │
>>> └─┴─────────────────────────────┴────────────────────┘
>>>
>>> NB. Given the nature of the arguments...
>>>
>>> [ (( = +/@:|: ) # ]) #~ #: i.@:^ NB. Redundant "2
>>> [ ((= +/@:|:) # ]) #~ #: i.@:^
>>> ┌─┬───────────────────────┬────────────────────┐
>>> │[│┌─────────────────┬─┬─┐│┌─────┬──┬─────────┐│
>>> │ ││┌─┬─────────────┐│#│]│││┌─┬─┐│#:│┌──┬──┬─┐││
>>> │ │││=│┌─────┬──┬──┐││ │ ││││#│~││ ││i.│@:│^│││
>>> │ │││ ││┌─┬─┐│@:│|:│││ │ │││└─┴─┘│ │└──┴──┴─┘││
>>> │ │││ │││+│/││ │ │││ │ ││└─────┴──┴─────────┘│
>>> │ │││ ││└─┴─┘│ │ │││ │ ││ │
>>> │ │││ │└─────┴──┴──┘││ │ ││ │
>>> │ ││└─┴─────────────┘│ │ ││ │
>>> │ │└─────────────────┴─┴─┘│ │
>>> └─┴───────────────────────┴────────────────────┘
>>>
>>> [ (( = +/"1 ) # ]) #~ #: i.@:^ NB. Summing the rows of a matrix
>>> [ ((= +/"1) # ]) #~ #: i.@:^
>>> ┌─┬─────────────────────┬────────────────────┐
>>> │[│┌───────────────┬─┬─┐│┌─────┬──┬─────────┐│
>>> │ ││┌─┬───────────┐│#│]│││┌─┬─┐│#:│┌──┬──┬─┐││
>>> │ │││=│┌─────┬─┬─┐││ │ ││││#│~││ ││i.│@:│^│││
>>> │ │││ ││┌─┬─┐│"│1│││ │ │││└─┴─┘│ │└──┴──┴─┘││
>>> │ │││ │││+│/││ │ │││ │ ││└─────┴──┴─────────┘│
>>> │ │││ ││└─┴─┘│ │ │││ │ ││ │
>>> │ │││ │└─────┴─┴─┘││ │ ││ │
>>> │ ││└─┴───────────┘│ │ ││ │
>>> │ │└───────────────┴─┴─┘│ │
>>> └─┴─────────────────────┴────────────────────┘
>>>
>>> This latter form is the capless counterpart of the version provided by
>>> Lippu Esa.
>>>
>>>
>>>
>>>
>>> On Sat, Nov 28, 2015 at 2:27 AM, Linda A Alvord <lindaalv...@verizon.net>
>>> wrote:
>>>
>>>> Pascal and others. I am curious to know if you find tacit code easy to
>>>> read.
>>>>
>>>> cr=:([ = [: +/ [: |: #~ #: [: i. ^) #"2 #~ #: [: i. ^
>>>> divy=:([: ,. [: <"1 '*' $~ ] ,~ [: <. %) , [: < '*' $~ [ - ] * [: <. %
>>>>
>>>> Those two tacit lines seem hard to translate for me. Instead I find the
>>>> expressions below are quite easy to follow.
>>>>
>>>> cr=: 13 :'(x= +/ |:(y#x)#:i.x^y) #"2 (y#x)#:i.x^y'
>>>> divy=: 13 :'(,.<"1((<.x%y),y)$''*''),<(x-y*<.x%y)$''*'''
>>>>
>>>> In most cases, with examples there is little documentation that is
>>>> necessary.
>>>>
>>>> 2 cr 5
>>>> 0 0 0 1 1
>>>> 0 0 1 0 1
>>>> 0 0 1 1 0
>>>> 0 1 0 0 1
>>>> 0 1 0 1 0
>>>> 0 1 1 0 0
>>>> 1 0 0 0 1
>>>> 1 0 0 1 0
>>>> 1 0 1 0 0
>>>> 1 1 0 0 0
>>>> 18 divy 5
>>>> ------┐
>>>> │*****│
>>>> +-----+
>>>> │*****│
>>>> +-----+
>>>> │*****│
>>>> +-----+
>>>> │*** │
>>>> L------
>>>> Maybe it is just that the explicit code looks like mathematics. It might be
>>>> interesting and useful to hear how programmers and J users read code most
>>>> easily.
>>>>
>>>> Linda
>>>> -----Original Message-----
>>>> From: programming-boun...@forums.jsoftware.com
>>>> [mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Don Kelly
>>>> Sent: Friday, November 27, 2015 10:37 PM
>>>> To: programm...@jsoftware.com
>>>> Subject: Re: [Jprogramming] dyadic J
>>>>
>>>> there is nothing wrong with saying something like plus =: + conjugate =:+
>>>> and knowing that plus is intended to be monadic (although +(real
>>>> number) is the real number in either case. If you want one to work as
>>>> monadic onlyand the other as dyadic only-then you have to dress them up a
>>>> bit with some test and error message.
>>>> you can do mean=: sum divideby count in any language.
>>>> J has 2 meanings for + -which are dependent on the context. English also
>>>> is
>>>> like that in that some words have two unrelated meanings (e.g bow , can,
>>>> twig, butt ) as well as having some with related meanings (e.g rise, level)
>>>> and a lot of other things that depend on context It would be possible to
>>>> build up a long list of names so that all uses of the primitives have
>>>> different names and do just what the names indicate but is that of any more
>>>> than limited use?
>>>>
>>>>
>>>>
>>>> On 11/27/2015 1:08 PM, 'Pascal Jasmin' via Programming wrote:
>>>> > Are you saying that if I define
>>>> >
>>>> > floor =: (<. : (<.@]))"0 _ 0
>>>> >
>>>> > that it does not have integrated rank support?
>>>> >
>>>> > The criticism about english and documentation seems hollow to me. I
>>>> don't
>>>> say that Nuvoc is useless because it hasn't been implemented in 150
>>>> languages. An ability to read the dictionary in English is essential to
>>>> learn J, and code typically uses english shaddows from profile.ijs. Making
>>>> foreign language cover verbs including autotranslating the english ones is
>>>> straightforward, and answers that part of the criticism. Using the exact
>>>> names from the dictionary (what I'm refering to as autodocumentation
>>>> because
>>>> the exact same place you would look up i. is where iota will be explained.)
>>>> seems like an elegant way to ease a shallow learning curve on the process.
>>>> >
>>>> > The entire criticism could be applied to "you should never assign a verb
>>>> to any name"
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > ----- Original Message -----
>>>> > From: Raul Miller <rauldmil...@gmail.com>
>>>> > To: Programming forum <programm...@jsoftware.com>
>>>> > Sent: Friday, November 27, 2015 3:27 PM
>>>> > Subject: Re: [Jprogramming] dyadic J
>>>> >
>>>> > On Thu, Nov 26, 2015 at 4:12 PM, 'Pascal Jasmin' via Programming
>>>> > <programm...@jsoftware.com> wrote:
>>>> >> The only disadvantage I recognize is the point about special code.
>>>> > It would be interesting to go over the reasons you do not recognize
>>>> > the other disadvantages.
>>>> >
>>>> >> As to your other points, because the primitives are tacit, I believe
>>>> there is integrated rank support.
>>>> >>
>>>> >> floor b. 0
>>>> >> 0 _ _
>>>> > You might want to read
>>>> > http://www.jsoftware.com/pipermail/general/1998-October/000041.html
>>>> >
>>>> > All verbs have rank support, even verbs which contain explicit
>>>> > definitions. However, for some combinations of primitives, the
>>>> > interpreter takes special steps - bypassing the default implementation
>>>> > of rank support with something more efficient.
>>>> >
>>>> >> English is needed to read dictionary, and all of the primitives are the
>>>> monad dictionary entries, so everything is autodocumented.
>>>> > In my experience, documentation is difficult and autodocumentation
>>>> > quickly falls victim to entropy. It sounds great, but most examples I
>>>> > have seen become incredibly useless in practice. It's possible to work
>>>> > around this with manual effort, but the effort involved often seems to
>>>> > be greater than the effort of simply doing it manually in the first
>>>> > place. Where automation shines is replicating the useful manual
>>>> > efforts.
>>>> >
>>>> >> The advantage bigger than the one you mentioned is better seeing the
>>>> intent of code.
>>>> > Agreed.
>>>> >
>>>> > Thanks,
>>>> >
>>>>
>>>> ----------------------------------------------------------------------
>>>> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
