|
»
Limit limitation
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Limit limitation
by Dan Bron
::
Rate this Message:
I'm seeking a stylish workaround to the a constraint on applications of
^:_ . The idiom ^:_ is well designed and well documented. It is one of the most useful tools in the J kit and has broad applicability. However, there are some cases where it's almost, but not quite, applicable. Consider the form f^:g^:_ where g is a conditional which determines if f is to be applied (again). Of course if g returns 0, then f isn't applied, and f^:g becomes an identity function, which means its output will match its input, and ^:_ will terminate. So usually ^:g^:_ acts as a while loop, independent of the operation of f, terminating iff g is 0. But now consider an f that is not one-to-one. That is, an f where two or more distinct inputs may produce identical outputs. Using this f in f^:g^:_ becomes problematic. If f receives two inputs in a row which map to the same output, then the loop will terminate early (that is, even if g is 1). Here's a recent example. I'm trying to code the "evoluationary algorithm" from RC http://rosettacode.org/wiki/Evolutionary_algorithm . The code I have so far reads [1]: CHARS =: ' ABCDEFGHIJKLMNOPQRSTUVWXYZ' randomize =: fivePct`mutation} fivePct =: 0.05 >: $ ?@$ 0: mutation =: (UCALPHA,' ')&(] ,: [ {~ $@] ?@$ #@[) score =: +/@:~:"1 copy100 =: 100 $ ,: done =: 1 - -: initial =: CHARS ([ {~ ?@$&#~ ) [ f =: ([ (] {~ (i. <./)@:score) randomize@:copy100@:]) (f^:done^:_: initial) 'METHINKS IT IS LIKE A WEASEL' The problem I'm hitting is that f here isn't deterministic. It takes a "parent", generates a random population, and selects the fittest member of that population -- which could legitimately be the original parent. Hence input and output are identical and f^:done^:_: terminates "early". What is I want is for f^:done^:_: to terminate iff done is true (that is, 'METHINKS IT IS LIKE A WEASEL' -: y ). Now, I understand that ^:_ is doing the right thing. I just want it to do a slightly different thing, and I'm asking for elegant ways to achieve that. I know I've hit this wall before. Has anyone else? Can you suggest a stylish workaround? One method I'm considering is artificially (but reversibly) changing the output of f at every iteration, as in defining f_new =: -.&.>@:{. ,&< f (that is, concatenating a boolean and negating it every iteration). -Dan [1] Bear in mind this code is still in development, and may suffer from problems other than the one in question. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Raul Miller-4
::
Rate this Message:
On Thu, Oct 8, 2009 at 11:43 AM, Dan Bron <j@...> wrote:
> I'm seeking a stylish workaround to the a constraint on applications of > ^:_ . Some options include: Construct iteration arguments as a list and use / to iterate. Include a "generation counter" in your domain (or perhaps a bit which you always invert). -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Jose Mario Quintana
::
Rate this Message:
I hit that wall years ago; this is what I currently use instead of U^:V^:_ in similar situations:
U while V 0&({::)@:((U^:([`1:`(0&({::)@])) ,&< -.@:(1&({::)@:]))^:(''"_ $ ,@:(V^:([`1:`(0&({::)@]))))^:_^:([`1:`((] ,&< 0:)@]))) This is a modification, following a hint from Henry, of another shorter version of while that unfortunately had multiple instances of U or V resulting in generating over-sized code. By the way, what is UCALPHA? ________________________________ From: Dan Bron <j@...> To: Programming Forum <programming@...> Sent: Thursday, October 8, 2009 11:43:59 AM Subject: [Jprogramming] Limit limitation I'm seeking a stylish workaround to the a constraint on applications of ^:_ . The idiom ^:_ is well designed and well documented. It is one of the most useful tools in the J kit and has broad applicability. However, there are some cases where it's almost, but not quite, applicable. Consider the form f^:g^:_ where g is a conditional which determines if f is to be applied (again). Of course if g returns 0, then f isn't applied, and f^:g becomes an identity function, which means its output will match its input, and ^:_ will terminate. So usually ^:g^:_ acts as a while loop, independent of the operation of f, terminating iff g is 0. But now consider an f that is not one-to-one. That is, an f where two or more distinct inputs may produce identical outputs. Using this f in f^:g^:_ becomes problematic. If f receives two inputs in a row which map to the same output, then the loop will terminate early (that is, even if g is 1). Here's a recent example. I'm trying to code the "evoluationary algorithm" from RC http://rosettacode.org/wiki/Evolutionary_algorithm . The code I have so far reads [1]: CHARS =: ' ABCDEFGHIJKLMNOPQRSTUVWXYZ' randomize =: fivePct`mutation} fivePct =: 0.05 >: $ ?@$ 0: mutation =: (UCALPHA,' ')&(] ,: [ {~ $@] ?@$ #@[) score =: +/@:~:"1 copy100 =: 100 $ ,: done =: 1 - -: initial =: CHARS ([ {~ ?@$&#~ ) [ f =: ([ (] {~ (i. <./)@:score) randomize@:copy100@:]) (f^:done^:_: initial) 'METHINKS IT IS LIKE A WEASEL' The problem I'm hitting is that f here isn't deterministic. It takes a "parent", generates a random population, and selects the fittest member of that population -- which could legitimately be the original parent. Hence input and output are identical and f^:done^:_: terminates "early". What is I want is for f^:done^:_: to terminate iff done is true (that is, 'METHINKS IT IS LIKE A WEASEL' -: y ). Now, I understand that ^:_ is doing the right thing. I just want it to do a slightly different thing, and I'm asking for elegant ways to achieve that. I know I've hit this wall before. Has anyone else? Can you suggest a stylish workaround? One method I'm considering is artificially (but reversibly) changing the output of f at every iteration, as in defining f_new =: -.&.>@:{. ,&< f (that is, concatenating a boolean and negating it every iteration). -Dan [1] Bear in mind this code is still in development, and may suffer from problems other than the one in question. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Devon McCormick
::
Rate this Message:
Since I long ago swiped a few of Dan's global definitions, I can tell you
UCALPHA-:'ABCDEFGHIJKLMNOPQRSTUVWXYZ' On Thu, Oct 8, 2009 at 1:59 PM, Jose Mario Quintana < josemarioquintana@...> wrote: > I hit that wall years ago; this is what I currently use instead of U^:V^:_ > in similar situations: > > U while V > 0&({::)@:((U^:([`1:`(0&({::)@])) ,&< -.@:(1&({::)@:]))^:(''"_ $ > ,@:(V^:([`1:`(0&({::)@]))))^:_^:([`1:`((] ,&< 0:)@]))) > > > This is a modification, following a hint from Henry, of another shorter > version of while that unfortunately had multiple instances of U or V > resulting in generating over-sized code. > > By the way, what is UCALPHA? > > > > > ________________________________ > From: Dan Bron <j@...> > To: Programming Forum <programming@...> > Sent: Thursday, October 8, 2009 11:43:59 AM > Subject: [Jprogramming] Limit limitation > > I'm seeking a stylish workaround to the a constraint on applications of > ^:_ . > > The idiom ^:_ is well designed and well documented. It is one of the > most useful tools in the J kit and has broad applicability. However, > there are some cases where it's almost, but not quite, applicable. > > Consider the form f^:g^:_ where g is a conditional which determines if > f is to be applied (again). Of course if g returns 0, then f isn't > applied, and f^:g becomes an identity function, which means its output > will match its input, and ^:_ will terminate. So usually ^:g^:_ acts > as a while loop, independent of the operation of f, terminating iff g is > 0. > > But now consider an f that is not one-to-one. That is, an f where two or > more distinct inputs may produce identical outputs. Using this f in > f^:g^:_ becomes problematic. If f receives two inputs in a row which map > to the same output, then the loop will terminate early (that is, even if g > is 1). > > Here's a recent example. I'm trying to code the "evoluationary algorithm" > from RC http://rosettacode.org/wiki/Evolutionary_algorithm . The code I > have so far reads [1]: > > CHARS =: ' ABCDEFGHIJKLMNOPQRSTUVWXYZ' > randomize =: fivePct`mutation} > fivePct =: 0.05 >: $ ?@$ 0: > mutation =: (UCALPHA,' ')&(] ,: [ {~ $@] ?@$ #@[) > score =: +/@:~:"1 > copy100 =: 100 $ ,: > done =: 1 - -: > initial =: CHARS ([ {~ ?@$&#~ ) [ > > f =: ([ (] {~ (i. <./)@:score) randomize@:copy100@:]) > > (f^:done^:_: initial) 'METHINKS IT IS LIKE A WEASEL' > > The problem I'm hitting is that f here isn't deterministic. It takes a > "parent", generates a random population, and selects the fittest member of > that population -- which could legitimately be the original parent. Hence > input and output are identical and f^:done^:_: terminates "early". What > is I want is for f^:done^:_: to terminate iff done is true (that is, > 'METHINKS IT IS LIKE A WEASEL' -: y ). > > Now, I understand that ^:_ is doing the right thing. I just want it to > do a slightly different thing, and I'm asking for elegant ways to achieve > that. I know I've hit this wall before. Has anyone else? Can you > suggest a stylish workaround? > > One method I'm considering is artificially (but reversibly) changing the > output of f at every iteration, as in defining f_new =: -.&.>@:{. ,&< > f (that is, concatenating a boolean and negating it every iteration). > > -Dan > > [1] Bear in mind this code is still in development, and may suffer from > problems other than the one in question. > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Devon McCormick
::
Rate this Message:
Prepending an iteration count seems like a low-cost and sensible approach.
On Thu, Oct 8, 2009 at 1:19 PM, Raul Miller <rauldmiller@...> wrote: > On Thu, Oct 8, 2009 at 11:43 AM, Dan Bron <j@...> wrote: > > I'm seeking a stylish workaround to the a constraint on applications of > > ^:_ . > > Some options include: > > Construct iteration arguments as a list and use / to iterate. > > Include a "generation counter" in your domain (or perhaps a bit > which you always invert). > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Jose Mario Quintana
::
Rate this Message:
Thanks, Devon. (I guessed you meant =: instead of -: .)
UCALPHA =: 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' CHARS =: ' ABCDEFGHIJKLMNOPQRSTUVWXYZ' randomize =: fivePct`mutation} fivePct =: 0.05 >: $ ?@$ 0: mutation =: (UCALPHA,' ')&(] ,: [ {~ $@] ?@$ #@[) score =: +/@:~:"1 copy100 =: 100 $ ,: done =: 1 - -: initial =: CHARS ([ {~ ?@$&#~ ) [ f =: ([ (] {~ (i. <./)@:score) randomize@:copy100@:]) (f^:done^:_: initial) 'METHINKS IT IS LIKE A WEASEL' BACHIHKSEITPIN LIKHTALIERLUP (f while done initial) 'METHINKS IT IS LIKE A WEASEL' METHINKS IT IS LIKE A WEASEL For recursive alternatives to u while v see http://www.jsoftware.com/pipermail/general/2005-July/023272.html ________________________________ From: Devon McCormick <devonmcc@...> To: Programming forum <programming@...> Sent: Thursday, October 8, 2009 3:11:17 PM Subject: Re: [Jprogramming] Limit limitation Since I long ago swiped a few of Dan's global definitions, I can tell you UCALPHA-:'ABCDEFGHIJKLMNOPQRSTUVWXYZ' On Thu, Oct 8, 2009 at 1:59 PM, Jose Mario Quintana < josemarioquintana@...> wrote: > I hit that wall years ago; this is what I currently use instead of U^:V^:_ > in similar situations: > > U while V > 0&({::)@:((U^:([`1:`(0&({::)@])) ,&< -.@:(1&({::)@:]))^:(''"_ $ > ,@:(V^:([`1:`(0&({::)@]))))^:_^:([`1:`((] ,&< 0:)@]))) > > > This is a modification, following a hint from Henry, of another shorter > version of while that unfortunately had multiple instances of U or V > resulting in generating over-sized code. > > By the way, what is UCALPHA? > > > > > ________________________________ > From: Dan Bron <j@...> > To: Programming Forum <programming@...> > Sent: Thursday, October 8, 2009 11:43:59 AM > Subject: [Jprogramming] Limit limitation > > I'm seeking a stylish workaround to the a constraint on applications of > ^:_ . > > The idiom ^:_ is well designed and well documented. It is one of the > most useful tools in the J kit and has broad applicability. However, > there are some cases where it's almost, but not quite, applicable. > > Consider the form f^:g^:_ where g is a conditional which determines if > f is to be applied (again). Of course if g returns 0, then f isn't > applied, and f^:g becomes an identity function, which means its output > will match its input, and ^:_ will terminate. So usually ^:g^:_ acts > as a while loop, independent of the operation of f, terminating iff g is > 0. > > But now consider an f that is not one-to-one. That is, an f where two or > more distinct inputs may produce identical outputs. Using this f in > f^:g^:_ becomes problematic. If f receives two inputs in a row which map > to the same output, then the loop will terminate early (that is, even if g > is 1). > > Here's a recent example. I'm trying to code the "evoluationary algorithm" > from RC http://rosettacode.org/wiki/Evolutionary_algorithm . The code I > have so far reads [1]: > > CHARS =: ' ABCDEFGHIJKLMNOPQRSTUVWXYZ' > randomize =: fivePct`mutation} > fivePct =: 0.05 >: $ ?@$ 0: > mutation =: (UCALPHA,' ')&(] ,: [ {~ $@] ?@$ #@[) > score =: +/@:~:"1 > copy100 =: 100 $ ,: > done =: 1 - -: > initial =: CHARS ([ {~ ?@$&#~ ) [ > > f =: ([ (] {~ (i. <./)@:score) randomize@:copy100@:]) > > (f^:done^:_: initial) 'METHINKS IT IS LIKE A WEASEL' > > The problem I'm hitting is that f here isn't deterministic. It takes a > "parent", generates a random population, and selects the fittest member of > that population -- which could legitimately be the original parent. Hence > input and output are identical and f^:done^:_: terminates "early". What > is I want is for f^:done^:_: to terminate iff done is true (that is, > 'METHINKS IT IS LIKE A WEASEL' -: y ). > > Now, I understand that ^:_ is doing the right thing. I just want it to > do a slightly different thing, and I'm asking for elegant ways to achieve > that. I know I've hit this wall before. Has anyone else? Can you > suggest a stylish workaround? > > One method I'm considering is artificially (but reversibly) changing the > output of f at every iteration, as in defining f_new =: -.&.>@:{. ,&< > f (that is, concatenating a boolean and negating it every iteration). > > -Dan > > [1] Bear in mind this code is still in development, and may suffer from > problems other than the one in question. > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
|
|
|
|
|
|
Re: Limit limitation
by Dan Bron
::
Rate this Message:
I said:
> I'm seeking a stylish workaround to the a constraint on applications of > ^:_ . Raul responded: > Construct iteration arguments as a list and use / to iterate. I agree this is a useful idiom, if your problem can be rephrased this way. However, only algorithms that have a fixed number of iterations are amenable to such rephrasing, unless you can correct me. This algorithm is nondeterministic and so cannot be phrased in terms of a fixed number of iterations: > Include a "generation counter" in your domain (or perhaps a bit > which you always invert). Yes, I already considered this approach: > that is, concatenating a boolean and negating it every iteration In fact, it is the one I adopted. However, I do not consider it "stylish". Jose wrote: > this is what I currently use instead of U^:V^:_ in similar situations: I have to study this "while" -- at first glance, it seems to be more complicated than neccesary. Can you explain its operation at a high level? > For recursive alternatives to u while v see > http://www.jsoftware.com/pipermail/general/2005-July/023272.html > evolve=. ]`([ $: f)@.done I avoid recursion in J if I can; it's unreliable (because the language doesn't optimize tail calls, it has a low, artificial, compiler-imposed limit on stack depth). > I guess Dan really meant: Yep, you got it. -Dan ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Jose Mario Quintana
::
Rate this Message:
I also try to avoid recursion for several reasons but, for the case at hand, the code is very terse and found the solution hundreds of times without any problem.
Regarding "while," it implements, in general, a companion flipping boolean (similar to the "negating") to avoid exiting due to a "premature" convergence. The code is complicated because it is defined in a way that both arguments (the verbs) appear only once in the generated code (it also forces the exiting boolean condition to be a scalar to avoid "surprises"). This feature is important, to me, because typically the code that defines those verbs (particularlly the left argument) can be very large in my applications. Of course, I would gladly use a simpler general alternative that retains the feature(s) that I mentioned, if you or any one else, can find it and share it. ________________________________ From: Dan Bron <j@...> To: Programming forum <programming@...> Sent: Friday, October 9, 2009 7:19:58 PM Subject: Re: [Jprogramming] Limit limitation I said: > I'm seeking a stylish workaround to the a constraint on applications of > ^:_ . Raul responded: > Construct iteration arguments as a list and use / to iterate. I agree this is a useful idiom, if your problem can be rephrased this way. However, only algorithms that have a fixed number of iterations are amenable to such rephrasing, unless you can correct me. This algorithm is nondeterministic and so cannot be phrased in terms of a fixed number of iterations: > Include a "generation counter" in your domain (or perhaps a bit > which you always invert). Yes, I already considered this approach: > that is, concatenating a boolean and negating it every iteration In fact, it is the one I adopted. However, I do not consider it "stylish". Jose wrote: > this is what I currently use instead of U^:V^:_ in similar situations: I have to study this "while" -- at first glance, it seems to be more complicated than neccesary. Can you explain its operation at a high level? > For recursive alternatives to u while v see > http://www.jsoftware.com/pipermail/general/2005-July/023272.html > evolve=. ]`([ $: f)@.done I avoid recursion in J if I can; it's unreliable (because the language doesn't optimize tail calls, it has a low, artificial, compiler-imposed limit on stack depth). > I guess Dan really meant: Yep, you got it. -Dan ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Sherlock, Ric
::
Rate this Message:
> From: Dan Bron
> > Here's a recent example. I'm trying to code the "evoluationary > algorithm" > from RC http://rosettacode.org/wiki/Evolutionary_algorithm . The > code I > have so far reads [1]: > > CHARS =: ' ABCDEFGHIJKLMNOPQRSTUVWXYZ' > randomize =: fivePct`mutation} > fivePct =: 0.05 >: $ ?@$ 0: > mutation =: (UCALPHA,' ')&(] ,: [ {~ $@] ?@$ #@[) > score =: +/@:~:"1 > copy100 =: 100 $ ,: > done =: 1 - -: > initial =: CHARS ([ {~ ?@$&#~ ) [ > > f =: ([ (] {~ (i. <./)@:score) randomize@:copy100@:]) > > (f^:done^:_: initial) 'METHINKS IT IS LIKE A WEASEL' > Hi Dan, I'm just catching up on the forum (having been on holiday for a while). While not related to your main query (which others appear to have handled), I thought I should note that I've submitted a solution for that problem on Rosetta Code. I was aware of this thread, but hadn't read your code beforehand, nevertheless that there are a number of similarities. I'm sure some of your ideas above could be used to improve my current implementation. A tacit version of the current "mutate" verb would be nice. A tacit version of the while loop would also be good but I think it should be included in addition to the explicit one. I'm starting to see Rosetta Code not only as a Rosetta stone for different languages but also for the different forms (tacit/explicit) of J! Ric ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Dan Bron
::
Rate this Message:
Ric wrote:
> I've submitted a solution for [evolutionary algorithm] on Rosetta Code Thank you! > A tacit version of the while loop would also be good but > I think it should be included in addition to the explicit one I'm still of the opinion that our goal on RC should be evangelism -- and I don't feel explicit code assists that effort. Reflecting on my own RC usage, when I look at a new task: I first read its description, then I look to see if a J solution has already been presented. If it hasn't, I work one out and submit it. Then I scan through the other submissions and only bother to read the code that looks interesting, and in particular only short entries (so I don't have to spend much time). Short entries catch my eye, and so do "weird" entries. [1] Entries with a lot of "for" and "while" and "a[i] = a[i-1] * 2" do not interest me, and I ignore them. From my POV, such languages are mere dialects of C (or Java, etc). And while I know I could solve general problems in them (including all RC problems), and I could probably learn such a language quickly, I see no reason to, since I already know C (and Java etc). I don't feel like they have much to offer me. Now, I could be wrong: these languages may have new or interesting features. But I'll never know, and that's the point. The very use of these patterns leads me to believe that I already basically know the language (and that it's tedious from a programming POV), and so I summarily dismiss it. And the language has lost a potential convert. Which is just a long way of saying that I prefer we present brief, tacit J solutions on RC. Elaboration or exegesis or alternative (explicit) solutions can go on the talk page, or on a linked subpage (either of the task or of the J category page). That said, I feel penetration (task coverage) on RC is even more important than presentation, and I know that I don't have the bandwidth to keep up with the site myself. So I'm sincerely grateful to you and others who are contributing solutions. To that end, I certainly am not going to demotivate anyone by stepping all over his code and rewriting it in my preferred style, or even tacitly. Plus I enjoy seeing other J coding styles, which are hard to find in the wild. So I think the current system works fine (where we have several contributors who add solutions when and how they choose), because J is getting good coverage and generating discussion among "foreigners". But I'm also willing to collaborate on a "house style" for J, which would neccesarily entail building consensus regarding our goals on RC. To that end, I've created a page on RC to start that dicussion: http://rosettacode.org/wiki//HouseStyle . If you have any ideas or suggestions for the J community on RC, you can discuss it there. But if you're happy operating independently on RC, feel free to ignore it. -Dan [1] Case in point. I wanted to solve http://rosettacode.org/wiki/Nth_root_algorithm . So the first thing I did was visit the WP page, http://en.wikipedia.org/wiki/Nth_root_algorithm . But that page listed only mathematical solutions, and what I wanted was pseudocode I could mechanically translate into J. So I started scanning the RC entries. I skipped over most of them because they were long and looked like they'd take a while to translate. But the E solution caught my eye -- it was short and high-level. So I translated that in J. And as it turns out, the E solution was not only shorter because E is high-level, but because its author had chosen a "different" algorithm. One that, coincidentally, can be expressed elegantly in J. Maybe there really is a correspondance between "weird, high-level languages" and "thinking differently". Ken clearly thought so. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Dan Bron
::
Rate this Message:
I wrote:
> To that end, I've created a page on RC to start that dicussion: > http://rosettacode.org/wiki//HouseStyle . The link should've been http://rosettacode.org/wiki/J/HouseStyle . -Dan ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Rosetta Code goals (was Limit limitation)
by Sherlock, Ric
::
Rate this Message:
> From: Dan Bron
> I'm still of the opinion that our goal on RC should be evangelism -- > and I don't feel explicit code assists that effort. I think that depends on the target audience of the evangelism. I imagine there are some who will look at a one-line, tacit J solution composed of primitives and be intrigued enough to devote the time required to work out what is going on, however I believe that those people are probably relatively few in number. The reaction of the majority (borne out by recent reactions on RC [1]) is something like: "Wow that's short, but it looks like unintelligible gobbledy gook to me. I wouldn't even know where to start trying to understand it ... Next!" (In some instances a number of J'ers may have a similar reaction!!!) The question for me is, if we go for a slightly more verbose style, that might be semi-comprehensible to a non-J'er, are we likely to drag in more potential users? We might need to go from answers that are 1/10 as long as others to only being 1/3 as long, but I think they will still "catch the eye". As long as the code blocks for separate implementations are well labelled (e.g. "=== Alternative short solution ===") then perhaps including both is an option that provides the best of both worlds? Another thing that will probably make a big difference to the attractiveness/readability of the J code on the site (and the J wiki) is providing syntax highlighting. I'd be willing to collaborate on such an effort. [snip] > But > I'm also willing to collaborate on a "house style" for J, which would > neccesarily entail building consensus regarding our goals on RC. > > To that end, I've created a page on RC to start that dicussion: > http://rosettacode.org/wiki//HouseStyle . If you have any ideas or > suggestions for the J community on RC, you can discuss it there. I've put up some initial suggestions for goals. [1] http://rosettacode.org/wiki/User_talk:Dkf#Your_discussion_about_J ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Rosetta Code goals (was Limit limitation)
by Roger Hui
::
Rate this Message:
Rather than an overt evangelism, it may work better to
just write the "best" J code that you can, taking care to make it as easy for the reader as you can. This was the approach taking in the Project Euler problems. http://projecteuler.net/index.php?section=problems Some new people have been motivated to learn J as a result. (After you've sweat blood for a few days solving a problem, you'd be highly motivated to find out why the solution in another language is so much shorter.) ----- Original Message ----- From: "Sherlock, Ric" <R.G.Sherlock@...> Date: Monday, October 12, 2009 15:43 Subject: Re: [Jprogramming] Rosetta Code goals (was Limit limitation) To: Programming forum <programming@...> > > From: Dan Bron > > I'm still of the opinion that our goal on RC should be > evangelism -- > > and I don't feel explicit code assists that effort. > > I think that depends on the target audience of the evangelism. > I imagine there are some who will look at a one-line, tacit J > solution composed of primitives and be intrigued enough to > devote the time required to work out what is going on, however I > believe that those people are probably relatively few in number. > The reaction of the majority (borne out by recent reactions on > RC [1]) is something like: > > "Wow that's short, but it looks like unintelligible gobbledy > gook to me. I wouldn't even know where to start trying to > understand it ... Next!" > (In some instances a number of J'ers may have a similar reaction!!!) > > The question for me is, if we go for a slightly more verbose > style, that might be semi-comprehensible to a non-J'er, are we > likely to drag in more potential users? We might need to go from > answers that are 1/10 as long as others to only being 1/3 as > long, but I think they will still "catch the eye". > > As long as the code blocks for separate implementations are well > labelled (e.g. "=== Alternative short solution ===") then > perhaps including both is an option that provides the best of > both worlds? > > Another thing that will probably make a big difference to the > attractiveness/readability of the J code on the site (and the J > wiki) is providing syntax highlighting. I'd be willing to > collaborate on such an effort. > > [snip] > > But > > I'm also willing to collaborate on a "house style" for J, > which would > > neccesarily entail building consensus regarding our goals on RC. > > > > To that end, I've created a page on RC to start that dicussion: > > http://rosettacode.org/wiki//HouseStyle . If you > have any ideas or > > suggestions for the J community on RC, you can discuss it > there. > > I've put up some initial suggestions for goals. > > [1] > http://rosettacode.org/wiki/User_talk:Dkf#Your_discussion_about_J For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Rosetta Code goals (was Limit limitation)
by Skip Cave-3
::
Rate this Message:
I absolutely agree with Roger. Write the "best" J code you can for the
RC forum. Make your code examples short, crisp, and elegant. However for some programmers, terseness and elegance aren't necessarily good traits for a programming language.. J has many other features besides terseness that provide benefits for programmers, but those benefits may be overlooked if our focus is just on the shortness of our example code. I believe the key to attracting more interest in J, is to include more extensive comments and explanations with the example code in the RC forum than one would if we were presenting to an audience of J programmers. Create the most elegant code you can for the RC example, but follow the code with a clear explanation of how it works in English, that any programmer could understand. If programmers see an elegant J phrase, but dismiss it out of hand as a "trick" they won't take the time to investigate J any further. If an elegant J phrase solution is followed by a careful explanation of the various aspects of the solution, most programmers will be much more likely to stop and think about all of the ramifications of matrix operations and tacit programming. The whole purpose of the RC forum is to educate non-J-programmers of the advantages of J. I believe that the best approach to that education is to "show the elegance", then explain it in not-so-elegant English. . .Skip Cave Roger Hui wrote: > Rather than an overt evangelism, it may work better to > just write the "best" J code that you can, taking care > to make it as easy for the reader as you can. > This was the approach taking in the Project Euler problems. > http://projecteuler.net/index.php?section=problems > Some new people have been motivated to learn > J as a result. (After you've sweat blood for > a few days solving a problem, you'd be highly > motivated to find out why the solution in > another language is so much shorter.) > > > > ----- Original Message ----- > From: "Sherlock, Ric" <R.G.Sherlock@...> > Date: Monday, October 12, 2009 15:43 > Subject: Re: [Jprogramming] Rosetta Code goals (was Limit limitation) > To: Programming forum <programming@...> > > >>> From: Dan Bron >>> I'm still of the opinion that our goal on RC should be >>> >> evangelism -- >> >>> and I don't feel explicit code assists that effort. >>> >> I think that depends on the target audience of the evangelism. >> I imagine there are some who will look at a one-line, tacit J >> solution composed of primitives and be intrigued enough to >> devote the time required to work out what is going on, however I >> believe that those people are probably relatively few in number. >> The reaction of the majority (borne out by recent reactions on >> RC [1]) is something like: >> >> "Wow that's short, but it looks like unintelligible gobbledy >> gook to me. I wouldn't even know where to start trying to >> understand it ... Next!" >> (In some instances a number of J'ers may have a similar reaction!!!) >> >> The question for me is, if we go for a slightly more verbose >> style, that might be semi-comprehensible to a non-J'er, are we >> likely to drag in more potential users? We might need to go from >> answers that are 1/10 as long as others to only being 1/3 as >> long, but I think they will still "catch the eye". >> >> As long as the code blocks for separate implementations are well >> labelled (e.g. "=== Alternative short solution ===") then >> perhaps including both is an option that provides the best of >> both worlds? >> >> Another thing that will probably make a big difference to the >> attractiveness/readability of the J code on the site (and the J >> wiki) is providing syntax highlighting. I'd be willing to >> collaborate on such an effort. >> >> [snip] >> >>> But >>> I'm also willing to collaborate on a "house style" for J, >>> >> which would >> >>> neccesarily entail building consensus regarding our goals on RC. >>> >>> To that end, I've created a page on RC to start that dicussion: >>> http://rosettacode.org/wiki//HouseStyle . If you >>> >> have any ideas or >> >>> suggestions for the J community on RC, you can discuss it >>> >> there. >> >> I've put up some initial suggestions for goals. >> >> [1] >> http://rosettacode.org/wiki/User_talk:Dkf#Your_discussion_about_J >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > > For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Sherlock, Ric
::
Rate this Message:
> > From: Dan Bron
> > > > I'm trying to code the "evoluationary algorithm" > > from RC http://rosettacode.org/wiki/Evolutionary_algorithm . The code I > > have so far reads [1]: > > [snip] > > > > The problem I'm hitting is that f here isn't deterministic. It takes a > > "parent", generates a random population, and selects the fittest member of > > that population -- which could legitimately be the original parent. Hence > > input and output are identical and f^:done^:_: terminates "early". What > > is I want is for f^:done^:_: to terminate iff done is true (that is, > > 'METHINKS IT IS LIKE A WEASEL' -: y ). > > > > Now, I understand that ^:_ is doing the right thing. I just want it to > > do a slightly different thing, and I'm asking for elegant ways to achieve > > that. I know I've hit this wall before. Has anyone else? Can you > > suggest a stylish workaround? > Ric wrote: > I've submitted a solution for [evolutionary algorithm] on Rosetta > Code > A tacit version of the while loop would also be good but > I think it should be included in addition to the explicit one I had a go at putting together a tacit while loop for this problem and came up with a solution but am not sure it is what you were after! It gets around the issue you describe by catenating the best solution for each generation to previous ones, but only "works" with the last best solution. NB. From current solution on RC CHARSET=: 'ABCDEFGHIJKLMNOPQRSTUVWXYZ ' NPROG=: 100 NB. "C" from specification fitness=: +/@:~:"1 select=: ] {~ (i. <./)@:fitness NB. select fittest member of population populate=: (?@$&# { ])&CHARSET NB. get random list from charset of same length as y mutate=: dyad define idxmut=. I. x >: (*/$y) ?@$ 0 (populate idxmut) idxmut"_} y ) NB. Tacit alternative for current evolve mrate =: %@:# nextgeneration=: ] , [ select {:@] , mrate@[ mutate NPROG # ,:@{:@] notPerfect =: 0 < [ fitness {:@] evolve=: ] (nextgeneration ^: notPerfect ^:_) ,:@populate ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Sherlock, Ric
::
Rate this Message:
> From: Sherlock, Ric
> > > > From: Dan Bron > > > > > > I'm trying to code the "evoluationary algorithm" > > > from RC http://rosettacode.org/wiki/Evolutionary_algorithm . The > code I > > > have so far reads [1]: > > > > [snip] > > > > > > The problem I'm hitting is that f here isn't deterministic. It > takes a > > > "parent", generates a random population, and selects the fittest > member of > > > that population -- which could legitimately be the original parent. > Hence > > > input and output are identical and f^:done^:_: terminates > "early". What > > > is I want is for f^:done^:_: to terminate iff done is true > (that is, > > > 'METHINKS IT IS LIKE A WEASEL' -: y ). > > > > > > Now, I understand that ^:_ is doing the right thing. I just want > it to > > > do a slightly different thing, and I'm asking for elegant ways to > achieve > > > that. I know I've hit this wall before. Has anyone else? Can you > > > suggest a stylish workaround? > > > Ric wrote: > > I've submitted a solution for [evolutionary algorithm] on Rosetta > > Code > > A tacit version of the while loop would also be good but > > I think it should be included in addition to the explicit one > > I had a go at putting together a tacit while loop for this problem and > came up with a solution but am not sure it is what you were after! It > gets around the issue you describe by catenating the best solution for > each generation to previous ones, but only "works" with the last best > solution. > > NB. From current solution on RC > CHARSET=: 'ABCDEFGHIJKLMNOPQRSTUVWXYZ ' > NPROG=: 100 NB. "C" from specification > > fitness=: +/@:~:"1 > select=: ] {~ (i. <./)@:fitness NB. select fittest member of > population > populate=: (?@$&# { ])&CHARSET NB. get random list from > charset of same length as y > mutate=: dyad define > idxmut=. I. x >: (*/$y) ?@$ 0 > (populate idxmut) idxmut"_} y > ) > > NB. Tacit alternative for current evolve > mrate =: %@:# > nextgeneration=: ] , [ select {:@] , mrate@[ mutate NPROG # ,:@{:@] > notPerfect =: 0 < [ fitness {:@] > > evolve=: ] (nextgeneration ^: notPerfect ^:_) ,:@populate Or simpler: evolve=: nextgeneration ^: notPerfect ^:_ ,:@populate ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
Re: Limit limitation
by Jose Mario Quintana
::
Rate this Message:
"I had a go at putting together a tacit while loop for this problem and came up with a solution but am not sure it is what you were after! It gets around the issue you describe by catenating the best solution for each generation to previous ones, but only 'works' with the last best solution."
Would that change not affect the nature of the evolutionary algorithm and the task itself? ________________________________ From: "Sherlock, Ric" <R.G.Sherlock@...> To: Programming forum <programming@...> Sent: Mon, November 2, 2009 4:20:10 AM Subject: Re: [Jprogramming] Limit limitation > > From: Dan Bron > > > > I'm trying to code the "evoluationary algorithm" > > from RC http://rosettacode.org/wiki/Evolutionary_algorithm . The code I > > have so far reads [1]: > > [snip] > > > > The problem I'm hitting is that f here isn't deterministic. It takes a > > "parent", generates a random population, and selects the fittest member of > > that population -- which could legitimately be the original parent. Hence > > input and output are identical and f^:done^:_: terminates "early". What > > is I want is for f^:done^:_: to terminate iff done is true (that is, > > 'METHINKS IT IS LIKE A WEASEL' -: y ). > > > > Now, I understand that ^:_ is doing the right thing. I just want it to > > do a slightly different thing, and I'm asking for elegant ways to achieve > > that. I know I've hit this wall before. Has anyone else? Can you > > suggest a stylish workaround? > Ric wrote: > I've submitted a solution for [evolutionary algorithm] on Rosetta > Code > A tacit version of the while loop would also be good but > I think it should be included in addition to the explicit one I had a go at putting together a tacit while loop for this problem and came up with a solution but am not sure it is what you were after! It gets around the issue you describe by catenating the best solution for each generation to previous ones, but only "works" with the last best solution. NB. From current solution on RC CHARSET=: 'ABCDEFGHIJKLMNOPQRSTUVWXYZ ' NPROG=: 100 NB. "C" from specification fitness=: +/@:~:"1 select=: ] {~ (i. <./)@:fitness NB. select fittest member of population populate=: (?@$&# { ])&CHARSET NB. get random list from charset of same length as y mutate=: dyad define idxmut=. I. x >: (*/$y) ?@$ 0 (populate idxmut) idxmut"_} y ) NB. Tacit alternative for current evolve mrate =: %@:# nextgeneration=: ] , [ select {:@] , mrate@[ mutate NPROG # ,:@{:@] notPerfect =: 0 < [ fitness {:@] evolve=: ] (nextgeneration ^: notPerfect ^:_) ,:@populate ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm |
|
|
|
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
