On Thu, May 31, 2012 at 01:38:41PM -0400, Joe Bogner wrote: > Calculating a SUM is very quick.. > > ! (bench (let Amt 0 (mapc '((This) (inc 'Amt (: Amount))) List))) > 1.152 sec
Minor optimization: You could also use 'sum' for that: (sum '((This) (: Amount)) List) > Sidebar: Is there a way to disable the interactive session from printing > the return of a statement? For example, if I do a (setq ABC L) where L is a > million items, I'd prefer the option of not having all million items print > on my console. I've worked around this by wrapping it in a prog and > returning NIL. Is there an easier way? As Tomas wrote in his answer to this thread, you could use 'nil' or 't' : (nil (longResult)) I usually prefer : (longResult) T This works because the input line may hold more than one expression, and only the value of the last expression is printed in the REPL. I use 'T' because it is the shortest to type. Usually you can also do something useful, like printing the result you are interested in, and which is produced in a side effect: : (longResult) Count : (longResult) (show (someObject)) > As a simple test to get a list of unique customers > > ! (bench (mapc '((X) (idx 'UniqueCustomers X T)) CustomerNumbers)) > 163.309 sec > > Am I doing something wrong with idx? It depends a lot on the structure of the input list 'CustomerNumbers'. I think your approach is all right if 'CustomerNumbers' is very long, but holds the numbers in random order. Then you might also use (uniq L) The 'idx' reference says: "If all elements are inserted in sorted order, the tree degenerates into a linear list." I suspect that CustomerNumbers are sorted (or nearly sorted), and contain many distinct values. Is that the case? 'idx' is a rather low-level tool, giving responsibility for optimizations to the programmer. If you know that the input list is already sorted (or at least very un-random), you could try 'balance' (balance 'UniqueCustomers CustomerNumbers) > I'm wondering if accu runs better > because I remember reading that picoLisp internally uses hashes for symbols > and properties and I think accu is using a property of the symbol to store > the values. PicoLisp hashes symbol names, but this doesn't matter here. The names hashes are used only for 'read'ing. Properties are not hashed in any way, they are searched linearly in the property list of a symbol. 'accu' uses a simple association list. It is only fast if the number of keys is not too high. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
