Ok there won't be many associations in this instance so thank you for the advice. 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 Dean 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:firstname.lastname@example.org?subject=Unsubscribe >>> >> >>