From general-request@jsoftware.com Fri Sep 15 10:34:03 2006 Date: Fri, 15 Sep 2006 08:39:32 +0800 (HKT) From: general-request@jsoftware.com Reply-To: general@jsoftware.com To: general@jsoftware.com Subject: General Digest, Vol 12, Issue 9 Send General mailing list submissions to general@jsoftware.com To subscribe or unsubscribe via the World Wide Web, visit http://www.jsoftware.com/cgi-bin/mailman/listinfo/general or, via email, send a message with subject or body 'help' to general-request@jsoftware.com You can reach the person managing the list at general-owner@jsoftware.com When replying, please edit your Subject line so it is more specific than "Re: Contents of General digest..." Today's Topics: 1. RE: suggested sugar [. ...previous evaluation (Miller, Raul D) 2. RE: suggested sugar [. ...previous evaluation (Pascal Jasmin) 3. RE: suggested sugar [. ...previous evaluation (Miller, Raul D) 4. RE: suggested sugar [. ...previous evaluation (Pascal Jasmin) 5. Re: Redefining dyadic / (Roger Hui) 6. Common Extensible J Libraries, Was: suggested sugar [. ...previous evaluation (Oleg Kobchenko) 7. Re: Common Extensible J Libraries, Was: suggested sugar [. ...previous evaluation (Oleg Kobchenko) ---------------------------------------------------------------------- Message: 1 Date: Thu, 14 Sep 2006 13:21:08 -0400 From: "Miller, Raul D" Subject: RE: [Jgeneral] suggested sugar [. ...previous evaluation To: "General forum" Message-ID: Content-Type: text/plain; charset="us-ascii" Pascal Jasmin wrote: Sent: Wednesday, September 13, 2006 10:54 AM > languages (Forth). I'm not particularly familiar with > these, but if a monad solution is adopted, > [. 1 -- previous evaluation > [. 2 -- line before that > [. 1 2 -- boxed pair of last 2 evaluations? > [. 0 -- some kind of self reference, i'm unsure is > needed... and if not, could refer to previous line, > and simplify the simplest multiresult uses. This would seem to lead to a variety of subtle bugs. For example, different people should have different intuitions about what the following would produce: a=:2 f=: 'a=:a+y' f 3 [. 1 [. 1 One approach is "previous evaluation" means that J stores the result of each line it executes. This would rapidly lead to out of memory conditions for people working with large data sets. Another approach is that "previous evaluation" means that the previous expression is recorded and executed. The obvious implementation of this results in a stack full error for the second [. 1 Another approach would be to special case recursion on [., where the offset is adjusted in each recursion. This probably does what you "really want", and in this case the results of the above would be 5 8 11 However, this becomes hard to understand, and does not result in the creation of a re-usable expression. In my experience, when I've got several screens of evaluations going, I sometimes have introduced an error and I have to go back and do things over again to see where I've gone wrong. This does not happen for simple cases but does happen for complex cases. I don't see how I could accomplish this if my session was littered with [. n expressions. The only times you [. would produce something re-usable are the cases where it's not doing anything useful. As an aside, it seems like it should be possible to find the function which handles ctrl shift uparrow, and bind it to another key, but I have not been able to find it. -- Raul ------------------------------ Message: 2 Date: Thu, 14 Sep 2006 14:04:27 -0400 (EDT) From: Pascal Jasmin Subject: RE: [Jgeneral] suggested sugar [. ...previous evaluation To: General forum Message-ID: <20060914180427.45191.qmail@web50309.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 > This probably does what you "really want", and in > this > case the results of the above would be > 5 > 8 > 11 Actually, what I'd really want is 5 5 5 You're right, the most logical implementation involves caching the last result(s). Caching only a single result would provide 99%+ of the usefulness, and minimize the length of time data need held in memory cached, but in a world where 1GB of RAM is common, extended caching could be well within resources of many. I'd assume the last result is already cached, since it is needed for return values, in which case, ignore my 3rd paragraph here. Another benefit of caching the result rather than providing a shorthand for inserting the last expression at the cursor is whenever the intermediate results take less than instant computation time. It would let you keep your sanity checks without recalculating everything. Another possible implementation is as yet another potential plugin into a preprocessor engine. There is a straightforward code substitution equivalent from the multiline version to a single line version, that can be used when not in debug mode. Because the intermediate values are never the last line in a script, they can be optimized away (theoretically). --- "Miller, Raul D" wrote: > Pascal Jasmin wrote: > Sent: Wednesday, September 13, 2006 10:54 AM > > languages (Forth). I'm not particularly familiar > with > > these, but if a monad solution is adopted, > > [. 1 -- previous evaluation > > [. 2 -- line before that > > [. 1 2 -- boxed pair of last 2 evaluations? > > [. 0 -- some kind of self reference, i'm unsure is > > needed... and if not, could refer to previous > line, > > and simplify the simplest multiresult uses. > > This would seem to lead to a variety of subtle bugs. > > For example, different people should have > different intuitions about what the following > would produce: > a=:2 > f=: 'a=:a+y' > f 3 > [. 1 > [. 1 > > One approach is "previous evaluation" means that > J stores the result of each line it executes. This > would rapidly lead to out of memory conditions for > people working with large data sets. > > Another approach is that "previous evaluation" means > that the previous expression is recorded and > executed. > The obvious implementation of this results in a > stack > full error for the second [. 1 > > Another approach would be to special case recursion > on [., where the offset is adjusted in each > recursion. > This probably does what you "really want", and in > this > case the results of the above would be > 5 > 8 > 11 > > However, this becomes hard to understand, and does > not result in the creation of a re-usable > expression. > > In my experience, when I've got several screens of > evaluations going, I sometimes have introduced an > error > and I have to go back and do things over again to > see > where I've gone wrong. This does not happen for > simple > cases but does happen for complex cases. I don't > see > how I could accomplish this if my session was > littered > with [. n expressions. The only times you [. would > produce something re-usable are the cases where it's > not doing anything useful. > > As an aside, it seems like it should be possible to > find the function which handles ctrl shift uparrow, > and bind it to another key, but I have not been > able to find it. > > -- > Raul > > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------ Message: 3 Date: Thu, 14 Sep 2006 15:42:25 -0400 From: "Miller, Raul D" Subject: RE: [Jgeneral] suggested sugar [. ...previous evaluation To: "General forum" Message-ID: Content-Type: text/plain; charset="us-ascii" Pascal Jasmin wrote: > Caching only a single result would provide 99%+ > of the usefulness, and minimize the length of > time data need held in memory cached You could approximate this by defining: a=:3 :'A=:y' then a i. 3 0 1 2 a +/~A 0 1 2 1 2 3 2 3 4 a +/,A 18 If you wanted to archive further results you could extend a. For example A=:B=:C=:D=:E=:i.0 0 a=:3 :'A=:y[B=:A[C=:B[D=:C[E=:D' (Or, you could maintain a boxed list of results. Or, you could use 3!:1 and write the results to file. Or, ...) -- Raul ------------------------------ Message: 4 Date: Thu, 14 Sep 2006 17:24:23 -0400 (EDT) From: Pascal Jasmin Subject: RE: [Jgeneral] suggested sugar [. ...previous evaluation To: General forum Message-ID: <20060914212423.33377.qmail@web50314.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Its an excellent solution. After all, tracking nouns is the primary benefit. I'd nominate the following verb for inclusion in stdlib, or maybe just in introduction books up=: 3 :'UP=:y' --- "Miller, Raul D" wrote: > Pascal Jasmin wrote: > > Caching only a single result would provide 99%+ > > of the usefulness, and minimize the length of > > time data need held in memory cached > > You could approximate this by defining: > > a=:3 :'A=:y' > > then > a i. 3 > 0 1 2 > a +/~A > 0 1 2 > 1 2 3 > 2 3 4 > a +/,A > 18 > > If you wanted to archive further results > you could extend a. For example > > A=:B=:C=:D=:E=:i.0 0 > a=:3 :'A=:y[B=:A[C=:B[D=:C[E=:D' > > (Or, you could maintain a boxed list of > results. Or, you could use 3!:1 and write > the results to file. Or, ...) > > -- > Raul > > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------ Message: 5 Date: Thu, 14 Sep 2006 15:47:46 -0700 From: Roger Hui Subject: Re: [Jgeneral] Redefining dyadic / To: General forum Message-ID: <8f84a68fdd2a.8fdd2a8f84a6@shaw.ca> Content-Type: text/plain; charset=us-ascii a. The fact that a primitive can be readily defined in terms of others is not a strong reason for excluding it. The dyad - (equivalent to (+ -)"0) is an example of this. b. Whatever the merits of the new facility, nearly all the merits would still be present if it is assigned a new symbol, without disrupting anything. c. Control structures can not be satisfactorily replaced by tacit constructs. For example: z=. z0 for_i. i.n do. a0=. read i a1=. i{boo a2=. i{coo z=. z f1 a0 f2 a1 f3 a2 end. The blocks within a control structure can refer to too many names than can coexist felicitously in a tacit construct. d. The difference in performance between the following two constructs for_e. g do. c=. (<./i) (i=. {&c^:_ >e)}c end. c=. (({~^:_ )~ ([:<./{)`[`]} ])&.>/ (|.g), @ ({&.>/) @ (] , <@[) f1=: 4 : 0 z=. x for_e. |.y do. z=. (>e){z end. ) y=: 10 ?&.> 5e4$10 x (f0 -: f1) y 1 ts 'x f0 y' 0.0617705 468416 ts 'x f1 y' 0.196699 265536 In other words, even if ds were primitive, the performance on c (({~^:_)~ ([:<./{)`[`]} ])&.> ds g would be similar to c=. (({~^:_ )~ ([:<./{)`[`]} ])&.>/ (|.g),e)}c end. ----- Original Message ----- From: "R.E. Boss" Date: Thursday, September 14, 2006 6:53 am Subject: [Jgeneral] Redefining dyadic / > There are good reasons to redefine the dyadic adverb / called > "table" in the > vocabulary, and one reason not to do so. > > 0) One of the aims of an array programming language should be > to make > explicit loops (for, while) superfluous. Or at least avoidable at > no cost. > > 1) The current definition of u/ is only a shorthand for > u"(lu,_) > > 2) It is preferable that monadic and dyadic use of primitives > match as > much as possible > > 3) There exists a good candidate for dyadic / > > _1) Incompatibility > > Some remarks > > 1) There are cases in which explicit loops are unavoidable > if good > performance is important. > > Even(?) Hui used a for-loop in a recent verb > http://www.jsoftware.com/pipermail/programming/2006- > September/003258.html > > If I replace in his verb comp the line > > for_e. g do. c=. (<./i) (i=. {&c^:_ >e)}c end. > > with the equivalent > > c=. (({~^:_ )~ ([:<./{)`[`]} ])&.>/ (|.g), > to obtain verb comp1, than I get (for e=: edgs~ 5e4) a far worse > performance > ts 'comp e' > 0.45996326 7448832 > > ts 'comp1 e' > 2.6279606 7448896 > > (comp -: comp1) e > 1 > > 2) More primitives are shorthand for complicated expressions, > e.g. /. > is equivalent to 1 : 'u.@#~ =' > > See http://www.jsoftware.com/jwiki/PrimitivePrimitives for other > examples. > But u"(lu,_) is not complicated (enough) for a shorthand. > > What's more, the title (table) does not even reflect its outcome. > > Try 1 2 3 ;/ 4 5 6 7 as one of the problems I encountered when my > J learning > curve was a quite bit steeper than today. Of course 1 2 3 ;"0/ 4 > 5 6 7 > gives the desired outcome, but if you know that, than you also can > come up > with the equivalent 1 2 3 ;"0"0 _ [ 4 5 6 7 > > 3) There are many examples, < and > belonging to the best, where > monadic and dyadic use have nothing in common. But if they do, it > is at > least of mnemonic use. > > 4) The good candidate I am proposing is just the 'for'-loop > Hui used. > > So I would like to have > > x u/ y > > to be defined by " apply u/ on the concatenation of x and y" > > or, more formally, equivalent to > > ds=: 1 : 0 NB. dyadic scan > : > for_j. |.x do. y=. j u y end. > ) > > Then performance can be further improved by special coding ...! > > _1) No remarks on incompatibility. ------------------------------ Message: 6 Date: Thu, 14 Sep 2006 17:18:44 -0700 (PDT) From: Oleg Kobchenko Subject: [Jgeneral] Common Extensible J Libraries, Was: suggested sugar [. ...previous evaluation To: General forum Message-ID: <20060915001844.42616.qmail@web50308.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 > verb for inclusion in stdlib, ... Good candidate. But I suggest instead of tweaking stdlib, we could maintain an effort for new common library(ies). Earlier it was discussed to having more intuitive string manipulation primitives, such as "substr". There are functions which are redefined too often, such as "ts". Some functions are also redefined too often, but they are already in a library, so it's a problem of visibility, e.g. "comb" from "stats". There is also "Scripts" and "Phrases"/"J Pharases" section in J Wiki. But they are all disconnected and not readily available for immediate use. I am thinking of something extensible and growing, yet closely available, like Perl modules or LaTeX packages. With the ability of easily updating/loading from the Web. Hence, CJAN or JEAR, JEAL (extension and application repository / library) eventually(?) See also * [Jgeneral] comb and other common functions http://www.jsoftware.com/pipermail/general/2006-August/027728.html * [Jprogramming] substr phrase http://www.jsoftware.com/pipermail/programming/2006-July/002858.html --- Pascal Jasmin wrote: > Its an excellent solution. After all, tracking nouns > is the primary benefit. I'd nominate the following > verb for inclusion in stdlib, or maybe just in > introduction books > > up=: 3 :'UP=:y' > > --- "Miller, Raul D" wrote: > > > Pascal Jasmin wrote: > > > Caching only a single result would provide 99%+ > > > of the usefulness, and minimize the length of > > > time data need held in memory cached > > > > You could approximate this by defining: > > > > a=:3 :'A=:y' > > > > then > > a i. 3 > > 0 1 2 > > a +/~A > > 0 1 2 > > 1 2 3 > > 2 3 4 > > a +/,A > > 18 > > > > If you wanted to archive further results > > you could extend a. For example > > > > A=:B=:C=:D=:E=:i.0 0 > > a=:3 :'A=:y[B=:A[C=:B[D=:C[E=:D' > > > > (Or, you could maintain a boxed list of > > results. Or, you could use 3!:1 and write > > the results to file. Or, ...) > > > > -- > > Raul __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------ Message: 7 Date: Thu, 14 Sep 2006 17:47:09 -0700 (PDT) From: Oleg Kobchenko Subject: Re: [Jgeneral] Common Extensible J Libraries, Was: suggested sugar [. ...previous evaluation To: General forum Message-ID: <20060915004709.49845.qmail@web50301.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Here's another provoking thought. Suppose, "JRAN" is located in the SVN folders. These folders are mapped to the actual J subtree on your disk, e.g. j/contrib or so. Then some of the SVN API is exposed through a J library, e.g. rsync (for remove sync); or lcheckin, lupdate, ldiff, lmerge, rload, etc. Possibly using GUI or external differs. As a result, from J session, right at the fingertips, you get instant availability of the most recent updates from the libraries. Conversely, if you contribute to a library, you can check-in right from J, and your changes are instantly globaly available. Possible question: how to handle builds, something that (continous) integration systems do. But for J this could be simplified with zero build approach: all code should work as is, as in ASP/PHP/scripting web application. That's also true for python: it does compile on demand in place, as in MoinMoin wiki. However, there should be some handling of different J versions. Possibly different branches of "contrib". --- Oleg Kobchenko wrote: > > verb for inclusion in stdlib, ... > > Good candidate. But I suggest instead of > tweaking stdlib, we could maintain an effort > for new common library(ies). Earlier it was > discussed to having more intuitive string manipulation > primitives, such as "substr". > > There are functions which are redefined > too often, such as "ts". > > Some functions are also redefined too often, > but they are already in a library, so it's a > problem of visibility, e.g. "comb" from "stats". > > There is also "Scripts" and "Phrases"/"J Pharases" > section in J Wiki. But they are all disconnected > and not readily available for immediate use. > > I am thinking of something extensible and growing, > yet closely available, like Perl modules or > LaTeX packages. With the ability of easily > updating/loading from the Web. > > Hence, CJAN or JEAR, JEAL (extension and application > repository / library) eventually(?) > > > See also > > * [Jgeneral] comb and other common functions > http://www.jsoftware.com/pipermail/general/2006-August/027728.html > > * [Jprogramming] substr phrase > http://www.jsoftware.com/pipermail/programming/2006-July/002858.html > > > --- Pascal Jasmin wrote: > > > Its an excellent solution. After all, tracking nouns > > is the primary benefit. I'd nominate the following > > verb for inclusion in stdlib, or maybe just in > > introduction books > > > > up=: 3 :'UP=:y' > > > > --- "Miller, Raul D" wrote: > > > > > Pascal Jasmin wrote: > > > > Caching only a single result would provide 99%+ > > > > of the usefulness, and minimize the length of > > > > time data need held in memory cached > > > > > > You could approximate this by defining: > > > > > > a=:3 :'A=:y' > > > > > > then > > > a i. 3 > > > 0 1 2 > > > a +/~A > > > 0 1 2 > > > 1 2 3 > > > 2 3 4 > > > a +/,A > > > 18 > > > > > > If you wanted to archive further results > > > you could extend a. For example > > > > > > A=:B=:C=:D=:E=:i.0 0 > > > a=:3 :'A=:y[B=:A[C=:B[D=:C[E=:D' > > > > > > (Or, you could maintain a boxed list of > > > results. Or, you could use 3!:1 and write > > > the results to file. Or, ...) > > > > > > -- > > > Raul > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------ ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm End of General Digest, Vol 12, Issue 9 **************************************