A Collections Framework?
in [Lisp]
|
Prev: scheme problem
Next: lisp student job offer
From: Paul Khuong on 5 May 2010 12:05 In article <hrs46v$h91$1(a)news.eternal-september.org>, Norbert_Paul <norbertpauls_spambin(a)yahoo.com> wrote: > Mario S. Mommer wrote: > > Yes, an implementation is allowed to have really bad hash tables, but > > most try to do an at least decent job. > > > > Note that the sentences in the spec allow for hash tables using /better/ > > algorithms than those in TACP, and that that is one reason for that > > wording. > > > > SBCLs hash tables are quite good and AFAIK as fast as such things > > get. I wouldn't go that far. > > You can use them as a black box without worrying. I would sugest > > you to at least try them out. If they are too slow, you can still write > > your own collection stuff :-) > > I am still worried, though. It is a pity that you cannot choose to exploit > features of your collections. At least sxhash should have been made > generic -- for example as generic function or via > (make-hash-table &key ... (hash #'sxhash)) > . You mean, like the extension described in <http://sbcl.sourceforge.net/manual/Hash-Table-Extensions.html>? :hash-function If nil (the default), a hash function based on the test argument is used, which then must be one of the standardized hash table test functions, or one for which a default hash function has been defined using sb-ext:define-hash-table-test. If hash-function is specified, the test argument can be any two argument predicate consistent with it. The hash-function is expected to return a non-negative fixnum hash code. I believe many implementations offer similar extensions. There's also GENHASH, for more portable code. Paul Khuong
From: Norbert_Paul on 5 May 2010 12:26 Paul Khuong wrote: >> I am still worried, though. It is a pity that you cannot choose to exploit >> features of your collections. At least sxhash should have been made >> generic -- for example as generic function or via >> (make-hash-table&key ... (hash #'sxhash)) >> . > > You mean, like the extension described in > <http://sbcl.sourceforge.net/manual/Hash-Table-Extensions.html>? > > :hash-function > If nil (the default), a hash function based on the test argument >... Yes, but I also want to write in compatible Common Lisp and avoid using implementation specific features.
From: D Herring on 5 May 2010 22:08 On 05/05/2010 12:26 PM, Norbert_Paul wrote: > Yes, but I also want to write in compatible Common Lisp and avoid using > implementation specific features. Don't worry so much (about efficiency or portability). Nobody cares about either until the code becomes useful... Portability is so others can adapt your code to their implementation of choice. It does not require equivalent efficiency. Lisp was designed for easy extension via macros, etc. Thus any user of your code on a non-sbcl platform could easily shadow (make-hash-table ... :hash-function f) as (make-hash-table ...) or (make-hash-table ... :some-other-key f) or ... - Daniel
From: Norbert_Paul on 6 May 2010 04:35 D Herring wrote: > Don't worry so much (about efficiency or portability). Nobody cares > about either until the code becomes useful... A quote from my initial post: "I use functions like member, [...] to design my algorithms but when they are to become productive with huge data sets I will need things like balanced-trees etc. [...]" So I am only preparing myself to worry later, when the code might show to be useful. However, I always worry about sticking to the official spec. Norbert
From: Tamas K Papp on 6 May 2010 04:41
On Thu, 06 May 2010 10:35:04 +0200, Norbert_Paul wrote: > D Herring wrote: >> Don't worry so much (about efficiency or portability). Nobody cares >> about either until the code becomes useful... > > A quote from my initial post: > > "I use functions like member, [...] > to design my algorithms but when they are to become productive with > huge data sets I will need things like balanced-trees etc. [...]" > > So I am only preparing myself to worry later, when the code might show > to be useful. However, I always worry about sticking to the official > spec. I understand the mindset, because I used to have similar worries. Then I gradually learned that CL is very easy to refactor. Worrying about what happens to your code when you get large datasets is usually a distraction: if problems arise, you will just deal with them, and it is impossible to predict what the problems will be in advance. Best, Tamas |