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
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
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 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
).
> 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 usef
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
. And - as before - you 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 li
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
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 ow
is has two advantages:
1. 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])
must say that I am against using arrays
> in PicoLisp, and wrote it up a few years ago in:
>
>
>
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
orkaround 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 anyway.
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
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
> th
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 O(
On Tuesday 22 of February 2011 10:26:44 you wrote:
> 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! :)
>=20
> With new users, this will come up over and over aga
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
--
U
re 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 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
-
#x27;t the other and maybe
> more important point that arrays would not work with the way current
> garbage collection works? Basically, the heap would become
> non-homogeneous and fragmented, breaking the beauty, simplicity and
> efficiency of current heap management.
Well, the garb
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 h
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
> >> id
nt memory pages.
> seem to favor arrays is not efficiency, but that some algorithms
> deeply wired into our brains are more clearly represented using arrays
> instead of single linked lists.
Agree, completely.
Cheers,
Tomas
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
is alread=
y
> present in L1 cache. Otherwise, about 200...300 CPU cycles [1] will be wa=
sted
> waiting for the cache to be filled before data is available to the CPU. T=
his
> wasted time actually dominates the execution time, in pathological cases.
>
> The data will be in cache
on :(
Nice article.
> 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
illed before data is available to the CPU. This
wasted time actually dominates the execution time, in pathological cases.
The data will be in cache most of the time for small arrays, but will NOT be
in cache for larger arrays. So if you think ``for large ammouts of data arrays
will be significan
vertheless, I posted it. It might be improved in the future, and
> can be found under
>
> =C2=A0 Articles & Essays =C2=A0-> =C2=A0Array Abstinence
>
> or at the direct link "http://picolisp.com/5000/-2-1d.html";.
>
when i wear my C hat, i think arrays. when i we
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 shoul
29 matches
Mail list logo
