Re: [go-nuts] Use a hash/maphash uint64 as map key

2025-06-25 Thread Jan Mercl
On Thu, Jun 26, 2025 at 8:30 AM Robert Engels wrote: > Agreed. I’ve been away from Go for a bit - I just assumed with hash/maphash > the stdlib had a generic map… ugh. Why should the _stdlib_ have a generic map when the _language_ had a generic map since it went public in 2009? -- You receive

Re: [go-nuts] Use a hash/maphash uint64 as map key

2025-06-25 Thread Robert Engels
Agreed. I’ve been away from Go for a bit - I just assumed with hash/maphash the stdlib had a generic map… ugh. Rant… this highlights a key problem with Go. Perfect is the enemy of good. Java has had a map interface for 20 years. Millions of successful solutions have been developed. Just use it and

Re: [go-nuts] Use a hash/maphash uint64 as map key

2025-06-25 Thread 'Axel Wagner' via golang-nuts
My assumption is that OP wants to de-facto store keys in a map that are not `comparable` (e.g. use a `[]byte` as a key), without having to fully implement their own hash map. Of course, at some point we'll hopefully get #69559 to do this easily. In the me

Re: [go-nuts] Use a hash/maphash uint64 as map key

2025-06-25 Thread robert engels
but if you have the K to compare to, why not just use map[K]V and let the standard map manage the hash and duplicates - since the OP referred to hash/maphash I assume they are using keys that are comparable unless the OP is trying to write a complete custom map implementation - but I doubt that

Re: [go-nuts] Use a hash/maphash uint64 as map key

2025-06-25 Thread 'Axel Wagner' via golang-nuts
Yes, I meant map[uint64][]struct{K;V}, thanks for correcting me. On Wed, 25 Jun 2025 at 20:06, robert engels wrote: > That is not correct and will not work - what the op is talking about is if > K collides - so this is only a single K - so map[K][]struct{K;V} will only > ever have one element in

Re: [go-nuts] Use a hash/maphash uint64 as map key

2025-06-25 Thread robert engels
That is not correct and will not work - what the op is talking about is if K collides - so this is only a single K - so map[K][]struct{K;V} will only ever have one element in the array… > On Jun 25, 2025, at 12:33 PM, 'Axel Wagner' via golang-nuts > wrote: > > There are ∞ many possible hashab

[go-nuts] Re: fmap: a faster map

2025-06-25 Thread christoph...@gmail.com
By swap pop I mean that a deleted item is replaced by the last item of the group or the chain. This will indeed move items. I have implemented a new version using 8bit top hashes, tombstones, perfect match, quadratic probing and extensible hash table. It leaves items in place and might thus be

Re: [go-nuts] Use a hash/maphash uint64 as map key

2025-06-25 Thread 'Axel Wagner' via golang-nuts
There are ∞ many possible hashable Go values (in particular, all strings) and 2^64 uint64, so yes, there is a possibility of collision. How big that risk is depends on how many values you have and what the damage is, if a collision happens. Wikipedia has a nifty table: https://en.wikipedia.org/wiki

[go-nuts] gomobile - capture stdout/stderr

2025-06-25 Thread 'Tom Son' via golang-nuts
I am calling Golang library from Android like that and would like to capture stdout/stderr from my: `Somemodule.functionToCall`. I was wondering if there is any way to capture the console output. I am not sure if there is anything builtin to Gomobile that I could use. I see two potential optio

[go-nuts] Use a hash/maphash uint64 as map key

2025-06-25 Thread Pierre Durand
Is it safe to use the result of a hash/maphash (uint64) as a map key. Is there a risk of collision ? (different inputs generate the same hash) Thank you -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop rece