Value has been changed in method - go

I'm solving a problem in leetcode using recursion.
But, the value which is used as a parameter is changed in the method.
package main
import "fmt"
func makeCmbs(cmbs [][]int, nums []int, remains []int, k int) [][]int {
fmt.Println("==", cmbs, nums, remains, k) // (2)
if k == 0 {
cmbs = append(cmbs, nums)
fmt.Println("!", nums, cmbs)
return cmbs
}
for i, num := range remains {
fmt.Printf("-[%d] num:%d cmbs:%v remains:%v\n", i, num, cmbs, remains) // (1) cmbs here is [[1,2,3,4]]
cmbs = makeCmbs(cmbs, append(nums, num), remains[i+1:], k-1) // cmbs in makeCmbs method is [[1,2,3,5]] ???
fmt.Printf("+[%d] num:%d cmbs:%v\n", i, num, cmbs)
}
return cmbs
}
func combine(n int, k int) [][]int {
remains := make([]int, n)
for i := 0; i < n; i++ {
remains[i] = i + 1
}
return makeCmbs([][]int{}, []int{}, remains, k)
}
func main() {
combine(5, 4)
}
Bellow is its beginning of output.
== [] [] [1 2 3 4 5] 4
-[0] num:1 cmbs:[] remains:[1 2 3 4 5]
== [] [1] [2 3 4 5] 3
-[0] num:2 cmbs:[] remains:[2 3 4 5]
== [] [1 2] [3 4 5] 2
-[0] num:3 cmbs:[] remains:[3 4 5]
== [] [1 2 3] [4 5] 1
-[0] num:4 cmbs:[] remains:[4 5]
== [] [1 2 3 4] [5] 0
! [1 2 3 4] [[1 2 3 4]]
+[0] num:4 cmbs:[[1 2 3 4]]
-[1] num:5 cmbs:[[1 2 3 4]] remains:[4 5] <---- cmbs is [[1 2 3 4]]
== [[1 2 3 5]] [1 2 3 5] [] 0 <---- why [[1 2 3 5]] ???
As you can see those last two lines, cmbs [[1 2 3 4]] became [[1 2 3 5]].
Could anybody please give me a clue why cmbs value is changed in makeCmbs method?

Let start with recursion last recursive loop of calling makeCmbs
cmbs = makeCmbs(cmbs, append(nums, num), remains[i+1:], k-1)
As remains[i+1:] where the value of i at last loop will be the highest i.e
i = len(remains-1)
So it means it means i+1 is two (2) greater then len(remains-1) that is why remain[i+1] will be empty array ([]) for first two last recusrive rounds.
This is how it works. I hope I made it to the imaginative height of this problem.
UPDATE:
For the first time when k=0
start of function: num:[1 2 3 4] cmbs:[] remains:[5], k:0
So if k=0 condition is true
if k == 0 {
cmbs = append(cmbs, nums)
fmt.Printf("in side if: num:%d cmbs:%v k:%v\n", nums, cmbs, k)
return cmbs
}
that is the first return of recursion
as cmbs = [] and nums = [1 2 3 4]
cmbs = append(cmbs, nums)
Now retuned value is cmb from if condition is [[1 2 3 4]] to the for loop this line
cmbs = makeCmbs(cmbs, append(nums, num), remains[i+1:], k-1)
and here loop ends so it also return the same
[[1 2 3 4]]
But at before that recursion nums was append of nums+num that is [1 2 3 5] so that is why when it return back in the second last recursion at the same for loop call cmbs hold [1 2 3 5].
It is indeed a difficult question to image but can be solved easily with a debugger.

Related

Iterate a 2D slice of integers diagonally in go

