Arrays are very useful for numeric computing over linked lists. Contiguous blocks of linear memory are much more efficient, improving on numeric density, cache occupancy, and being able to take advantage of specific CPU vector instructions. For GPU based computing, contiguous arrays are essential and linked lists are useless, they must be scanned in linear time and no warp-level parallelization is possible.
I don't think it's necessary to add arrays to the core language however, given a sufficiently featured array library, picolisp's FFI interface can be used to provide a nice abstraction above it. This is similar to how numeric arrays are used in Python with the numpy package. Functions are provided to copy data into and out of arrays from lists, dictionaries, or files, and the actual operations on the arrays are carried out by a native C library (and often third party libraries like blas/lapack). The arrays themselves are just opaque pointers to corrected sized and memory ordered malloc'ed regions. Googling 'C array library' returns many interesting hits. Judy arrays also look very interesting: http://judy.sourceforge.net/ -Michel On Tue, Feb 17, 2015 at 9:04 AM, Enrique Sánchez <petenr...@gmail.com> wrote: > > But if you have such a redundant structure, where the array elements > > point into the list, you have a large overhead to build both the array > > and the list. > > I think that building trees take more overhead than executing a > malloc and building a linear list. (And probably more cons cells). > > > You can't do any changes (cons, insert, delete, reverse) > > without rebuilding the array. And - as before - you have to keep track > > of your arrays to know when to dispose them. > > There's no point in creating array helpers for small lists elements. > These helpers are only useful for large lists. > > Most of us always use these big arrays as global, static (in the C > sense), created at the beginning of a program, living during the whole > lifetime of a program, and being disposed of manually at the end of > the program, or automatically by the system at program end. During > their life, these arrays don't grow, the structure remains the same, > because they have the nature of an array. > > Of course I could use the allocation and disposing of small arrays at > many points in the source code with this system, as you fear, like C > and C++ programmers do. But that is hell, I would not do that. They > do that because they don't have other means. > > So the allocation and disposing using malloc() and free(), are only > made typically for a pair of big arrays at two well known points in > the source code, and that's it. > > The following is a typical program showing the use of array helpers: > > (setq *Ram (array (readFile 65536 "ram.bin")) # memory array > *PC 0 # Program pointer > *SP 16384 # Stack pointer > *Reg1 0 *Reg2 0 *Reg3 0 # general registers > *Run T ) > > (while *Run > (setq *P (nth: *Ram *PC)) # random access > (execute *P) ) > > [... here would be all the main code ...] > > (dispose *Ram) # optional > (bye) > > > For this kind of program, using trees to emulate raw memory array > functionality seems convoluted, and I guess at least 10 times slower. > Convoluted because of the emulation of a more primitive structure by > means of a more complex one. > > The most important data structure in Picolisp, the cons cell, is > nothing more than a array element, addressable by a pointer, that is > just an array index. If I want to use Picolisp to do exploratory > programming of computer interpreters, then having arrays seems > natural. > > > I'm still not convinced at all that accessing list elements by a numeric > > index is really needed, or at least justifies the effort. The mentioned > > 'hash' mechanism is alread there, in constructs like the built-in > > 'cache' function (see also the answer by Denis Fourt). > > If you consider that for building interpreters, emulating raw memory > indexes with trees is appropiate, then I don't think so. I see it > half way as convoluted as clogging the symbol table with symbols like > 'M00001, 'M00002 ... for doing that. > > Or may be you consider that trees are not appropiate for that kind of > application, as is my opinion, and your solution is to resort to > another computer language, as C, for doing that kind of programming. > In this case I would understand your choice. I would like to be able > to do that kind of low level programming in picolisp. > > The implementation effort would be about 20 lines of code. > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
