Lest you think that "," for catenation is came down on the stone tablets:
Catenation was denoted by ⊕ (circle-plus) in "A Programming Language" (March 1962) http://www.jsoftware.com/papers/APL.htm and in "Programming Notation in System Design" (June 1963), http://www.jsoftware.com/papers/PNSD.htm and only settled on the now familiar , (comma) in "Formalism in Programming Languages" (February 1964). http://www.jsoftware.com/papers/FPL.htm . The next major change came in July 1990 when J redefined , to denote the computation usually denoted by comma-bar in APL. http://www.jsoftware.com/papers/J1990.htm ----- Original Message ----- From: Devon McCormick <[email protected]> Date: Monday, March 1, 2010 14:09 Subject: Re: [Jchat] Multiple cores To: Chat forum <[email protected]> > Just glancing at "E", I see that the implementer continues the > time-honored > programming language tradition of separating the wheat from the > chaff and > keeping the chaff. The language apparently patches the > poor symbol choice > of "+" for concatenation by having it vary meaning according to > the type of > the left argument - "a+b" is addition if "a" is a number but it's > concatenation if "a" is a string. > > I think we'll be talking about multi-core programming at next > week's NYCJUG, > so thanks for the reference. > > On Mon, Mar 1, 2010 at 4:18 PM, Yuvaraj Athur Raghuvir < > [email protected]> wrote: > > > I recently came across E [1] and Distributed Computing using > non-blocking > > promise [2]. In the talk I heard, the speaker indicated that E > is more an > > architecture than a specific language and so can be embedded > in situation > > that demanded multi-core distributed computing as well. > > > > FYI > > > > [1] http://erights.org/ > > [2] http://wiki.erights.org/wiki/Walnut/Distributed_Computing > > > > On Tue, Feb 16, 2010 at 9:18 AM, Yuvaraj Athur Raghuvir < > > [email protected]> wrote: > > > > > Hello, > > > I experimented with distributed data persistence. These are > my notes: > > > 0) The experiment was to use SQLite as a relational store > and q as a > > column > > > store and see how the data can be managed across these two stores. > > > a) jdb came in afterwards but I have not yet ported the > experiment to > > jdb. > > > 1) I used Chris Burke's J to q connector code [1]. I liked > the way the > > > communication protocol was set up. > > > 2) When working with sockets and multiple instances of J > server - J > > client > > > pattern, the following were noted: > > > a) managing the ports and logs on the ports > > > b) setting up the synchronous or asynchronous operations > > > c) external monitor of the number of instances and their > roles in the > > > computation. This is another process that sets up > independent connection > > to > > > the instances. It could also be the main instance launcher > process.> > 3) There are interesting patterns that can be > explored in the > > > request-response: > > > a) synchronous blocking > > > b) asynchronous > > > c) asynchronous with callback > > > 4) The protocol can be extended to query for value and > creation of verbs > > > from strings in the target J server. > > > 5) As Alex has noted with data bases, SQL statements > eventually cause the > > > overhead of string manipulations. > > > 6) Debugging was quite tricky. However with the interpreter > I was able to > > > make significant progress as I was able to trace the calls > on the client > > and > > > follow through on the server. During the debug runs I was > encountering> > issues with setting breakpoints I do not > recollect were exactly. > > > > > > The communication protocol has to be clear on > > > a) Communication Layer: This cares only about the > communication of > > > information and reports error information at this level. > > > b) Setting up the request-response patterns: Reports errors > at this level > > > c) Logical/Computational layer: Errors of this layer have > different> > characteristics. Probably this can be further split into > > > c.1) The data for the computation and its validation > > > c.2) The computation that is invoked on this data and its > validation> > c.3) The actual computation on the data. > > > > > > This is how far I got. > > > > > > ~Yuva > > > > > > > > > [1] See http://www.jsoftware.com/jwiki/Interfaces/Kdb > > > > > > On Tue, Feb 16, 2010 at 6:51 AM, Skip Cave > <[email protected]> >wrote: > > > > > >> > > >> > > >> Alex Rufon wrote: > > >> > I agree with Skip's idea but I would like to suggest > including boxed > > >> arrays or boxed strings in the test data set. > > >> > > > >> > I work exclusively with heterogeneous boxed arrays coming > in from SQL > > >> Server. I actually don't process pure numeric information. > One sample > > >> computation is matching a list of order by size against a > list of > > >> consumption by size. > > >> Skip replies: > > >> > > >> I think that if Alex's problem is split across multiple > processors, his > > >> matching process will entail moving some data between the > processors> >> during execution. I was trying to avoid that > issue in my pure numerical > > >> example. My thought was, if we test a process that doesn't > require any > > >> data movement other than the initial distribution and final > assembly,> >> and then find that parallel execution of that > process doesn't provide > > >> all that much efficiency gain, then it is unlikely that > processes that > > >> do require data movement between processors would be > executed more > > >> efficiently in parallel. > > >> > > >> Alex's problem has the advantage of a practical usage, so > it could be > > >> added in the test suite as a second test example of > parallel processing. > > >> However, I would expect his problem to be less amenable to > distributing> >> the processor load than the pure in-place > computational problem, due to > > >> the requirement to move data between processors during execution. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
