I support the last idea about that isn't necessary to touch core
language, and if someone needs array support, it could be implemented
the same way as e.g. "ext" and "ht" libraries.
Best regards,
Mansur
--- skipped ---
I don't think it's necessary to add arrays to the core language however,
g
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
> 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
On Tue, Feb 17, 2015 at 2:30 AM, Denis Fourt wrote:
> If I may provide an advice, in "Purely Functional Data Structures" from
> Chris Okasaki (Cambridge University Press, 1998), you will find various data
> structures based on lists which come close to regular arrays in term of
> access performanc
Hi Enrique,
> If we have a linear list for which we need fast access, we can do
> another thing: Instead of substituting the list with an array
> structure, we can keep the list and use an array as a helper of the
> original list.
Do you think this is a good idea?
OK, you have a list then, wher
> Subject: Re: A pragmatic solution to using arrays in picolisp
> Date: Mon, 16 Feb 2015 20:19:40 +0100
>
> I've changed my mind.
>
> If we have a linear list for which we need fast access, we can do
> another thing: Instead of substituting the list with an array
&g
On 2015-02-15 02:29, Alex Gilding wrote:
> One cheap workaround for this would simply be to have a "nogc" function that
> temporarily disables the GC around a piece of code. If you're crunching data
> in
> arrays, you probably want to isolate that operation in its own little
> high-performance blo
I've changed my mind.
If we have a linear list for which we need fast access, we can do
another thing: Instead of substituting the list with an array
structure, we can keep the list and use an array as a helper of the
original list.
That means that instead of storing the elements of a linear lis
> thanks for your ideas and elaborations!
>
thank you for having created picolisp
> Personally, I must say t
Hi Enrique,
thanks for your ideas and elaborations!
Personally, I must say that I am against using arrays in PicoLisp, and
wrote it up a few years ago in:
http://picolisp.com/wiki/?arrayAbstinence
Can you give me an example where you need a list with 65536 elements, in
a Lisp program? Normal
> 2) I suppose that the garbage collector would have to keep track of
> all those CELL pointers in the array, that are outside of the reach of
> the picolisp symbol table. That would be the price to pay, I think
> a smaller price than adding another datatype.
>
>
One cheap workaround for this would
1) A pragmatic solution
2) Some timing results and a workaround
1) A PRAGMATIC SOLUTION
---
Is there a price to be paid for having arrays in the language?
Well, if the picolisp machine has to be changed, in order to support
another data type, more tag bits, then I would say
12 matches
Mail list logo
