On Thu, Apr 13, 2017 at 09:51:14AM -0700, Lindsay John Lawrence wrote:
> The 'lack' of arrays has been a non-issue in picolisp for me so far. I've
For me too. Perhaps we should also point to
https://picolisp.com/wiki/?arrayabstinence
Also,
> 4) From what I understood one of the arg
The 'lack' of arrays has been a non-issue in picolisp for me so far. I've
been generating and manipulating some pretty substantial bitmaps using
notation like this.
2-D Array:
(setq *Img (make (do Size (link (need Size 0)
Write:
(let (Bit (rand 0 1))
(for Pt *Plot
(set (nth *Img
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
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
On Tue, Feb 17, 2015 at 2:30 AM, Denis Fourt denis.p...@hotmail.com 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
. First (the big advantage) is that we retain all the usual list
functions at our disposal, restoring Lisp programming style.
2. The patch to the garbage collector gets simpler:
for (int i=1; i=current; i++) # loop thru each array
if (void **p=arrays[i]) # only if array hasn't been
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 block
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
performance. This might be what you are looking for.
A simplified ML
have to keep track
of your arrays to know when to dispose them.
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
that I am against using arrays
in PicoLisp, and wrote it up a few years ago in:
http://picolisp.com
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
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
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 block anyway.
On Tue, Feb 22, 2011 at 08:31:43AM +0100, Alexander Burger wrote:
So, again, thanks to you all for the support! I don't have to defend
that design decision in the future again! :)
With new users, this will come up over and over again.
But now there is sort of a FAQ to point to.
// Jakob
--
there is sort of a FAQ to point to.
// Jakob
This is the FAQ: http://www.software-lab.de/doc/faq.html#arrays
;-)
/Jon
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
On Tue, Feb 22, 2011 at 11:06:57AM +0100, Jon Kleiser wrote:
But now there is sort of a FAQ to point to.
// Jakob
This is the FAQ: http://www.software-lab.de/doc/faq.html#arrays
Oh, indeed! I forgot about that one. Good to know ;-)
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software
Hi.
O(n) vs O(1) is large difference, however, there is rather simple way
out of the problem: instead of one vector L with indexes 1,...,9
L[1],...,L[9]
one can use symbols with names like
L1,...,L9
If Picolisp is fast enough with symbols, i.e. symbol access
time is
Hi Kazimir,
one can use symbols with names like
L1,...,L9
...
For a comparison, access to list is much slower:
...
(bench (do 100 (inc (nth List 5
149.812 sec
...
Generation of the symbol names has its price,
however, for lot of data, it is still faster
than list
Hi all,
in recent IRC discussions, the old requests (demands) for array support
in PicoLisp rose their ugly heads again.
I'm a bit disappointed about that, as it (or, better, its absence) is a
central issue, and it shows that I couldn't make clear at all what
PicoLisp is about.
So I felt I
.
Regarding all that, it should become clear that wasting tag bits and
efforts for such a data type and its associated functions is not a
good idea.
You mention a few times wasting tag bits. Isn't the other and maybe
more important point that arrays would not work with the way current
garbage
on lists is the same.
The PicoLisp lists live on the heap which is an array of cells in the C
terms after all. However, for lists this happens more often, depending
on how the list came into existence because the data will be quite
likely spread over many different memory pages.
seem to favor arrays
On Monday 21 of February 2011 21:54:17 you wrote:
Hi Dexen Jos=E9,
Now if you access the array in a semi-random order, so-called `cache
trashing' will ensue. Pretty much like reading random data from the
harddrive (for example from swap). The CPU, starved of data, will
idle uselessly.
I don't understand what the problem is, as far as array functionality
goes one can use (get), and for hash functionality (assoc) or (idx),
did I miss something?
During development of http://vizreader.com which is quite a big
application, I never wished I had either native arrays or hashes
23 matches
Mail list logo
