codility:peaks: what's wrong with go implementation on performance parts testing? - algorithm

Question

Divide an array into the maximum number of same-sized blocks, each of which should contain an index P such that A[P - 1] < A[P] > A[P + 1].
My Solution: golang solution
However partly performance testing fails without reason, anyone can add some suggestion?
func Solution(A []int) int {
peaks := make([]int, 0)
for i := 1; i < len(A)-1; i++ {
if A[i] > A[i-1] && A[i] > A[i+1] {
peaks = append(peaks, i)
}
}
if len(peaks) <= 0 {
return 0
}
maxBlocks := 0
// we only loop through the possible block sizes which are less than
// the size of peaks, in other words, we have to ensure at least one
// peak inside each block
for i := 1; i <= len(peaks); i++ {
// if i is not the divisor of len(A), which means the A is not
// able to be equally divided, we ignore them;
if len(A)%i != 0 {
continue
}
// we got the block size
di := len(A) / i
peakState := 0
k := 0
// this loop is for verifying whether each block has at least one
// peak by checking the peak is inside A[k]~A[2k]-1
// if current peak is not valid, we step down the next peak until
// valid, then we move to the next block for finding valid peak;
// once all the peaks are consumed, we can verify whether all the
// blocks are valid with peak inside by checking the k value,
// if k reaches the
// final state, we can make sure that this solution is acceptable
for {
if peakState > len(peaks)-1 {
break
}
if k >= i {
break
}
if peaks[peakState] >= di*k && peaks[peakState] <= di*(k+1)-1 {
peakState++
} else {
k++
}
}
// if all peaks are checked truly inside the block, we can make
// sure this divide solution is acceptable and record it in the
// global max block size
if k == i-1 && peakState == len(peaks) {
maxBlocks = i
}
}
return maxBlocks
}

Answer 1

Thanks for adding more comments to your code. The idea seems to make sense. If the judge is reporting a wrong answer, I would try it with random data and some edge cases and a brute-force control to see if you can catch a failing example that's reasonably sized, and analyse what is wrong.
My own thought about a possible approach so far was to record a prefix array so as to tell in O(1) if a block has a peak. Add 1 if the element is a peak, 0 otherwise. For input,
1, 2, 3, 4, 3, 4, 1, 2, 3, 4, 6, 2
we would have:
1, 2, 3, 4, 3, 4, 1, 2, 3, 4, 6, 2
0 0 0 1 1 2 2 2 2 2 3 3
now when we divide, we know if a block contains a peak if its relative sum is positive:
1, 2, 3, 4, 3, 4, 1, 2, 3, 4, 6, 2
0|0 0 0 1| 1 2 2 2| 2 2 3 3
a b c d
If the first block did not contain a peak, we would expect b - a to equal 0 but instead we get 1, meaning there's a peak. This method would guarantee O(num blocks) for each divisor test.
The second thing I would try is to iterate from the smallest divisor (largest block size) to the largest divisor (smallest block size), but skip divisors that can be divided by a smaller divisor that failed validation. For example, if 2 succeeded but 3 failed, there's no way 6 can succeed, but 4 still could.
1 2 3 4 5 6 7 8 9 10 11 12
2 |
3 | |
6 | | | | |
4 x |x | x| x