Guy's four solutions for the water problem really bothered me. Why does he make this sound so difficult? So I wrote a J definition for water:
water =: +/ @: -~ >./\ <. >./\. water 2 6 3 5 2 8 1 4 2 2 5 3 5 7 4 1 35 It is identical to his first serial solution except all "how to" (loops) are removed (left for the J interpreter to do as it sees best). I noticed that his fourth solution is the same as his first serial solution, rewriting it removing the "how to's", leaving that to library routines. The solution in J is also ready for parallel processing. It just so happens that the J interpreter does not support that right now. I can see that it would not be difficult for the J interpreter to use the tree approach to parallelizing the scans and summation to incorporate parallel computing. Or one of several other methods. And the definition of water is untouched. Watching the video a second time it amazed me to see people still struggling with and recreating concepts that Ken Iverson and others so clearly defined and exploited long ago. On Tue, Feb 16, 2016 at 5:33 AM, Raul Miller <[email protected]> wrote: > On Tue, Feb 16, 2016 at 2:21 AM, Roger Hui <[email protected]> > wrote: > >> He presents a loop to compute +/1+i.1e6 using a loop and then > >> introduces some concerns. But, of course, the efficient implementation > >> of that algorithm here would be -:@(*>:) 1e6 or perhaps 0 0.5 0.5 p. 1e6 > > > > 2!1+1e6 > > Nicer. > > Thanks, > > -- > Raul > > > On Mon, Feb 15, 2016 at 11:09 PM, Raul Miller <[email protected]> > wrote: > > > >> Hmm.... > >> > >> I think Guy Steele is being sort of relevant, in his Growing a > >> Language paper, but I think he's definitely oversimplifying also. > >> > >> Let's consider his first example involving "noun that names one thing". > >> > >> First off, note that he does not actually include any information > >> about how to distinguish between nouns that get 's' and nouns that get > >> 'es' when made plural. So if we take some example nouns, like 'city', > >> 'leaf', 'life', 'man' or 'geese' we do not know which of those rules > >> to apply to any of them. > >> > >> Second off, let's consider his next example of "numbers with no > >> bound". From experience, we know that if we want to have a lot of > >> numbers we're going to have to put some bound on them, or things crawl > >> to a stop. In J, that's the difference between 10^100 and 10^100x. > >> > >> Anyways, to make a long story short, I think there's a lot more to the > >> suitability of a language than its size. There's always going to be > >> limitations, and there's more to the usefulness of a language than the > >> size of the vocabulary it provides. > >> > >> That said, I think I understand some of his frustrations. > >> > >> But let's jump to his youtube talk about parallelization. > >> > >> He presents a loop to compute +/1+i.1e6 using a loop and then > >> introduces some concerns. But, of course, the efficient implementation > >> of that algorithm here would be -:@(*>:) 1e6 or perhaps 0 0.5 0.5 p. > >> 1e6 > >> > >> This is a general problem with a lot of "computer science" - we've got > >> solutions looking for problems, and we rather lazily go for the wrong > >> solution all too often. Brute force works (by "brute force" here, I > >> mean: acting without attempting to understand further), and is often > >> enough the best choice. But that does not mean we couldn't do a lot > >> better, and sometimes that's the best choice (like, for example, when > >> brute force isn't working). If it's stupid and it works, it's not > >> stupid. > >> > >> Anyways, playing with this kind of thing can be fun, so that's > >> probably a good thing. To some degree. > >> > >> But, getting back to parallelization, the motivating issue for > >> parallelization is efficiency. But that's meaningless if you're not > >> making some effort to track relevant resource costs. But that's a > >> pain. So he's not doing that, and he's kind of glossing over that > >> issue in his youtube talk (though he did touch on it in a few places). > >> > >> But I guess I sort of drifted off during his talk and didn't pay > >> enough attention to a lot of it. > >> > >> Still, his water histogram thing was kind of fun, so here's some > >> operations on those things: > >> > >> NB. go above this and water spills out > >> hull=: >./\ <. >./\. > >> > >> NB. how much water can be poured into a structure > >> water=: [: +/ ] - hull > >> > >> NB. how much water you can add when you join two globs together: > >> combine=: water@,&hull > >> > >> (Though you might make the case that hull should be left out of the > >> combine operation?) > >> > >> Example uses: > >> water 2 6 3 5 2 8 1 4 2 2 5 3 5 7 4 1 > >> 35 > >> 2 6 3 5 2 8 1 4 combine 2 2 5 3 5 7 4 1 > >> 22 > >> > >> Note that I've left out some of the details of his representation. > >> Also, I guess there's still a fair bit that could be said here, in the > >> context of his talk. For example, I guess hull is an idempotent > >> operation: > >> hull 2 6 3 5 2 8 1 4 > >> 2 6 6 6 6 8 4 4 > >> hull hull 2 6 3 5 2 8 1 4 > >> 2 6 6 6 6 8 4 4 > >> > >> And, that might be significant if we were building a J compiler. > >> (Which, to be useful, would probably need to deal with constraining to > >> relevant collections of types and shapes.) > >> > >> Or, at least, that's my current current thought. But I guess the big > >> thing, from my point of view, is how much of the detail he presented > >> I'm glossing over. But simplification is good, right? > >> > >> Thanks, > >> > >> -- > >> Raul > >> > >> > >> > >> On Mon, Feb 15, 2016 at 6:00 AM, June Kim (김창준) <[email protected]> > >> wrote: > >> > Hello > >> > > >> > I watched an interesting video from Guy Steel. who is famous for his > >> > Growing a Language paper : > >> > https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf and his > >> design > >> > of scheme, common lisp, and java. > >> > > >> > He is also a famous researcher in concurrent mathematical > programming. He > >> > designed the Fortress language. > >> > https://en.wikipedia.org/wiki/Fortress_(programming_language) > >> > > >> > The following video is his lecture at Google. > >> > https://www.youtube.com/watch?v=ftcIcn8AmSY > >> > > >> > He shows the solutions for water histogram problem and compares > >> sequential > >> > and parallel approaches. It is interesting from the perspective of > array > >> > oriented languages. > >> > > >> > June > >> > ---------------------------------------------------------------------- > >> > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
