Hi Tomas,
you say you drain the set, do you remove elements one by one from it?
Do you need more from that set than only getting successive elements from
it?
It seems you are implementing something, which might require going lower
level or using different data structures.
I am still not really
Hi Simon -
Thanks for the detailed reply, my responses are in-line below.
~Thomas
On Wed, Oct 30, 2019 at 7:52 AM Simon Schlee wrote:
> Racket has mutable and immutable hash tables these are implemented
> differently.
> Because as a user of hash tables you have to differentiate between
Hi Thomas,
it seems to me that you may have a misleading intuition for racket's hash
tables.
Racket has mutable and immutable hash tables these are implemented
differently.
Because as a user of hash tables you have to differentiate between mutable
and immutable,
there are also different hash
Hi All,
Thanks for the information + various ideas.
The various suggest constructs provide a helpful view on different corners
of the language, but all appear to have the characteristic of throwing out
the existing hashtable structure from the map and then reconstructing it
from scratch for the
A dict doesn't guarantee unique keys, but it *does* guarantee that dict-ref
returns a single value and dict-set accepts a single value, which is really
strange to guarantee if you're not also going to guarantee unique keys.
Honestly, I think association-lists-as-dicts were a mistake. If you
> On Oct 25, 2019, at 7:28 AM, Thomas Dickerson
> wrote:
>
> For reasons that are unclear to me, hash-keys and dict-keys both return a
> list? instead of a set?(frankly, this seems like a bug in the API...).
A dict doesn't guarantee unique keys. So `dict-keys` returns a list, not a set.
I don't know of a more efficient way to convert, but depending on what
operations you want, you might be able to compute it directly on the
hash, e.g., see hash-has-key?, hash-keys-subset?, hash-union, etc. (I
didnt know about some of the functions until recently.)
On Fri, Oct 25, 2019 at 4:21 PM
Oh -- forgot to mention: if you're using an immutable hash, then
`in-immutable-hash-keys` is significantly faster than `in-hash-keys`.
I mean:
(for/set ([k (in-immutable-hash-keys h)]) k)
On Fri, Oct 25, 2019 at 4:37 PM Jon Zeppieri wrote:
>
> From a little test I just ran, building a set of
>From a little test I just ran, building a set of hash keys, using a
hash with 100,000 k/v pairs and generating the key set 100 times each:
"list->set"
cpu time: 3147 real time: 3148 gc time: 1137
"apply"
cpu time: 3205 real time: 3206 gc time: 1146
"in-hash"
cpu time: 2791 real time: 2791 gc
It also might be worth trying `(for/set ([(k v) (in-hash h)]) k)`.
On Fri, Oct 25, 2019 at 1:19 PM David Storrs wrote:
> On Fri, Oct 25, 2019 at 10:28 AM Thomas Dickerson
> wrote:
> >
> > For reasons that are unclear to me, hash-keys and dict-keys both return
> a list? instead of a set?
On Fri, Oct 25, 2019 at 10:28 AM Thomas Dickerson
wrote:
>
> For reasons that are unclear to me, hash-keys and dict-keys both return a
> list? instead of a set? (frankly, this seems like a bug in the API...).
>
> Is there a something I can do that's more efficient than just calling
> list->set?
For reasons that are unclear to me, hash-keys and dict-keys both return a
list? instead of a set? (frankly, this seems like a bug in the API...).
Is there a something I can do that's more efficient than just calling
list->set?
--
You received this message because you are subscribed to the
12 matches
Mail list logo
