FAQ
I ask for maps because for slices this seems potentially problematic: what
does "same reference" entail for a slice? Overlapping underlying arrays?
Same starting pointer regardless of whether their len matches? Same start,
end, len, and cap? And so on. Though I guess "reference-equality" would be
pretty well defined for channels.

However, for maps determining "sameness" at a reference level seems like a
much more well defined question, and a much simpler one to answer. Yet I
can't figure out a good way to do it. Perhaps with
reflect.Value.UnsafePointer (would that even work)? Either way, that seems
like overcomplicating things. The "easiest" way to do it seems to be
something like this, dreamt up on the go-nuts IRC when I asked this:
http://play.golang.org/p/6Ffxfx7zBb

But I think we can all agree that that's a rather silly and limited
solution (and to be fair wasn't suggested in earnest).

I can see why == isn't defined on maps, too many people would likely
mistake it for a deep equality test (if that was indeed the reason), but it
seems like there should be some semi-trivial way to see if two map
variables refer to the same map. Perhaps a need just wasn't seen for such
an operation? Maybe it's really a more difficult/expensive test than I
assumed?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Dave Cheney at Jul 13, 2013 at 11:53 am
    Do you see a need for this operation? Can you provide a sample of code what you need to find out if two map values are the same map?
    On 13/07/2013, at 21:35, Jsor wrote:

    I ask for maps because for slices this seems potentially problematic: what does "same reference" entail for a slice? Overlapping underlying arrays? Same starting pointer regardless of whether their len matches? Same start, end, len, and cap? And so on. Though I guess "reference-equality" would be pretty well defined for channels.

    However, for maps determining "sameness" at a reference level seems like a much more well defined question, and a much simpler one to answer. Yet I can't figure out a good way to do it. Perhaps with reflect.Value.UnsafePointer (would that even work)? Either way, that seems like overcomplicating things. The "easiest" way to do it seems to be something like this, dreamt up on the go-nuts IRC when I asked this: http://play.golang.org/p/6Ffxfx7zBb

    But I think we can all agree that that's a rather silly and limited solution (and to be fair wasn't suggested in earnest).

    I can see why == isn't defined on maps, too many people would likely mistake it for a deep equality test (if that was indeed the reason), but it seems like there should be some semi-trivial way to see if two map variables refer to the same map. Perhaps a need just wasn't seen for such an operation? Maybe it's really a more difficult/expensive test than I assumed?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jsor at Jul 13, 2013 at 12:02 pm
    Sure (both functions assume both arguments are non-nil just for brevity),

    func CopyTo(m1, m2 map[int]int) {
       if m1 ReallyEquals m2 {
          return
       }

       for key,val := range map1 {
         m2[key] = val
       }
    }

    func IsEqual(m1, m2 map[int]int) bool {
       if m1 ReallyEquals m2 {
         return true // trivial case
       } else if len(m1) != len(m2) {
          return false
       }

       for key,val := range m1 {
          if val != m2[key] {
             return false
          }
       }
       return true
    }

    In both cases it could potentially save a lot of pointless loops,
    comparisons, and/or copies. The exception might be if the standard
    compilers make this optimization already, in which case it's a moot point.
    On Saturday, July 13, 2013 4:53:29 AM UTC-7, Dave Cheney wrote:

    Do you see a need for this operation? Can you provide a sample of code
    what you need to find out if two map values are the same map?

    On 13/07/2013, at 21:35, Jsor <jrago...@gmail.com <javascript:>> wrote:

    I ask for maps because for slices this seems potentially problematic: what
    does "same reference" entail for a slice? Overlapping underlying arrays?
    Same starting pointer regardless of whether their len matches? Same start,
    end, len, and cap? And so on. Though I guess "reference-equality" would be
    pretty well defined for channels.

    However, for maps determining "sameness" at a reference level seems like a
    much more well defined question, and a much simpler one to answer. Yet I
    can't figure out a good way to do it. Perhaps with
    reflect.Value.UnsafePointer (would that even work)? Either way, that seems
    like overcomplicating things. The "easiest" way to do it seems to be
    something like this, dreamt up on the go-nuts IRC when I asked this:
    http://play.golang.org/p/6Ffxfx7zBb

    But I think we can all agree that that's a rather silly and limited
    solution (and to be fair wasn't suggested in earnest).

    I can see why == isn't defined on maps, too many people would likely
    mistake it for a deep equality test (if that was indeed the reason), but it
    seems like there should be some semi-trivial way to see if two map
    variables refer to the same map. Perhaps a need just wasn't seen for such
    an operation? Maybe it's really a more difficult/expensive test than I
    assumed?

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Jul 13, 2013 at 12:06 pm
    Respectfully, you haven't shown a problem that cannot be solved without map value equality. You just wrote two functions that would work, if map values defined an equality operator.
    On 13/07/2013, at 22:01, Jsor wrote:

    Sure (both functions assume both arguments are non-nil just for brevity),

    func CopyTo(m1, m2 map[int]int) {
    if m1 ReallyEquals m2 {
    return
    }

    for key,val := range map1 {
    m2[key] = val
    }
    }

    func IsEqual(m1, m2 map[int]int) bool {
    if m1 ReallyEquals m2 {
    return true // trivial case
    } else if len(m1) != len(m2) {
    return false
    }

    for key,val := range m1 {
    if val != m2[key] {
    return false
    }
    }
    return true
    }

    In both cases it could potentially save a lot of pointless loops, comparisons, and/or copies. The exception might be if the standard compilers make this optimization already, in which case it's a moot point.
    On Saturday, July 13, 2013 4:53:29 AM UTC-7, Dave Cheney wrote:

    Do you see a need for this operation? Can you provide a sample of code what you need to find out if two map values are the same map?
    On 13/07/2013, at 21:35, Jsor wrote:

    I ask for maps because for slices this seems potentially problematic: what does "same reference" entail for a slice? Overlapping underlying arrays? Same starting pointer regardless of whether their len matches? Same start, end, len, and cap? And so on. Though I guess "reference-equality" would be pretty well defined for channels.

    However, for maps determining "sameness" at a reference level seems like a much more well defined question, and a much simpler one to answer. Yet I can't figure out a good way to do it. Perhaps with reflect.Value.UnsafePointer (would that even work)? Either way, that seems like overcomplicating things. The "easiest" way to do it seems to be something like this, dreamt up on the go-nuts IRC when I asked this: http://play.golang.org/p/6Ffxfx7zBb

    But I think we can all agree that that's a rather silly and limited solution (and to be fair wasn't suggested in earnest).

    I can see why == isn't defined on maps, too many people would likely mistake it for a deep equality test (if that was indeed the reason), but it seems like there should be some semi-trivial way to see if two map variables refer to the same map. Perhaps a need just wasn't seen for such an operation? Maybe it's really a more difficult/expensive test than I assumed?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jsor at Jul 13, 2013 at 12:15 pm
    True, I can't think of a scenario where it is *required*. However, if you
    have, say, a Set implementation (most easily done with a map), it's not
    uncommon to have very large sets -- and it seems rather needless to force
    iterating over a 10k member set just to prove that a reference is, indeed,
    equal to itself. Again, if there is some under-the-hood optimization that
    does something like this then whether such an operation exists or not isn't
    really a big deal. It's mostly just a performance related concern.

    I'm not asking for an "=="-like operator to be added to the built-ins for
    maps. I was mostly curious if there was some way to do this with the
    standard library, hopefully avoiding reflect, but unsafe would likely be
    fine if it's the only way.
    On Saturday, July 13, 2013 5:05:48 AM UTC-7, Dave Cheney wrote:

    Respectfully, you haven't shown a problem that cannot be solved without
    map value equality. You just wrote two functions that would work, if map
    values defined an equality operator.

    On 13/07/2013, at 22:01, Jsor <jrago...@gmail.com <javascript:>> wrote:

    Sure (both functions assume both arguments are non-nil just for brevity),

    func CopyTo(m1, m2 map[int]int) {
    if m1 ReallyEquals m2 {
    return
    }

    for key,val := range map1 {
    m2[key] = val
    }
    }

    func IsEqual(m1, m2 map[int]int) bool {
    if m1 ReallyEquals m2 {
    return true // trivial case
    } else if len(m1) != len(m2) {
    return false
    }

    for key,val := range m1 {
    if val != m2[key] {
    return false
    }
    }
    return true
    }

    In both cases it could potentially save a lot of pointless loops,
    comparisons, and/or copies. The exception might be if the standard
    compilers make this optimization already, in which case it's a moot point.
    On Saturday, July 13, 2013 4:53:29 AM UTC-7, Dave Cheney wrote:

    Do you see a need for this operation? Can you provide a sample of code
    what you need to find out if two map values are the same map?

    On 13/07/2013, at 21:35, Jsor wrote:

    I ask for maps because for slices this seems potentially problematic:
    what does "same reference" entail for a slice? Overlapping underlying
    arrays? Same starting pointer regardless of whether their len matches? Same
    start, end, len, and cap? And so on. Though I guess "reference-equality"
    would be pretty well defined for channels.

    However, for maps determining "sameness" at a reference level seems like
    a much more well defined question, and a much simpler one to answer. Yet I
    can't figure out a good way to do it. Perhaps with
    reflect.Value.UnsafePointer (would that even work)? Either way, that seems
    like overcomplicating things. The "easiest" way to do it seems to be
    something like this, dreamt up on the go-nuts IRC when I asked this:
    http://play.golang.org/p/6Ffxfx7zBb

    But I think we can all agree that that's a rather silly and limited
    solution (and to be fair wasn't suggested in earnest).

    I can see why == isn't defined on maps, too many people would likely
    mistake it for a deep equality test (if that was indeed the reason), but it
    seems like there should be some semi-trivial way to see if two map
    variables refer to the same map. Perhaps a need just wasn't seen for such
    an operation? Maybe it's really a more difficult/expensive test than I
    assumed?

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Jul 13, 2013 at 12:21 pm

    On 2013/7/13 Jsor wrote:
    True, I can't think of a scenario where it is *required*. However, if you
    have, say, a Set implementation (most easily done with a map), it's not
    uncommon to have very large sets -- and it seems rather needless to force
    iterating over a 10k member set just to prove that a reference is, indeed,
    equal to itself. Again, if there is some under-the-hood optimization that
    does something like this then whether such an operation exists or not isn't
    really a big deal. It's mostly just a performance related concern.

    I'm not asking for an "=="-like operator to be added to the built-ins for
    maps. I was mostly curious if there was some way to do this with the
    standard library, hopefully avoiding reflect, but unsafe would likely be
    fine if it's the only way.
    Why do you want to use unsafe? As the name says, it is unsafe whereas
    reflect is allowed in safe contexts such as the playground:

    http://play.golang.org/p/XiHmNxuTYQ

    package main

    import "reflect"
    import "fmt"

    func main() {
         m := make(map[int]int)
         fmt.Printf("0x%x\n", reflect.ValueOf(m).Pointer())
    }

    Rémy.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jeff Juozapaitis at Jul 13, 2013 at 12:24 pm
    Well, I'm not wholly opposed to reflect, but I understand that ValueOf is
    fairly costly. I'm not clear on how costly it is though, maybe it's okay?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Atomly at Jul 13, 2013 at 8:49 pm
    No offense, but you've contrived a problem where you yourself admit that
    you have no real need to solve it and then complain that a perfectly valid
    solution to it might possibly be too inefficient-- talk about a new level
    of premature optimization! The only "sane," safe and accurate (your SECRET
    example could, though unlikely, easily give false positives) way to do this
    is via reflect.

    :: atomly ::

    [ atomly@atomly.com : www.atomly.com : http://blog.atomly.com/ ...
    [ atomiq records : new york city : +1.347.692.8661 ...
    [ e-mail atomly-news-subscribe@atomly.com for atomly info and updates ...

    On Sat, Jul 13, 2013 at 8:24 AM, Jeff Juozapaitis wrote:

    Well, I'm not wholly opposed to reflect, but I understand that ValueOf is
    fairly costly. I'm not clear on how costly it is though, maybe it's okay?

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Atomly at Jul 13, 2013 at 8:54 pm
    (If you wanted the SECRET version to be safe, you'd have to generate a
    random key, check that it doesn't exist in either map (otherwise generate a
    new random key and try again), then set it in a, check that it exists in b
    and then, finally, delete it from one or both maps. As it's written, your
    current version would falsely return true if run twice for any two maps.)

    :: atomly ::

    [ atomly@atomly.com : www.atomly.com : http://blog.atomly.com/ ...
    [ atomiq records : new york city : +1.347.692.8661 ...
    [ e-mail atomly-news-subscribe@atomly.com for atomly info and updates ...

    On Sat, Jul 13, 2013 at 4:48 PM, atomly wrote:

    No offense, but you've contrived a problem where you yourself admit that
    you have no real need to solve it and then complain that a perfectly valid
    solution to it might possibly be too inefficient-- talk about a new level
    of premature optimization! The only "sane," safe and accurate (your SECRET
    example could, though unlikely, easily give false positives) way to do this
    is via reflect.

    :: atomly ::

    [ atomly@atomly.com : www.atomly.com : http://blog.atomly.com/ ...
    [ atomiq records : new york city : +1.347.692.8661 ...
    [ e-mail atomly-news-subscribe@atomly.com for atomly info and updates ...

    On Sat, Jul 13, 2013 at 8:24 AM, Jeff Juozapaitis wrote:

    Well, I'm not wholly opposed to reflect, but I understand that ValueOf is
    fairly costly. I'm not clear on how costly it is though, maybe it's okay?

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jim Robinson at Jul 13, 2013 at 12:29 pm

    On Saturday, July 13, 2013 5:15:06 AM UTC-7, Jsor wrote:

    If you have, say, a Set implementation (most easily done with a map)

    Probably it's considered easy enough to define your own Set struct
    that holds a private map and a public Id. I would guess that might
    also be a bit easier to understand for another person reading the
    code (distinct types for a variable vs. using a the generic map/slice).

    Jim

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Jul 13, 2013 at 12:34 pm
    If you are defining a Set type, say

    type set Struct {
        mu sync.Mutex
        values map[something]struct{}
    }

    then two structs are identical if their addresses are identical, and
    thus so are the maps they contain.
    On Sat, Jul 13, 2013 at 10:29 PM, Jim Robinson wrote:
    On Saturday, July 13, 2013 5:15:06 AM UTC-7, Jsor wrote:

    If you have, say, a Set implementation (most easily done with a map)

    Probably it's considered easy enough to define your own Set struct
    that holds a private map and a public Id. I would guess that might
    also be a bit easier to understand for another person reading the
    code (distinct types for a variable vs. using a the generic map/slice).

    Jim

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David DENG at Jul 15, 2013 at 12:57 am
    There're always something that is not comparable. You can consider map as
    one of this. If you have to check, use the pointer form.

    David
    On Saturday, July 13, 2013 7:35:55 PM UTC+8, Jsor wrote:

    I ask for maps because for slices this seems potentially problematic: what
    does "same reference" entail for a slice? Overlapping underlying arrays?
    Same starting pointer regardless of whether their len matches? Same start,
    end, len, and cap? And so on. Though I guess "reference-equality" would be
    pretty well defined for channels.

    However, for maps determining "sameness" at a reference level seems like a
    much more well defined question, and a much simpler one to answer. Yet I
    can't figure out a good way to do it. Perhaps with
    reflect.Value.UnsafePointer (would that even work)? Either way, that seems
    like overcomplicating things. The "easiest" way to do it seems to be
    something like this, dreamt up on the go-nuts IRC when I asked this:
    http://play.golang.org/p/6Ffxfx7zBb

    But I think we can all agree that that's a rather silly and limited
    solution (and to be fair wasn't suggested in earnest).

    I can see why == isn't defined on maps, too many people would likely
    mistake it for a deep equality test (if that was indeed the reason), but it
    seems like there should be some semi-trivial way to see if two map
    variables refer to the same map. Perhaps a need just wasn't seen for such
    an operation? Maybe it's really a more difficult/expensive test than I
    assumed?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 13, '13 at 11:36a
activeJul 15, '13 at 12:57a
posts12
users6
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase