Linda, I am going to guess what you will ask next, so I will mention here there is both a monadic and dyadic use of f/ . Please look that up! --Kip
Sent from my iPad On Jan 22, 2013, at 9:09 AM, km <k...@math.uh.edu> wrote: > Linda, the dyadic use of f&g is that x f&g y is (g x) f (g y) . I knew the > dyadic use of f&g would be needed below because the / just before +. means > the verb to the left of the slash will be inserted between the items of the > result of +. . --Kip > > Sent from my iPad > > > On Jan 22, 2013, at 1:46 AM, "Linda Alvord" <lindaalv...@verizon.net> wrote: > >> This is just what I'm looking for! >> >> This is OK >> >> ic4 =: [: , [: ((j./)&i:)/ +. NB. remove @ >> >> What rule are you using here? >> >> ic4 =: [: , [: (i:@[ j./ i:@])/ +. NB. remove & >> >> I would have expected >> >> ic4=:[:,[: ([:(j./)i:)/+. >> >> >> Linda >> >> -----Original Message----- >> From: programming-boun...@forums.jsoftware.com >> [mailto:programming-boun...@forums.jsoftware.com] On Behalinf Of km >> Sent: Tuesday, January 22, 2013 1:56 AM >> To: programm...@jsoftware.com >> Subject: Re: [Jprogramming] [Jprogrammingou Hermitian from triangular >> >> Linda, here I remove conjunctions @ and & from ic2, leading to ic4 not ic. >> Two new @'s creep in but they would be easy to remove! >> >> 9!:3 [ 6 NB. fully parenthesized display >> >> ic2 >> [: , ((((j./)&i:)/)@+.) >> >> ic4 =: [: , [: ((j./)&i:)/ +. NB. remove @ >> >> ic4 =: [: , [: (i:@[ j./ i:@])/ +. NB. remove & >> >> ic4 1j2 >> _1j_2 _1j_1 _1 _1j1 _1j2 0j_2 0j_1 0 0j1 0j2 1j_2 1j_1 1 1j1 1j2 >> >> Kip >> >> Sent from my iPad >> >> >> On Jan 21, 2013, at 9:49 PM, "Linda Alvord" <lindaalv...@verizon.net> wrote: >> >>> It would be most helpful if you would give a sequence of legitimate >>> substitutions which can be made in an orderly fashion to work "backwards" >>> from ic2 to ic . If you could then go from ic to an explicit >>> definition that would be great. >>> >>> I start with an explicit definition to write statements that work on >>> real data. Later it is possible to simplify. When I can't understand >>> a terse expression, I need to "work backwards" to make it >>> understandable. I try to use definitions for @ and @. and & as >>> that makes right to left execution more clear. It is obvious from >>> this example that it becomes Important to include rank somehow. >>> >>> Thanks in advance if you can do this. >>> >>> Linda >>> >>> : Monday, January 21, 2013 10:19 PM >>> To: programm...@jsoftware.como >>> Subject: Re: [Jprogramming] [Jprogrammingou Hermitian from triangular >>> >>> What would be most helpful >>> >>> -----Original Message----- >>> From: programming-boun...@forums.jsoftware.com >>> [mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Dan >>> Bron >>> Sent: Monday, January 21, 2013 2:08 PM >>> To: programm...@jsoftware.com >>> Subject: Re: [Jprogramming] [Jprogrammingou Hermitian from triangular >>> >>> Linda wrote: >>>> ic >>>> [: , ([: i: 9&o.) j./ [: i: 11&o. >>>> ic2 >>>> [: , j./&i:/@+. >>>> f >>>> [: , [: j./&i:/ +. >>>> g >>>> [: j./ [: i: +. >>> >>> It appears to me that as you move from ic2 to f to g, you are simply >>> deleting words (the kind that you don't like). >>> >>> If you go back to the email where ic2 was developed from ic, you'll >>> see that each of the words in ic2 was introduced deliberately, and >>> none of the words is superfluous. In fact, it was the very words you >>> arbitrarily deleted which the email specifically introduced in order >>> to simplify ic to ic2, without losing functionality. So, if you want >>> to remove those words, you must do it carefully. In fact, if you take >>> care to do this properly, and gradually expand the definition of ic2 >>> until it has your preferred, conjunction-free form, the result will be >>> ic! In effect, you'll end up working through the ic->ic2 transformation >> backwards. >>> >>> You can't have it both ways: the ic2 form is simpler and cleaner, but >>> requires you to use conjunctions. The ic form is composed solely of >>> verb trains, but is not as concise, and can't be read left-to-right or >>> executed right-to-left. That was the point of my original post: that >>> conjunctions have their benefits, and perhaps it's worth reconsidering >>> your aversion to them. >>> >>> Anyway, arbitrarily deleting words you don't like is akin to >>> translating a sentence from Chinese to English by transliterating the >>> words you know, and simply ignoring the ones that you don't (or don't >>> have a simple, direct translation). That won't work. >>> >>> And, while it is good that you tested your changes along the way, >>> given the verbs' infinite domain, no amount of tests will ever prove >>> their correctness. As you discovered, it only takes one >>> counterexample to destroy the equivalence. You need to bring some theory >> to the table. >>> >>> Let me give you an example. If you look at ic, Kip's original: >>> >>> 13 : ',(i: 9 o. y) j./ i: 11 o. y' >>> [: , ([: i: 9 o. ]) j./ [: i: 11 o. ] >>> >>> It's quite clear - even just visually - that his j./ has two >>> arguments: one on the left, and one on the right. Whereas, if you look at >> your g: >>> >>> 13 :'j./ i:+.y' >>> [: j./ [: i: +. >>> >>> it's evident that your j./ only has one argument, on the right. So g >>> can't be doing the same thing as ic (or, by implication, ic2). >>> >>> This is the kind of analysis you need to do if you want to simplify J >>> verbs or phrases. You can't just randomly delete words you don't >>> like. But moreover, it may be worth your while to reconsider eschewing >>> these words in the first place. I noticed you picked up on ic2, rather >>> than ic, to use as a basis for your own approach, even though the >>> former is conjunction-rich and the latter conjunction-free. And >>> furthermore, while you deleted the / that followed i:, you retained >>> the / following j. - apparently because you thought it expressed some >> concept clearly. >>> >>> -Dan >>> >>> PS: >>> >>> Linda also wrote: >>>> However, I do not understand how ic and ic2 agree when they don't! >>> >>> In fact, they do. If you want to understand how, then [1] walks >>> through that in some detail. >>> >>> This is despite the observation Raul made earlier: >>> >>>> I will agree that they do not agree [at rank 1 and higher] >>> >>> Which was specifically called out in the original email: >>> >>>> NB. But... >>>> (ic2 -: ic) 1 2 1j2 0j2 >>>> 0 >>>> >>>> NB. When we move beyond the original scope of a single, NB. scalar >>>> input the answers differ. What gives? >>>> NB. Left as an exercise for the reader. >>> >>> And in the follow-ups, e.g. from Kip: >>> >>>> About your closing question, consider >>>> (ic2"0 -: ic"0) 1 2 1j2 0j2 >>>> 1 >>>> >>>> Monadic i: has rank 0 and for reasonable behavior I think ic and ic2 >>>> should be used with rank 0 on vector arguments. >>> >>> [1] Development of ic2 from ic: >>> >>> http://www.jsoftware.com/pipermail/programming/2013-January/031131.htm >>> l >>> >>> >>> ---------------------------------------------------------------------- >>> 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
