Ok there won't be many associations in this instance so thank you for the
I'd still like to understand how that idx tree hierarchy gets formed from
what looks like a load of "homogenous" insertions  (suggesting linear to
me) and how d gets to be first in a sorted tree i.e. before the numbers.
I'm not seeing it at the moment.

Best Regards

On 16 December 2016 at 20:01, Joh-Tob Schäg <johtob...@gmail.com> wrote:

> assoc '(a) '(((a) vlu_a1 vlu_a2) ((a b).vlu_ab1))) #'(a) is the key
> (vlu_a1 vlu_a2 ) to be exact. Since ((a) vlu_a1 vlu_a2) is ((a) . (vlu_a1
> vlu_a2))
> Am 17.12.2016 04:53 schrieb "dean" <deangwillia...@gmail.com>:
>> >'assoc'iation list for such purposes. That is probably the fastest, and
>> surely most lispy :)
>> Then that's what I should really be doing...I wasn't familiar with this
>> but looking on the net it seems to involve "assoc" but I've also seen "idx"
>> in the lists part of the reference.
>> I think I "get" assoc
>> i.e.
>> : (assoc '(a) '(((a) vlu_a1 vlu_a2) ((a b).vlu_ab1))) #'(a) is the key
>> for vlu_a1 and vlu_a2
>> -> ((a) vlu_a1 vlu_a2)
>> : (assoc '(a b) '(((a) vlu_a1 vlu_a2) ((a b).vlu_ab3))) #'(a b) is the
>> key just for vlu_ab3
>> -> ((a b) .vlu_ab3)
>> but I can't see how the first few insertions in the example result in
>> this structure
>> (d (2 NIL 17 NIL A) (a b c))              # 'd' already existed
>> and wonder
>> a) if idx is a possible way of doing association lists and
>> b) irrespective of the answer how the above tree comes from the
>> insertions.
>> Sorry if it's obvious and I've just missed it.
>> Best Regards
>> Dean
>> On 14 December 2016 at 19:31, Alexander Burger <a...@software-lab.de>
>> wrote:
>>> Hi Bruno,
>>> > I'm surprised that (pick '((A B) (and (= A Value) B)) ListA ListB) is
>>> > faster than (get ListB (index Value ListA)).
>>> > It's true that get traverses ListB right after a traversal of ListA,
>>> but
>>> > pick seems to do the same traversal of
>>> > the same number of elements. The only difference is that pick
>>> traverses the
>>> > two lists at the same time, instead
>>> > of sequentially.
>>> Oops, you are right! I have not tested, but the 'pick' solution is
>>> probably
>>> *slower* than the get/index one, due to the function call overhead for
>>> each
>>> element.
>>> I think I never needed such a case. Usually I try do build 'assoc'iation
>>> list
>>> for such purposes. That is probably the fastest, and surely most lispy :)
>>> - Alex
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to