FAQ
Dear golang-nuts group,

I've been battling with an extremely confusing issue in the past days and I
think I have found the cause, still I don't know WHY it causes this.
Basically I have a function that takes two arrays which each contain the
same data type with two integer values and transfers a single item from one
to the other,
effectively raising the length of the receiver by 1 and lowering the length
of the other one. Here is a gist of the function used.<https://gist.github.com/b282721f40b2abf466c4>

But after hours of debugging I figured this function is the function that
triggers the weird value switches and duplications.
Sometimes, the array that get's one item taken away "loses" the item on
index 0 and receives a duplicate in a random index,
sometimes there are even multiple pointers to one memory address popping up
in any of the arrays.

I don't know of how much use this is to you, but I also uploaded my
extremely verbose debug file: Also as a gist. ;)<https://gist.github.com/b67ff95883976601e151>
This will need some explanation, but if you really want to take a look,
line 12 to 16 displays the first occurence of a Transfer-call, with the
direction "RTL" (right-to-left).
Comparing the lines 9 and 16 will result in way more differences than there
should be, the only one would be the "loss" of the item at index 4.

If anyone knows what to do, what I did wrong, I'd appreciate an answer.
Should you want more data, just ask for it, I'd be more than happy to
provide it.

--

Search Discussions

  • Minux at Nov 6, 2012 at 7:51 pm

    On Wed, Nov 7, 2012 at 3:38 AM, Node-Raptor wrote:

    Dear golang-nuts group,

    I've been battling with an extremely confusing issue in the past days and
    I think I have found the cause, still I don't know WHY it causes this.
    Basically I have a function that takes two arrays which each contain the
    same data type with two integer values and transfers a single item from one
    to the other,
    effectively raising the length of the receiver by 1 and lowering the
    length of the other one. Here is a gist of the function used.<https://gist.github.com/b282721f40b2abf466c4>

    But after hours of debugging I figured this function is the function that
    triggers the weird value switches and duplications.
    Sometimes, the array that get's one item taken away "loses" the item on
    index 0 and receives a duplicate in a random index,
    sometimes there are even multiple pointers to one memory address popping
    up in any of the arrays.

    I don't know of how much use this is to you, but I also uploaded my
    extremely verbose debug file: Also as a gist. ;)<https://gist.github.com/b67ff95883976601e151>
    This will need some explanation, but if you really want to take a look,
    line 12 to 16 displays the first occurence of a Transfer-call, with the
    direction "RTL" (right-to-left).
    Comparing the lines 9 and 16 will result in way more differences than
    there should be, the only one would be the "loss" of the item at index 4.

    If anyone knows what to do, what I did wrong, I'd appreciate an answer.
    Should you want more data, just ask for it, I'd be more than happy to
    provide it.
    Suggested reading: http://code.google.com/p/go-wiki/wiki/SliceTricks

    basically, you just want to remove one item from a slice, it is really a
    one-liner.

    --
  • Node-Raptor at Nov 6, 2012 at 7:53 pm
    Thank you, I've updated the gist in the original post.
    Sadly, the issue is still there.
    What might be worth a note is that the output is still exactly the same, so
    these weird values seem to have a pattern.
    I just don't have any clue which one and why...

    Am Dienstag, 6. November 2012 20:44:55 UTC+1 schrieb minux:
    Suggested reading: http://code.google.com/p/go-wiki/wiki/SliceTricks

    basically, you just want to remove one item from a slice, it is really a
    one-liner.
    --
  • Bryanturley at Nov 6, 2012 at 8:16 pm

    On Tuesday, November 6, 2012 1:53:14 PM UTC-6, Node-Raptor wrote:
    Thank you, I've updated the gist in the original post.
    Sadly, the issue is still there.
    What might be worth a note is that the output is still exactly the same,
    so these weird values seem to have a pattern.
    I just don't have any clue which one and why...
    gonna need more info, can you reproduce and post it on/from
    http://play.golang.org ?

    --
  • Node-Raptor at Nov 6, 2012 at 9:00 pm
    Actually, I can't.
    I've replicated the array I'm using in my program, I did all the switches
    and transfers as the debug message in the OP states and I'm using the same
    function for the verbose output.
    Might want to take a look? ;) <http://play.golang.org/p/UkQu056TnN>
    But on the golang playground *it works as supposed*, while locally it gives
    me this weirdness.
    Any advice on what to do? The go version on my PC shouldn't be too old,
    it's only been a month since I started.

    Am Dienstag, 6. November 2012 21:09:56 UTC+1 schrieb bryanturley:

    gonna need more info, can you reproduce and post it on/from
    http://play.golang.org ?
    --
  • Dave Cheney at Nov 6, 2012 at 9:03 pm
    Can you make the problem simpler?

    Start with two slices of ints from 1 to 10, then run your transfer
    function and compare the results with an expected, reflect.DeepEquals
    may be of use here.

    Dave

    On Wed, Nov 7, 2012 at 8:00 AM, Node-Raptor
    wrote:
    Actually, I can't.
    I've replicated the array I'm using in my program, I did all the switches
    and transfers as the debug message in the OP states and I'm using the same
    function for the verbose output.
    Might want to take a look? ;)
    But on the golang playground it works as supposed, while locally it gives me
    this weirdness.
    Any advice on what to do? The go version on my PC shouldn't be too old, it's
    only been a month since I started.

    Am Dienstag, 6. November 2012 21:09:56 UTC+1 schrieb bryanturley:

    gonna need more info, can you reproduce and post it on/from
    http://play.golang.org ?
    --
    --
  • Node-Raptor at Nov 6, 2012 at 9:15 pm
    Using an array with fewer values works, in fact, the one I tested with more
    (20 values each) worked too.
    Locally this function is used in a more advanced context and called by a
    function used to optimize the distribution of values between the two
    arrays,
    determining the switch/transfer that would have the best effect and
    executing it at the end of a loop, that runs until a certain goal is
    reached.
    Also, the values are read from files. But as they are correctly converted
    to integers before the optimization process I don't think that matters.

    I've added a fmt.Println(reflect.DeepEqual(master.second[0],
    master.second[1])) to the end of the main()-function
    of the local program with the debug file linked above, and it returns true.
    :/

    Am Dienstag, 6. November 2012 22:03:40 UTC+1 schrieb Dave Cheney:
    Can you make the problem simpler?

    Start with two slices of ints from 1 to 10, then run your transfer
    function and compare the results with an expected, reflect.DeepEquals
    may be of use here.

    Dave
    --
  • Peter at Nov 6, 2012 at 9:12 pm
    Could you show us how the slices of master are initialised? Is it as in
    http://play.golang.org/p/UkQu056TnN ?
    If they refer to the same underlying array, you may have problems.
    On Tuesday, 6 November 2012 19:38:27 UTC, Node-Raptor wrote:

    Dear golang-nuts group,

    I've been battling with an extremely confusing issue in the past days and
    I think I have found the cause, still I don't know WHY it causes this.
    Basically I have a function that takes two arrays which each contain the
    same data type with two integer values and transfers a single item from one
    to the other,
    effectively raising the length of the receiver by 1 and lowering the
    length of the other one. Here is a gist of the function used.<https://gist.github.com/b282721f40b2abf466c4>

    But after hours of debugging I figured this function is the function that
    triggers the weird value switches and duplications.
    Sometimes, the array that get's one item taken away "loses" the item on
    index 0 and receives a duplicate in a random index,
    sometimes there are even multiple pointers to one memory address popping
    up in any of the arrays.

    I don't know of how much use this is to you, but I also uploaded my
    extremely verbose debug file: Also as a gist. ;)<https://gist.github.com/b67ff95883976601e151>
    This will need some explanation, but if you really want to take a look,
    line 12 to 16 displays the first occurence of a Transfer-call, with the
    direction "RTL" (right-to-left).
    Comparing the lines 9 and 16 will result in way more differences than
    there should be, the only one would be the "loss" of the item at index 4.

    If anyone knows what to do, what I did wrong, I'd appreciate an answer.
    Should you want more data, just ask for it, I'd be more than happy to
    provide it.
    --
  • Node-Raptor at Nov 6, 2012 at 9:26 pm
    This <https://gist.github.com/1118e2779bbd50e94030> demonstrates how I read
    the files and initially create the two arrays, in the local example there
    is a bit error catching but basically that's it.
    And here is an example input file<https://gist.github.com/3a5bc17bbcf16a8ea1bc>,
    so you can see how it's supposed to work.

    Am Dienstag, 6. November 2012 22:12:08 UTC+1 schrieb Peter:
    Could you show us how the slices of master are initialised? Is it as in
    http://play.golang.org/p/UkQu056TnN ?
    If they refer to the same underlying array, you may have problems.
    On Tuesday, 6 November 2012 19:38:27 UTC, Node-Raptor wrote:

    Dear golang-nuts group,

    I've been battling with an extremely confusing issue in the past days and
    I think I have found the cause, still I don't know WHY it causes this.
    Basically I have a function that takes two arrays which each contain the
    same data type with two integer values and transfers a single item from one
    to the other,
    effectively raising the length of the receiver by 1 and lowering the
    length of the other one. Here is a gist of the function used.<https://gist.github.com/b282721f40b2abf466c4>

    But after hours of debugging I figured this function is the function that
    triggers the weird value switches and duplications.
    Sometimes, the array that get's one item taken away "loses" the item on
    index 0 and receives a duplicate in a random index,
    sometimes there are even multiple pointers to one memory address popping
    up in any of the arrays.

    I don't know of how much use this is to you, but I also uploaded my
    extremely verbose debug file: Also as a gist. ;)<https://gist.github.com/b67ff95883976601e151>
    This will need some explanation, but if you really want to take a look,
    line 12 to 16 displays the first occurence of a Transfer-call, with the
    direction "RTL" (right-to-left).
    Comparing the lines 9 and 16 will result in way more differences than
    there should be, the only one would be the "loss" of the item at index 4.

    If anyone knows what to do, what I did wrong, I'd appreciate an answer.
    Should you want more data, just ask for it, I'd be more than happy to
    provide it.
    --
  • Peter at Nov 6, 2012 at 9:32 pm
    Your split() function means that the two slices point to the same
    underlying array :(
    On Tuesday, 6 November 2012 21:26:05 UTC, Node-Raptor wrote:

    This <https://gist.github.com/1118e2779bbd50e94030> demonstrates how I
    read the files and initially create the two arrays, in the local example
    there is a bit error catching but basically that's it.
    And here is an example input file<https://gist.github.com/3a5bc17bbcf16a8ea1bc>,
    so you can see how it's supposed to work.

    Am Dienstag, 6. November 2012 22:12:08 UTC+1 schrieb Peter:
    Could you show us how the slices of master are initialised? Is it as in
    http://play.golang.org/p/UkQu056TnN ?
    If they refer to the same underlying array, you may have problems.
    On Tuesday, 6 November 2012 19:38:27 UTC, Node-Raptor wrote:

    Dear golang-nuts group,

    I've been battling with an extremely confusing issue in the past days
    and I think I have found the cause, still I don't know WHY it causes this.
    Basically I have a function that takes two arrays which each contain the
    same data type with two integer values and transfers a single item from one
    to the other,
    effectively raising the length of the receiver by 1 and lowering the
    length of the other one. Here is a gist of the function used.<https://gist.github.com/b282721f40b2abf466c4>

    But after hours of debugging I figured this function is the function
    that triggers the weird value switches and duplications.
    Sometimes, the array that get's one item taken away "loses" the item on
    index 0 and receives a duplicate in a random index,
    sometimes there are even multiple pointers to one memory address popping
    up in any of the arrays.

    I don't know of how much use this is to you, but I also uploaded my
    extremely verbose debug file: Also as a gist. ;)<https://gist.github.com/b67ff95883976601e151>
    This will need some explanation, but if you really want to take a look,
    line 12 to 16 displays the first occurence of a Transfer-call, with the
    direction "RTL" (right-to-left).
    Comparing the lines 9 and 16 will result in way more differences than
    there should be, the only one would be the "loss" of the item at index 4.

    If anyone knows what to do, what I did wrong, I'd appreciate an answer.
    Should you want more data, just ask for it, I'd be more than happy to
    provide it.
    --
  • Peter at Nov 6, 2012 at 9:50 pm
    If I may elaborate, you probably want to use a copy() to make sure the two
    slices are independent.

    http://play.golang.org/p/fqGJY8wxKn attempts to show it, although I may
    have mucked up your lengths. Note that (evenNumber + 1) / 2 == evenNumber /
    2 for evenNumber >= 0.

    Aside: can we get a font on the playground that distinguishes l and 1
    please.
    On Tuesday, 6 November 2012 21:32:42 UTC, Peter wrote:

    Your split() function means that the two slices point to the same
    underlying array :(
    On Tuesday, 6 November 2012 21:26:05 UTC, Node-Raptor wrote:

    This <https://gist.github.com/1118e2779bbd50e94030> demonstrates how I
    read the files and initially create the two arrays, in the local example
    there is a bit error catching but basically that's it.
    And here is an example input file<https://gist.github.com/3a5bc17bbcf16a8ea1bc>,
    so you can see how it's supposed to work.

    Am Dienstag, 6. November 2012 22:12:08 UTC+1 schrieb Peter:
    Could you show us how the slices of master are initialised? Is it as in
    http://play.golang.org/p/UkQu056TnN ?
    If they refer to the same underlying array, you may have problems.
    On Tuesday, 6 November 2012 19:38:27 UTC, Node-Raptor wrote:

    Dear golang-nuts group,

    I've been battling with an extremely confusing issue in the past days
    and I think I have found the cause, still I don't know WHY it causes this.
    Basically I have a function that takes two arrays which each contain
    the same data type with two integer values and transfers a single item from
    one to the other,
    effectively raising the length of the receiver by 1 and lowering the
    length of the other one. Here is a gist of the function used.<https://gist.github.com/b282721f40b2abf466c4>

    But after hours of debugging I figured this function is the function
    that triggers the weird value switches and duplications.
    Sometimes, the array that get's one item taken away "loses" the item on
    index 0 and receives a duplicate in a random index,
    sometimes there are even multiple pointers to one memory address
    popping up in any of the arrays.

    I don't know of how much use this is to you, but I also uploaded my
    extremely verbose debug file: Also as a gist. ;)<https://gist.github.com/b67ff95883976601e151>
    This will need some explanation, but if you really want to take a look,
    line 12 to 16 displays the first occurence of a Transfer-call, with the
    direction "RTL" (right-to-left).
    Comparing the lines 9 and 16 will result in way more differences than
    there should be, the only one would be the "loss" of the item at index 4.

    If anyone knows what to do, what I did wrong, I'd appreciate an answer.
    Should you want more data, just ask for it, I'd be more than happy to
    provide it.
    --
  • Bryanturley at Nov 6, 2012 at 9:58 pm
    Here is the concept Peter is trying to illustrate, I didn't want to
    attempt to fix the original code heh ;)

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

    --
  • Francesc Campoy Flores at Nov 7, 2012 at 5:44 pm
    Hi Peter,

    About the difference between 1 and l, this is what I'm seeing, which is
    pretty distinct IMHO

    [image: Inline image 1]

    Are you seeing the same? or maybe there's an issue with the fonts

    On Tue, Nov 6, 2012 at 1:49 PM, Peter wrote:

    If I may elaborate, you probably want to use a copy() to make sure the two
    slices are independent.

    http://play.golang.org/p/fqGJY8wxKn attempts to show it, although I may
    have mucked up your lengths. Note that (evenNumber + 1) / 2 == evenNumber /
    2 for evenNumber >= 0.

    Aside: can we get a font on the playground that distinguishes l and 1
    please.

    On Tuesday, 6 November 2012 21:32:42 UTC, Peter wrote:

    Your split() function means that the two slices point to the same
    underlying array :(
    On Tuesday, 6 November 2012 21:26:05 UTC, Node-Raptor wrote:

    This <https://gist.github.com/1118e2779bbd50e94030> demonstrates how I
    read the files and initially create the two arrays, in the local example
    there is a bit error catching but basically that's it.
    And here is an example input file<https://gist.github.com/3a5bc17bbcf16a8ea1bc>,
    so you can see how it's supposed to work.

    Am Dienstag, 6. November 2012 22:12:08 UTC+1 schrieb Peter:
    Could you show us how the slices of master are initialised? Is it as in
    http://play.golang.org/p/**UkQu056TnN<http://play.golang.org/p/UkQu056TnN>
    ?
    If they refer to the same underlying array, you may have problems.
    On Tuesday, 6 November 2012 19:38:27 UTC, Node-Raptor wrote:

    Dear golang-nuts group,

    I've been battling with an extremely confusing issue in the past days
    and I think I have found the cause, still I don't know WHY it causes this.
    Basically I have a function that takes two arrays which each contain
    the same data type with two integer values and transfers a single item from
    one to the other,
    effectively raising the length of the receiver by 1 and lowering the
    length of the other one. Here is a gist of the function used.<https://gist.github.com/b282721f40b2abf466c4>

    But after hours of debugging I figured this function is the function
    that triggers the weird value switches and duplications.
    Sometimes, the array that get's one item taken away "loses" the item
    on index 0 and receives a duplicate in a random index,
    sometimes there are even multiple pointers to one memory address
    popping up in any of the arrays.

    I don't know of how much use this is to you, but I also uploaded my
    extremely verbose debug file: Also as a gist. ;)<https://gist.github.com/b67ff95883976601e151>
    This will need some explanation, but if you really want to take a
    look, line 12 to 16 displays the first occurence of a Transfer-call, with
    the direction "RTL" (right-to-left).
    Comparing the lines 9 and 16 will result in way more differences than
    there should be, the only one would be the "loss" of the item at index 4.

    If anyone knows what to do, what I did wrong, I'd appreciate an
    answer. Should you want more data, just ask for it, I'd be more than happy
    to provide it.
    --


    --
    --
    Francesc

    --
  • Bryanturley at Nov 7, 2012 at 5:49 pm

    On Wednesday, November 7, 2012 11:44:52 AM UTC-6, Francesc Campoy Flores wrote:

    Hi Peter,

    About the difference between 1 and l, this is what I'm seeing, which is
    pretty distinct IMHO

    [image: Inline image 1]

    Are you seeing the same? or maybe there's an issue with the fonts
    1 and l are quite distinct for me on the playground. What browser/os (for
    fonts) are you using peter?
    I am firefox 15.0.1 in fedora 17 or 16 can't remember...

    --
  • Peter at Nov 7, 2012 at 6:55 pm
    <https://lh3.googleusercontent.com/-AR5h8DTlBLE/UJqtnijah8I/AAAAAAAAAMM/05zLWOqMm04/s1600/playground_font.png>
    For some reason the "Menlo" font isn't working for me.
    Chrome Version 22.0.1229.94
    Linux 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64
    x86_64 x86_64 GNU/Linux
    Distributor ID: Ubuntu
    Description: Ubuntu 12.04.1 LTS
    Release: 12.04
    Codename: precise

    Maybe I've done something wrong :(
    On Wednesday, 7 November 2012 17:49:14 UTC, bryanturley wrote:

    On Wednesday, November 7, 2012 11:44:52 AM UTC-6, Francesc Campoy Flores
    wrote:
    Hi Peter,

    About the difference between 1 and l, this is what I'm seeing, which is
    pretty distinct IMHO

    [image: Inline image 1]

    Are you seeing the same? or maybe there's an issue with the fonts
    1 and l are quite distinct for me on the playground. What browser/os (for
    fonts) are you using peter?
    I am firefox 15.0.1 in fedora 17 or 16 can't remember...
    --
  • Node-Raptor at Nov 7, 2012 at 5:20 pm
    *Thank you all so much!*
    It works now, using copy. Apparently, the len()-assignments I used on the
    underlying array were still relative, so when modifying the length of the
    individual array's, everything got messed up.
    I really don't know how long I would've taken without you, considering I
    was looking at the completely wrong part of the code.

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 6, '12 at 7:38p
activeNov 7, '12 at 6:55p
posts16
users6
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase