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
