> Is this example useful to this discussion. Linda, I'd rather view it the other way round: is this discussion useful to the examination of your example
"This discussion" is a tiny piece of a perennial one in the J forums, best summed-up by Harvey Hahn in: http://www.jsoftware.com/pipermail/programming/2008-May/010710.html It wasn't my intention to reopen it, at least not here. I would have had to write an essay, maybe a book. And I feel I'm not the person best-qualified to do that. But I do spend a lot of time contemplating the problem, and from many angles. I launched this thread in an unguarded moment. I was hoping either to open a new line of enquiry, in this well-worked field, or else put it to bed permanently, properly documented so's I'd never reopen it again just because I'd forgotten the issues surrounding it. The sort of thing I do all too often. I was struck by what I thought was a peculiar property of 5!:6, viz that if you picked a snatch of published tacit code at random and bracketed it using 5!:6, it was highly likely that all the bracketed forms (...) you saw would be verbs. I guessed in general they weren't. And David (Ward Lambert) confirms my guess in an orphaned branch of this thread dated Fri, Jul 20, 2012 at 9:02 PM, saying... > Question 1) 5!:6 can parenthesize trains, nouns, adverbs, and verbs. That should have been the end of the matter. But it didn't discourage me from dreaming of a quick'n'easy "explicate" algorithm, that would handle the bulk of code samples that puzzle a J novice - or could easily be bent to do so. Nevertheless, interesting and important though the wider question is, I feel uneasy about widening my original Question 1 into it, because I think we're picking a tiger up by his whiskers: there are better parts to grab hold of. Such as promoting the benefits of trace.ijs for use in "explication": http://www.jsoftware.com/help/release/trace.htm or appealing for somebody to finish developing tte.ijs: http://www.jsoftware.com/jwiki/Scripts/TacitToExplicit which Ambrus states doesn't handle Hooks. ...Which is, I guess, why ttem doesn't help much with the example you quote: > b=: +:&(%~i.) > b ttem > 3 : '(+:&(%~ i.))y' > This has not unlocked the mystery of the expression. ... But trace.ijs and tte.ijs are both techniques which put probes into a tacit verb and execute it (wholly or partially), to make it apparent where the x's and y's fit themselves in. Why shouldn't I carry on dreaming of a purely symbolic way: an algebraic way? On Sat, Jul 21, 2012 at 7:45 AM, Linda Alvord <[email protected]> wrote: > 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