What is an idiomatic way to iterate through a 2d slice of integers diagonally. Either the negative or positive diagonals?
Here is a playground with a 2d grid setup.
https://go.dev/play/p/Cpxg4a5HvrD
If x == y, or in this case, i == j, then it's the diagonal.
func main() {
size := 4
board := make([][]int, size)
for i := range board {
board[i] = append(board[i], make([]int, size)...)
}
for i, row := range board {
for j := range row {
board[i][j] = rand.Intn(9)
if i == j {
log.Println("diagonal:", board[i][j])
}
}
}
for _, row := range board {
fmt.Println(row)
}
}
That will print
2021/12/21 01:33:59 diagonal: 5
2021/12/21 01:33:59 diagonal: 6
2021/12/21 01:33:59 diagonal: 5
2021/12/21 01:33:59 diagonal: 8
[5 6 2 2]
[4 6 7 8]
[4 6 5 7]
[3 2 4 8]
If you want a different diagonal, you can offset one of the axis, for example x == y+1, or i == j+1
That will print
2021/12/21 01:38:07 diagonal: 4
2021/12/21 01:38:07 diagonal: 6
2021/12/21 01:38:07 diagonal: 4
[5 6 2 2]
[4 6 7 8]
[4 6 5 7]
[3 2 4 8]
For the inverse diagonals, need to use the len(board) - i, i.e.
for i, row := range board {
for j := range row {
board[i][j] = rand.Intn(9)
if len(board)-i == j {
log.Println("diagonal:", board[i][j])
}
}
}
Prints
2021/12/21 01:57:30 diagonal: 8
2021/12/21 01:57:30 diagonal: 5
2021/12/21 01:57:30 diagonal: 2
[5 6 2 2]
[4 6 7 8]
[4 6 5 7]
[3 2 4 8]

Backtracking in Go to find all paths in Directed Acyclic Graph, problem assigning paths to a solution slice (Leetcode 797)

I am attempting Leetcode 747 in Go. The problem summary:
Given a directed acyclic graph (DAG) of n nodes labeled from 0 to n -
1, find all possible paths from node 0 to node n - 1, and return them
in any order.
The graph is given as follows: graph[i] is a list of all nodes you can
visit from node i (i.e., there is a directed edge from node i to node
graph[i][j]).
This is my solution so far:
func allPathsSourceTarget(graph [][]int) [][]int {
allSolutions := [][]int{}
target := len(graph) - 1
isSolution := func(current int) bool {
return current == target
}
processSolution := func(solution []int) {
allSolutions = append(allSolutions, solution)
}
var backtrack func(currentPath []int)
backtrack = func(a []int) {
currentNode := a[len(a)-1]
if isSolution(currentNode) {
processSolution(a)
} else {
candidates := graph[currentNode]
for _, c := range candidates {
a = append(a, c)
backtrack(a)
a = a[:len(a)-1]
}
}
}
backtrack([]int{0})
return allSolutions
}
It passes 7/30 inputs but then fails on this one [[4,3,1],[3,2,4],[3],[4],[]]. The expected output for which is [[0,4],[0,3,4],[0,1,3,4],[0,1,2,3,4],[0,1,4]].
I believe the problem is how I am appending each result to the allSolutions slice. If I log the solution that comes in each time, it's what is expected, but it seems to then mutate the solutions already added.
If I add logs to the allSolutions func, for the above input, this is the output:
Solution:
[0 4]
New allSolutions:
[[0 4]]
Solution:
[0 3 4]
New allSolutions:
[[0 3] [0 3 4]]
Solution:
[0 1 3 4]
New allSolutions:
[[0 1] [0 3 4] [0 1 3 4]]
Solution:
[0 1 2 3 4]
New allSolutions:
[[0 1] [0 3 4] [0 1 2 3] [0 1 2 3 4]]
Solution:
[0 1 4]
New allSolutions:
[[0 1] [0 3 4] [0 1 4 3] [0 1 2 3 4] [0 1 4]]
I am interested in knowing why this is happening. Is it related to modifying the variable from a higher scope?
processSolution should copy its argument. Otherwise, backtrack continues to mutate the slice that it passes in, which results in the corruption that you're seeing.

re-slicing 2d slice in go

I came across a problem which needed editing several indexes of a 2-dimensional slice.
Imagine the following numbers as a 2-d slice of slices a [][]int
0 1 2 3
1 2 3 4
2 3 4 5
3 4 5 6
The problem is that I want to access and modify
0 1
1 2
As a sub-slice and I want a to be changed as well. I achieved that with this code :
sub := a[:2]
for i := range sub {
sub[i] = sub[i][:2]
}
Now fmt.Println(sub) prints [[0 1] [1 2]] But the problem is fmt.Println(a) is printing [[0 1] [1 2] [2 3 4 5] [3 4 5 6]]
The question is, how can I access this sub-slice without losing any data?
If your goal to modify the original []int slice elements when using sub, then copy the elements of a to a new slice. The code in the question modifies a directly.
sub := make([][]int, 2)
for i := range sub {
sub[i] = a[i][:2]
}
Just found a solution but don't know if it's the right way of doing so
sub := make([][]int, 2)
for i := range sub {
sub[i] = a[i][:2]
}
sub[0][0] = "876"
fmt.Println(a)
fmt.Println(sub)
now in the output I have
[[876 1 2 3] [1 2 3 4] [2 3 4 5] [3 4 5 6]]
[[876 1] [1 2]]

