Linda asked:So how do you write an explicit definition for jr=:_1^+:&(%~i.) ? Answer:
PoU=: 13 : '_1^+:y' NB. y'th Power of Unity = 2y'th power of minus one jr=: 13 : 'PoU(i.y)%y' NB. y y'th roots of unity - Bo >________________________________ > Fra: Linda Alvord <[email protected]> >Til: [email protected] >Sendt: 8:45 lørdag den 21. juli 2012 >Emne: Re: [Jprogramming] fully parenthesized representation of a tacit verb > >On 7/19/2012 Bo Jacoby wrote this example for complex roots which I call jr: > >Is this example useful to this discussion. > > (_1^+:&(%~i.))4 >1 0j1 _1 0j_1 > jr=:_1^+:&(%~i.) > jr 4 >1 0j1 _1 0j_1 > > jr ttem >3 : 0 >q0=. (+:&(%~ i.))y >(_1) ^ q0 >) > jr >_1 ^ +:&(%~ i.) > > a=:%~ i. > a ttem >3 : '(%~ i.)y' > > b=: +:&(%~i.) > b ttem >3 : '(+:&(%~ i.))y' > >This has not unlocked the mystery of the expression. On 7/18/2012, I used >your function to unlock a different definition for the complex roots iroots >which I later thought should be called jroots: > > iroots=:[: ,. _1 ^ [: +: i. % ] > iroots ttem >3 : 0 >t0=. i. y >s0=. +: t0 % y >,. (_1) ^ s0 >) > iroots=: 13 :',._1^+:(i.y)%y' > iroots 4 > 1 >0j1 > _1 >0j_1 > >So how do you write an explicit definition for jr=:_1^+:&(%~i.) ? > >Is this an example that would explain what you are looking for to Raul? >Or, am I misunderstanding the essence of your discussion? > >Linda > >On 7/18/2012 I had successfully uses ttem to unlock the tacit definition for >the same roots which I had called iroots, but later thought they should be >called jroots. > >Linda > > >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On Behalf Of Ian Clark >Sent: Friday, July 20, 2012 11:45 PM >To: [email protected] >Subject: Re: [Jprogramming] fully parenthesized representation of a tacit >verb > >I accept what you are saying, and these are interesting points to discuss. >But they take me outside my current focus. Viz the question I touched on in >another thread: to take an explicit definition like: 4 : >'x foo y' (where foo is an arbitrary tacit definition) and distribute the >x's and y's throughout the nested structure of foo. > >To take an example for the benefit of pragmatists trying to follow this >thread, I'm not asking for a whole BNF grammar but a simple pragmatic set of >transformation rules to convert, say: > 4 : 'x (a b c d) y' >into, say: > 4 : 'x a ((b y) c (d y))' >which I loosely called "multiplying out". > >It's not an arid theoretical problem. IMO it's the problem every novice has >to solve when trying to understand published samples of tacit code. > >A lot of people, I find, have had independent stabs at this problem in its >multifarious forms, with loads of overlap, and I thought I'd build a roadmap >to the relevant pages in jwiki. But every approach I've come across so far, >including ones I've experimented with myself, ask J to execute, in whole or >part, the literal string: > 'x foo y' >for example: > 'x (a (b c d)) y' >in order to return either nouns or verbs. > >Is it really necessary to do that, for a 95% good-enough algorithm? >I'm not convinced. Not yet. But even if it turns out it is, I still hope to >sidestep the resource issues of handling substrings of foo >like: > '(i. 10#10)' >which gives limit error when executed, even when J is only being asked to >return foo as a tacit verb. > >As you so rightly say, papers in "Logic & Foundations", which I take to >include the formal proof literature, seldom consider resource limitations. >The question asked is: will the Turing Machine ever stop, not when will it >stop. But I suspect a 95% good-enough algorithm won't become 100%, or even >96%, by expending much effort in this direction. >To my mind, a good-enough algorithm knows when to cop-out. > > >On Fri, Jul 20, 2012 at 9:30 PM, Raul Miller <[email protected]> wrote: >> On Fri, Jul 20, 2012 at 4:02 PM, Ian Clark <[email protected]> wrote: >>> Thanks, Raul. >>>>> 2. If baa is not a verb, how can I determine its type? >>>>> -short of actually assigning it to a local name: baa=. (...) >>>>> and calling 4!:0<'baa' ? >>>> >>>> What's wrong with that? >>> >>> What indeed? -- for the overwhelming majority of cases. If it turns >>> into an impossibly large noun, then just too bad. >> >> In this context, you are dealing with a representation of some element >> which must already exist. So "impossibly large" probably implies a >> bug. >> >> Meanwhile, the formal proof systems that I have looked at routinely >> ignore resource limits in their proofs. >> >>> I was trying to get right away from physically constructing (baa) >>> each time. My original approach had me doing just that, covering each >>> verb I found, running the tooled-up expression with test data and >>> looking to see if each (baa) was called monadically or dyadically, >>> and with what argument(s). If the algorithm runs to completion in >>> reasonable time, it's cast-iron. >>> >>> But, trained as an algebraist, I wondered if a useful subset of J >>> syntax (without copulas, and confined to verb trains) could be >>> reduced to a formal axiomatic system and handled by substitution >>> rules: like a semigroup presentation. >>> >>> At the time I guessed not - and your answer to my question 3 >>> reinforces that view: that J is "implementation defined" (like every >>> other programming language I know, with the possible exception of >>> Prolog) and therefore not (in the general case) amenable to algebraic >>> manipulation... >>> http://www.jsoftware.com/jwiki/Guides/Language%20FAQ/J%20BNF >>> more-or-less says as much. >> >> The issue here, from my point of view, is completeness. J's tools are >> implemented in J, so J needs some open ended features or it could not >> support J. >> >> If you do not care about supporting such "recursive toolbuilding", you >> can draw the line wherever you want and work with a subset which you >> support and declare the rest as "out of scope". >> >> For example, if I wanted to implement some BNF version of J, I would >> pick a single result type to support, for each built in adverb and >> conjunction (probably verb for : and noun for `) and ignore the other >> possibilities. This would prevent me from even having to consider >> explicit adverbs and conjunctions, which makes BNF easy (though I >> would still need to check name class when dealing with names). >> >> -- >> Raul >> ---------------------------------------------------------------------- >> 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
