Why is false returned before the triggering variable equals the triggering value in Ruby? almostIncreasingSequence Codefights

Question

One of the tools I'm using to improve coding is Codefights. I've been stuck on the same problem for several days now and could use some help figuring it out. Can anyone tell me what I'm doing wrong here?

Here are the instructions from CodeFights:

Given a sequence of integers as an array, determine whether it is possible to obtain a strictly increasing sequence by removing no more than one element from the array.

Example

For sequence = [1, 3, 2, 1], the output should be almostIncreasingSequence(sequence) = false;

There is no one element in this array that can be removed in order to get a strictly increasing sequence.

For sequence = [1, 3, 2], the output should be almostIncreasingSequence(sequence) = true.

You can remove 3 from the array to get the strictly increasing sequence [1, 2]. Alternately, you can remove 2 to get the strictly increasing sequence [1, 3].

Input/Output

[time limit] 4000ms (rb) [input] array.integer sequence

Constraints: 2 ≤ sequence.length ≤ 105, -105 ≤ sequence[i] ≤ 105.

[output] boolean

Return true if it is possible to remove one element from the array in order to get a strictly increasing sequence, otherwise return false.

Below is the code I'm trying. I dropped in puts "#{prev}" a few times to see what prev is set to originally, after a 1 is added to wrong and at the very end, so the last prev recorded.

def almostIncreasingSequence(sequence)
  prev = [sequence[0], sequence[1]].min
  puts "#{prev}"
  wrong = 0
  (sequence.length - 1).times do |num|
    if prev < sequence[num + 1]
      prev = sequence[num + 1]
    else
      wrong += 1
      return false if wrong == 2
      puts "#{prev}"
    end
  end
  puts "#{prev}"
  true
end

This is the only test that won't pass right now:

(almostIncreasingSequence([1, 2, 3, 4, 99, 5, 6])

This should be true because 99 can be pulled out and the increasing sequence can continue. But false is being returned seemingly after wrong is only added to once.

The code should return false if wrong == 2 From the puts "#{prev}" output, I can see that prev originates at 1 and a wrong is triggered when 99 is more than 5 and since wrong should only be at 1 I don't understand why it returns false immediately. I can get this test to pass if I set prev = sequence[num - 1] after a wrong is added to the first time, but then a lot of other tests won't pass. Here is a list of the other tests I'm trying. Most are the tests that Codefights requires you to pass before you can move to the next practice code.

(almostIncreasingSequence([1, 3, 2])) #true
(almostIncreasingSequence([1, 2, 1, 2])) #false
(almostIncreasingSequence([10, 1, 2, 3, 4, 5])) #true
(almostIncreasingSequence([0, -2, 5, 6]) )#true
(almostIncreasingSequence([1, 2, 3, 4, 5, 3, 5, 6])) #false
(almostIncreasingSequence([40, 50, 60, 10, 20, 30])) #false
(almostIncreasingSequence([1, 2, 3, 4, 3, 6])) #true
(almostIncreasingSequence([100, 200, 300, 400, 99, 500, 600])) #true
(almostIncreasingSequence([1, 3, 2, 1])) #false
(almostIncreasingSequence([1, 4, 10, 4, 2])) #false
(almostIncreasingSequence( [1, 1, 1, 2, 3])) #false
(almostIncreasingSequence([1, 1])) #true
(almostIncreasingSequence([10, 1, 2, 3, 4, 5, 6, 1])) #false

Thanks in advance for any light you can shed on this problem.

eiko · Answer 1 · 2017-03-23T13:48:14.037

It looks like wrong is only being added once because your puts comes after the return so it's never being called. Moving it before the return reveals that wrong is in fact being incremented twice.

The core of your problem is that when you increment wrong, your prev value stays set to 99 which makes every subsequent value wrong. You do need to set prev to sequence[num - 1] to prevent this from happening, but like you said, this causes errors. That's because when you remove a bad number from an array (ie [1, 2, 1, 2] -> [1, 1, 2] you need to check again to see if the two now-consecutive numbers work together, which in this case they do not.

You could fix that, but then you'd hit another error with situations like [10, 1, 2, 3, 4, 5]where your startingprev` value isn't actually your first value.

Ultimately you're going to hit a lot of bugs because the logic behind your solution is complex and unintuitive for a human to follow. You could eventually reach your answer following this method, but you might want to revisit the problem and redesign your code from scratch.

Why is false returned before the triggering variable equals the triggering value in Ruby? almostIncreasingSequence Codefights

1 Answers1