Several kinds of issues intersect here. One issue is of course the existing implementations of J. As we have seen, the implementation for imposing rank on a verb involves sequential processing.
One issue is machine architecture. Historically, J has been implemented on a CPU architecture -- it's designed for a central processor. (Economic factors have been making non-CPU architectures viable. There's things like Beowulf clusters, where we might spawn up independent processes on independent machines which each have their own CPU. And, there's the GPUs, where graphical processing systems are becoming more and more competent, and in some cases far surpass the processing power of similarly priced CPU systems.) One issue has to do with our mathematical models for what's happening. Typically, "purely functional" uses (without side effects) do not care about execution ordering, while code with intricately designed external dependencies imposes strict requirements on ordering. One issue is the exact wording of the dictionary itself. Since the dictionary is our primary reference document, we would ideally want any alternative implementations to still comply with the dictionary. One issue is the existing base of J code. Hopefully, we do not want to be breaking too many programs that already work in J when we release a new J version. (Ideally, we do not break any such programs, but perhaps some are already broken and we just have not noticed...) Anyways, it's probably also worth noting that there are a variety of concepts of "parallelism". One concept is where we initiate a chain of events which has some independent existence. (This corresponds to starting new "processes" in an operating system which supports multiple independent processes.) Another concept is where our parallel operations have no independent existence. (This corresponds to a GPU where each processor is running the same code, and the differences all exist in the data.) In terms of concepts, I think that the GPU style of parallelism is "more J-like" than the Beowulf style of parallelism. That said, GPUs have a fixed, finite number of processors, and for linguistic purposes we want to create abstractions which always implement the same concepts regardless of the number of available processors. FYI, -- Raul P.S. I am not sure if it's time to move this subject tangent to a new forum... On Tue, Sep 11, 2012 at 1:47 PM, Devon McCormick <devon...@gmail.com> wrote: > An interesting and potentially useful ambiguity here is that > > process"0 (1+i.2) > > conceptually (as I understand it) processes the two arguments > simultaneously but actually processes them serially as it is written > in Raul's example. One reason this is interesting is that you could > write "process" to spin off a separate J instance for each argument if > you wanted to process them in parallel. Though you would be spinning > off the processes serially, if each argument takes enough time to > process- more time than it takes to advance to the next argument - you > would effectively have parallel processing going on. > > On Tue, Sep 11, 2012 at 1:24 PM, Raul Miller <rauldmil...@gmail.com> wrote: >> On Tue, Sep 11, 2012 at 12:50 PM, pascha <amirpasha...@gmail.com> wrote: >>> Thanks.. "row_number" works >>> But now the problem is I want the verb to iterate over one array at a time. >>> for example if I do proccess"0(1+i.2) the resultant input is: > ... > > -- > Devon McCormick, CFA > ^me^ at acm. > org is my > preferred e-mail > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