Confused about the depth-first-search result when using Golang

I tried to solve the 'Combination Sum' on leetcode, and the result is wrong when using test case:
[7,3,2] 18
I used C++ with the same logic and passed, but when using Golang, my result is:
[[2,2,2,2,2,2,2,2,2],[2,2,2,2,2,7,3,3],[2,2,2,2,3,7],[2,2,2,3,3,3,3],[2,2,7,7],[2,3,3,3,7],[3,3,3,3,3,3]]
and the correct one should be
[[2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,3,3],[2,2,2,2,3,7],[2,2,2,3,3,3,3],[2,2,7,7],[2,3,3,3,7],[3,3,3,3,3,3]]
the code is shown below:
import "sort"
func combinationSum(candidates []int, target int) [][]int {
result := make([][]int, 0, 0)
resultp := &result
sort.Ints(candidates)
helper(candidates, 0, target, make([]int, 0, 0), resultp, len(candidates))
return *resultp
}
func helper(nums []int, index int, target int, list []int, resultp *[][]int, length int) {
if target == 0 {
*resultp = append(*resultp, list)
return
}
for i := index; i < length; i++ {
if i != index && nums[i] == nums[i - 1] {
continue
}
if (nums[i] > target) {
break
}
helper(nums, i, target - nums[i], append(list, nums[i]), resultp, length)
}
}
Can anyone tell me why the result is incorrect, I am just confused about the [2,2,2,2,2,7,3,3] in my answer, why the 7 is before the 3 since the array has been sorted? Or anyone can tell me what mistake I have made in my code
append function may or may not modify the underlying array that your slice refers to. So you are not creating a completely new list when using append. I changed helper to match your desired behavior.
for i := index; i < length; i++ {
if i != index && nums[i] == nums[i - 1] {
continue
}
if nums[i] > target {
break
}
var newList []int
newList = append(newList, list...)
newList = append(newList, nums[i])
helper(nums, i, target - nums[i], newList, resultp, length)
}
If list has capacity, then it will be modified and therefore you are modifying your argument. Instead make a copy of list, and then append nums[i] to it.
See Go Slices: usage and internals
The line
helper(nums, i, target - nums[i], append(list, nums[i]), resultp, length)
may not perform as expected. It is called within the loop, and you are probably assuming that in the each iteration the append will always add the new member to the existing slice. If has more complex behavior that you seem not caring about enough:
If the new value fits into the current capacity of the backing array withing the slice, it is added to the current backing array. All variables assigned to that slice now report the updated content with the added new value present.
If the value does not fit, a new array is allocated. In this case further modifications of the returned slice will not change the content of the initial slice if that old value is also retained.
I am under impression that you may not expect value/content disagreement between the value returned by append and the parameter list you pass to it.
This behavior is described here (scroll to "gotcha").
So you can see the behavior a bit better by adding some print output:
https://play.golang.org/p/JPmqoAJE4S
Importantly, you can see it at this point:
0694 helper [2 3 7] 1 1 [2 2 2 2 2 2 2 3] [[2 2 2 2 2 2 2 2 2]] 3
4425 calling down 1 6 [2 2 2 2 2 2] 3
8511 helper [2 3 7] 1 3 [2 2 2 2 2 2 3] [[2 2 2 2 2 2 2 2 2]] 3
8511 calling down 1 3 [2 2 2 2 2 2 3] 3
8162 helper [2 3 7] 1 0 [2 2 2 2 2 2 3 3] [[2 2 2 2 2 2 2 2 2]] 3
8162 solution [2 2 2 2 2 2 3 3] [[2 2 2 2 2 2 2 2 2] [2 2 2 2 2 2 3 3]]
1318 calling down 1 8 [2 2 2 2 2] 3
5089 helper [2 3 7] 1 5 [2 2 2 2 2 3] [[2 2 2 2 2 2 2 2 2] [2 2 2 2 2 3 3 3]] 3
5089 calling down 1 5 [2 2 2 2 2 3] 3
4728 helper [2 3 7] 1 2 [2 2 2 2 2 3 3] [[2 2 2 2 2 2 2 2 2] [2 2 2 2 2 3 3 3]] 3
1318 calling down 2 8 [2 2 2 2 2] 7
3274 helper [2 3 7] 2 1 [2 2 2 2 2 7] [[2 2 2 2 2 2 2 2 2] [2 2 2 2 2 7 3 3]] 3
This is the sequence of actions:
You recursively call with [2 2 2 2 2 2 3] and append 3. You find that this is a valid solution and add [2 2 2 2 2 2 3 3] to the result slice.
You return up a few levels until you're back to [2 2 2 2 2] (before adding the 6th 2) and start trying to add 3s. You recursively call with [2 2 2 2 2] and append 3. Unfortunately, this overwrites your existing solution [2 2 2 2 2 2 3 3]. Since it's using the same backing array, you append 3 to the first 5 items in that slice, overwriting the 6th index in the slice you previously added to your solution set. Your second solution becomes [2 2 2 2 2 3 3 3] (note the 3 in the 6th slot)
You find that this solution set isn't going to work after a couple iterations (at [2 2 2 2 2 3 3]) because the remaining target (2) is less than the last number added (3), so you return up.
You repeat this sequence with a 7 in the 6th slot, overwriting the underlying array index again. Your second solution becomes [2 2 2 2 2 7 3 3], because you're still using the same underlying array. You find this solution also won't work, and return up.
After this point, you return up to before the list slice was greater than 4 in length (which is when the slice grew, by default it grows by doubling in size), meaning you're using a different (previous) backing array, which is why further iterations do not further change the existing solutions. By luck, none of the remaining solutions collide in a similar fashion.
This alternative print version shows you where the backing array changes (by showing where the address of the first entry changes): https://play.golang.org/p/nrgtMyqwow. As you can see, it changes when you grow beyond lengths 2, 4, and 8, but as you return upwards, you end up reverting back to different backing arrays.
The easiest solution to fix your specific problem is to copy the list slice before adding it to the solution set:
if target == 0 {
sol := make([]int, len(list))
copy(sol, list)
*resultp = append(*resultp, sol)
return
}
https://play.golang.org/p/3qTKoAumj0
[[2 2 2 2 2 2 2 2 2] [2 2 2 2 2 2 3 3] [2 2 2 2 3 7] [2 2 2 3 3 3 3] [2 2 7 7] [2 3 3 3 7] [3 3 3 3 3 3]]

