Responding to you with a good bit of lag: > > My first approach was to "lazy load" by making all p1, p2, etc. strings > > and > > evaluating with > > > > 0!:111 ".&> (#~ 0 = 4!:0) 'p'&,&.> ARGV > > > > However, this strikes me as a bit ugly. It also makes it a bit awkward > > to > > investigate and iterate on solutions when loading into jconsole. > > > > So the scheme I came up with is a simple modification of the initial > > approach. > > Instead of p1, p2, etc. we now have [x1], v1, y1, [x2], v2, y2, etc. > > (where > > [x1] means that x1 is optional). Effectively we want to expand the > > argument '1' > > into 'x1 v1 y1' or 'v1 y1' as appropriate and then execute. This is how > > I am > > achieving that: > > > > echo ". ,"_1 ,&' '&> |: (#~"1 (0 3 0) = 4!:0) 'xvy' ,&.>/ ARGV > > > > It's quite nice how closely this mirrors the original approach. After > > the hook, > > we have a table whose columns encode the executions we want. Finally, a > > bit of > > munging gives the desired result. > > ... oh, OK, this is a way to only make some of the more > expensive computations verbs to be run.
Certainly. On the one extreme, we could simply store all anwsers in the 'y' nouns, which is equivalent to my original "precompute all answers" approach. On the other extreme, the 'y' (and 'x') are defined purely as nouns, with all evaluation steps stored in the 'v' verbs. Project Euler problems are typically organized by giving general problem and tasking you to compute the answer for a specific input. This maps nicely onto my 'x v y' scheme since inputs can generally be storedi in 'x y' with very little evaluation, while the "general problem" gets encoded into the 'v' verbs. > > Thoughts? Is this Good J TM? > > For your purposes what I would really do is skip the script > entirely and use the JQt environment, with my p1, p2, etc. code > in an editor. When I want to calculate p1, just ctrl-enter down > that part of the file, or select it and ctrl-e. All the code is > visible and can be edited. None of it's run automatically. You > can have multiple versions right next to each other, next to your > thoughts about them, next to some benchmark or tests of them. > The console right next to the editor lets you inspect things, > and then you have additional tools like debug/dissect. This is definitely a lateral thinking approach. I don't have access to JQt, but more to the point, I want this to be usable just like any other CLI program. Partly, I am looking at if/how J can be used as a replacement for shell scripts, sed, awk etc. > It's really J's terseness that makes this an option at all. > > You could go further and make it a lab. The format's very easy, > even the old format, you can interactively run what you like > just the same, but now there's the option of someone stepping > through it as a lab. Interesting. Thanks for pointing this out. I will definitely look into the lab format, if for nothing else than future reference. Cheers! ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
