Yeah, it's actually kind of depressing that google engineers probably being paid over $200k/year struggle to understand this kind of stuff.
-- Raul On Thu, Feb 18, 2016 at 1:52 PM, Don Guinn <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
