(Started by [TV])

A Xector is an associative vector or list, coming from the Connection Machine, which is a highly parallel and advanced machine from the 80s, which is based on a great number of computing nodes (e.g. 64k) which are list processing elements with high-throughput, low-latency connections, and which can be used to run [LISP] in parallel.

The Xector is probably the most important structure on the machine, using it for dynamic indirections.

I would be an interesting idea to have Xectors in Tcl, since [Tcl] is related to LISP; that shouldn't be too hard, and maybe fun to try some parallel implementation (I think the CM was used for social research purposes with large datasets), let's say on Nvidia Cuda or so. Anyway if I'd work in a university and be in charge, I guess that I'd think that fun and decent research.

Google books has this interesting quote:
[http://books.google.com/books?id=6HcBQ67-Fb4C&pg=PT436&lpg=PT436&dq=Xector&source=web&ots=esIE_uIzgt&sig=2ktCPxCZ9_sKLms5O9v9kw2iq9o&hl=en&sa=X&oi=book_result&resnum=1&ct=result]

I'll think of an implementation in Tcl or maybe a [C] one for efficiency comparison, and a good working example.

[Lars H]: So, an Xector is essentially an [array] meant to support loop-level parallelisation? (One could also envision it as a [dict], but generating string representations for data distributed over 2**16 processors would be rather awkward.) I suspect existing Tcl idioms for working with arrays cannot be parallelised to that level (threads are huge compared to the tasks that would be handed out in this kind of setting), so there's a lot of work on designing APIs ahead if you undertake this.

One might also wonder how different from a [relational database] the end result is likely to be. I suspect a database table is pretty close to an Xector — at least a [RDBMS] is probably the kind of common software that is best posed to take advantage of the kind of parallelisation that xectors are meant to harness.

----
!!!!!!
%| enter categories here |%
!!!!!!