choose-and-remove! operation
Arthur A. Gleckler
(11 Sep 2015 18:14 UTC)
|
Re: choose-and-remove! operation
taylanbayirli@xxxxxx
(11 Sep 2015 19:00 UTC)
|
Re: choose-and-remove! operation
Arthur A. Gleckler
(11 Sep 2015 22:10 UTC)
|
Re: choose-and-remove! operation
John Cowan
(12 Sep 2015 03:10 UTC)
|
Re: choose-and-remove! operation
Arthur A. Gleckler
(12 Sep 2015 03:16 UTC)
|
Re: choose-and-remove! operation taylanbayirli@xxxxxx (12 Sep 2015 05:12 UTC)
|
Re: choose-and-remove! operation
John Cowan
(12 Sep 2015 05:31 UTC)
|
Re: choose-and-remove! operation
John Cowan
(12 Sep 2015 03:03 UTC)
|
Re: choose-and-remove! operation
taylanbayirli@xxxxxx
(12 Sep 2015 12:43 UTC)
|
Re: choose-and-remove! operation
John Cowan
(12 Sep 2015 14:23 UTC)
|
Re: choose-and-remove! operation
taylanbayirli@xxxxxx
(12 Sep 2015 19:52 UTC)
|
Re: choose-and-remove! operation
taylanbayirli@xxxxxx
(12 Sep 2015 20:29 UTC)
|
Re: choose-and-remove! operation
Arthur A. Gleckler
(12 Sep 2015 20:51 UTC)
|
Re: choose-and-remove! operation
taylanbayirli@xxxxxx
(12 Sep 2015 22:02 UTC)
|
"Arthur A. Gleckler" <xxxxxx@speechcode.com> writes: > On Fri, Sep 11, 2015 at 12:00 PM, Taylan Ulrich Bayırlı/Kammer > <xxxxxx@gmail.com> wrote: > > OK, that's less efficient. I would question how often that > difference in efficiency is relevant though. If we absolutely want > the efficient push/pop then maybe we should name them > hash-table-update/pop! and such. Or let users define that when > they want it and leave it out of the spec. > > It's O(1) vs. O(N), which quickly matters, especially when it's > executed in a loop. I think I was a bit unclear. I meant that (pop! (hash-table-ref ht k)) could replace the hash-table-pop! that's currently in SRFI-125, so the identifier is freed up for this new hash-table-pop!. (pop! (hash-table-ref ht k)) is (theoretically) a bit less efficient than a direct hash-table-pop! (SRFI-125) because the latter can do the key lookup once and get and set its value in one step whereas the former would typically expand to the following code, which does a separate ref and then a set on the hash table: (let ((v (hash-table-ref ht k))) ((setter hash-table-ref) ht k (cdr v)) (car v)) If we can live with that, and I think we could, then hash-table-pop! in SRFI-125 can be freed up. That being said, I just noticed that (pop! (hash-table-ref ht k)) does not handle the case where 'k' is not found in 'ht'. That might need some more thought. (The extra 'x' argument to 'pop!' in my previous mail was just an error.) Taylan