> 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 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
