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