Go concurrent worker routines using slice type input and output channels

I am relatively new to the Go language. Even though I don't hope so, I maybe bother you with a silly question. My apologies upfront, just in case...
Here's my example: I defined a worker() function which is called from main() as a set of concurrent Go routines. Input and output data is provided via an input and an output channel both of slice type []int. In one case everything works as expected, in the other case the result is faulty. See the comments in the code and the program output below the code.
Honestly, I don't see the actual difference between both code variants. What did I miss here? Thank you for any advice!
package main
import "fmt"
import "runtime"
func worker(x_ch <-chan []int, y_ch chan<- []int, wid int) {
for x := range x_ch {
y := x
fmt.Println(" worker", wid, "x:", x)
fmt.Println(" worker", wid, "y:", y)
y_ch <- y
}
}
func main() {
n_workers := runtime.NumCPU()
n_len := 4
n_jobs := 4
x := make([]int, n_len)
x_ch := make(chan []int, 10)
y_ch := make(chan []int, 10)
for j := 0; j < n_workers; j++ { go worker(x_ch, y_ch, j) }
for k := 0; k < n_jobs; k++ {
// variant 1: works!
x = []int{k, k, k, k}
// variant 2: doesn't work!
// for i := range x { x[i] = k }
fmt.Println("main x:", k, x)
x_ch <- x
}
close(x_ch)
for i := 0; i < n_jobs; i++ {
z := <- y_ch
fmt.Println(" main y:", i, z)
}
}
Correct output (variant 1):
main x: 0 [0 0 0 0]
main x: 1 [1 1 1 1]
main x: 2 [2 2 2 2]
main x: 3 [3 3 3 3]
worker 3 x: [3 3 3 3]
worker 3 y: [3 3 3 3]
worker 2 x: [2 2 2 2]
worker 2 y: [2 2 2 2]
worker 1 x: [0 0 0 0]
worker 1 y: [0 0 0 0]
worker 0 x: [1 1 1 1]
worker 0 y: [1 1 1 1]
main y: 0 [3 3 3 3]
main y: 1 [2 2 2 2]
main y: 2 [0 0 0 0]
main y: 3 [1 1 1 1]
Wrong output (variant 2):
main x: 0 [0 0 0 0]
main x: 1 [1 1 1 1]
main x: 2 [2 2 2 2]
main x: 3 [3 3 3 3]
worker 3 x: [3 3 3 3]
worker 3 y: [3 3 3 3]
main y: 0 [3 3 3 3]
worker 0 x: [2 2 2 2]
worker 0 y: [3 3 3 3]
main y: 1 [3 3 3 3]
worker 1 x: [1 1 1 1]
worker 1 y: [3 3 3 3]
main y: 2 [3 3 3 3]
worker 2 x: [3 3 3 3]
worker 2 y: [3 3 3 3]
main y: 3 [3 3 3 3]
The difference is that in variant 1, you're sending a different slice every time, whereas in variant 2, you're sending the same slice every time (the one created above the for loops). Without creating a new slice, you're just setting the elements of the same slice to different values, so the goroutines see whatever values happen to be in the slice when they look at it. In variant 2, main will always see [3 3 3 3] because that's the final value after you've gone through the loop 4 times. The value of a slice object contains a reference to the underlying elements, not the elements themselves. There's a good explanation of slices here.
Thanks a lot for your explanation, now I see where the problem is. I added some debug code to output the pointer addresses and the result is (with slighty reformatted output):
Variant 1:
main 0 x=[0 0 0 0] &x=0x1830e180 &x[0]=0x1830e1e0
main 1 x=[1 1 1 1] &x=0x1830e180 &x[0]=0x1830e230
main 2 x=[2 2 2 2] &x=0x1830e180 &x[0]=0x1830e270
main 3 x=[3 3 3 3] &x=0x1830e180 &x[0]=0x1830e2a0
worker 3 x=[3 3 3 3] &x=0x1830e1d0 &x[0]=0x1830e2a0
worker 3 y=[3 3 3 3] &y=0x1830e2e0 &y[0]=0x1830e2a0
main 0 y=[3 3 3 3] &y=0x1830e2d0 &y[0]=0x1830e2a0
worker 0 x=[0 0 0 0] &x=0x1830e1a0 &x[0]=0x1830e1e0
worker 0 y=[0 0 0 0] &y=0x1830e370 &y[0]=0x1830e1e0
main 1 y=[0 0 0 0] &y=0x1830e360 &y[0]=0x1830e1e0
worker 1 x=[1 1 1 1] &x=0x1830e1b0 &x[0]=0x1830e230
worker 1 y=[1 1 1 1] &y=0x1830e400 &y[0]=0x1830e230
main 2 y=[1 1 1 1] &y=0x1830e3f0 &y[0]=0x1830e230
worker 2 x=[2 2 2 2] &x=0x1830e1c0 &x[0]=0x1830e270
worker 2 y=[2 2 2 2] &y=0x1830e480 &y[0]=0x1830e270
main 3 y=[2 2 2 2] &y=0x1830e470 &y[0]=0x1830e270
Variant 2:
main 0 x=[0 0 0 0] &x=0x1830e180 &x[0]=0x1830e190
main 1 x=[1 1 1 1] &x=0x1830e180 &x[0]=0x1830e190
main 2 x=[2 2 2 2] &x=0x1830e180 &x[0]=0x1830e190
main 3 x=[3 3 3 3] &x=0x1830e180 &x[0]=0x1830e190
worker 3 x=[3 3 3 3] &x=0x1830e1d0 &x[0]=0x1830e190
worker 3 y=[3 3 3 3] &y=0x1830e2a0 &y[0]=0x1830e190
main 0 y=[3 3 3 3] &y=0x1830e290 &y[0]=0x1830e190
worker 0 x=[3 3 3 3] &x=0x1830e1a0 &x[0]=0x1830e190
worker 0 y=[3 3 3 3] &y=0x1830e330 &y[0]=0x1830e190
main 1 y=[3 3 3 3] &y=0x1830e320 &y[0]=0x1830e190
worker 1 x=[3 3 3 3] &x=0x1830e1b0 &x[0]=0x1830e190
worker 1 y=[3 3 3 3] &y=0x1830e3c0 &y[0]=0x1830e190
main 2 y=[3 3 3 3] &y=0x1830e3b0 &y[0]=0x1830e190
worker 2 x=[3 3 3 3] &x=0x1830e1c0 &x[0]=0x1830e190
worker 2 y=[3 3 3 3] &y=0x1830e440 &y[0]=0x1830e190
main 3 y=[3 3 3 3] &y=0x1830e430 &y[0]=0x1830e190

Resources