sum13

[sai rama krishna]

I am working on below challenge
https://codingbat.com/prob/p127384
Return the sum of the numbers in the array, returning 0 for an empty array. Except the number 13 is very unlucky, so it does not count and numbers that come immediately after a 13 also do not count.


sum13([1, 2, 2, 1]) → 6
sum13([1, 1]) → 2
sum13([1, 2, 2, 1, 13]) → 6

I wrote my code as below

	public int sum13(int[] nums) {
		int sum = 0;
		for (int i = 0; i < nums.length; i++) {
			if (!(nums[i] == 13)) {
				sum = sum + nums[i];
			} else if (i < nums.length - 1 && (nums[i] == 13)) {
				sum = sum - nums[i] - nums[i + 1];
			}
		}
		return sum;
	}

I am failing some tests as below

Expected	Run		
sum13([1, 2, 2, 1]) → 6	6	OK	
sum13([1, 1]) → 2	2	OK	
sum13([1, 2, 2, 1, 13]) → 6	6	OK	
sum13([1, 2, 13, 2, 1, 13]) → 4	-9	X	
sum13([13, 1, 2, 13, 2, 1, 13]) → 3	-23	X	
sum13([]) → 0	0	OK	
sum13([13]) → 0	0	OK	
sum13([13, 13]) → 0	-26	X	
sum13([13, 0, 13]) → 0	-13	X	
sum13([13, 1, 13]) → 0	-13	X	
sum13([5, 7, 2]) → 14	14	OK	
sum13([5, 13, 2]) → 5	-8	X	
sum13([0]) → 0	0	OK	
sum13([13, 0]) → 0	-13	X	
other tests
X

can you please point me to mistakes i am making here in this approach?

I followed below second approach it passes all tests

	public int sum13(int[] nums) {
		int sum = 0;
		for (int i = 0; i < nums.length; i++) {
			if (nums[i] == 13) {
				i++;
				continue;
			}
			sum += nums[i];
		}
		return sum;
	}

[Campbell Ritchie]

Unlucky for some

sai rama krishna wrote:. . . I wrote my code as below . . .

That looks so complicated that is could hide any number of mistakes. The second attempt with i++; is so much simpler and more elegant
Use += rather than writing out the addition in full;
Use else instead of continue.

public int sum13(int[] numbers)
{
  int sum = 0;
  for (int i = 0; i < numbers.length; i++)
  {
    if (numbers[i] == 13)
    {
      i++;
    }
    else
    {
      sum += numbers[i];
    }
  }
  return sum;
}

[sai rama krishna]

Use += rather than writing out the addition in full;
Use else instead of continue.

thank you. I try to remember these 2 rules always
so pretty much when i think of using continue i can instead use else almost automatically right
any case where continue has to be used but not else?

[Liutauras Vilda]

sai rama krishna wrote:so pretty much when i think of using continue i can instead use else almost automatically right
any case where continue has to be used but not else?

An example, think nonsensical, but that should answer your question.

public void thinkAbout() {
    int result = 0;

    for (int i = 0; i < 10_000; i++) {
        if (i % 2 == 0) {
            result = result + 2;
        }
        else {
            result = result + 1;
        }
        result = result + 1; // bonus point for everyone
    }
}

public void thinkAbout() {
    int result = 0;

    for (int i = 0; i < 10_000; i++) {
        if (i % 2 == 0) {
            result = result + 2;
            continue;
        }
        result = result + 1;
        result = result + 1; // bonus point for everyone
    }
}

[Campbell Ritchie]

sai rama krishna wrote:. . . when i think of using continue i can instead use else almost automatically right

Not automatically. But in this case you are using continue instead of else, as I showed you.

any case where continue has to be used but not else?

There is no circumstance where continue is actually necessary, and break; is only necessary inside a switch block.

[sai rama krishna]

so both above code snippets does same thing right. instead of continue i too feel else is more readable.

continue is like short cut return skips that iteration which is bit confusing

[Piet Souris]

Campbell Ritchie wrote:
Use else instead of continue

Why? That else is causing an indent, which is not necessary.

Like with methods, as soon as I know the result, I do not want to process any further. So I use continue, break and return quite often.

[sai rama krishna]

i see you mean with continue we can have better control on code to break at appropriate time rather than continuing all other iterations of for loop etc.

[Piet Souris]

Well, I find it more clear, but as you see, other people have a different opinion. With practise, you will find out that you like some styles better than other styles. When these moments come, just pick the styles you like, and be consistent with it.

And: if you happen to work for some company, that company may have its own set of styles. Then you have no choice.

[Paul Clapham]

It's true that continue is never necessary, and it's also true that returning from the middle of a method, rather than at the end, is never necessary. But sometimes it takes some godawful extra code to make those things happen. There used to be those people who would rap your knuckles if your code returned from anywhere except the last line of code, but I'm not one of those people.

If your method is supposed to return a value, and if it rummages about for a while and finds the answer, my opinion is that it should return that answer right away instead of pretending to rummage through the rest of the data while actually ignoring it. Likewise for continue... it frequently happens that else provides the same functionality, as in pretty much everywhere the OP tried to use it. But sometimes that isn't true and continue can be more readable and understandable.

[Campbell Ritchie]

Piet Souris wrote:. . . Why? . . . .

Because in one circumstance SRK is adding the numbers, and in the other circumstance he is incrementing the loop variable. That is an if‑else to me.

[sai rama krishna]

Thank you. I also feel more comfortable with if else if as discussed here

[Campbell Ritchie]

I still like your second attempt, but please explain why you think it works. Explanation about the difference between the addition and i++; would let everybody see how you solved that exercise and that you understood the problem. If you presented that code somewhere, a few /* comments */ would be useful.

[sai rama krishna]

Return the sum of the numbers in the array, returning 0 for an empty array. Except the number 13 is very unlucky,
I think as per challenge approach 2 (forward approach) more straight forward just add all elements count of array except 13

but some challenge i saw reverse approach works better that is where i am bit confused

[Campbell Ritchie]

Did you solve this exercise by luck? This is what I think it means.

Start at beginning of array with index
while not reached end of array
   if the array element is 13
      Don't add anything
      Change the index so as to omit the next element
   else (element not 13)
      Add the element
   end-if
end-while

Line 5 corresponds to i++;

[Piet Souris]

This is incorrect, just like OPs codesnippet that passed all tests. What is the result when the array is { 13, 13, 1}? That's why the approach going backwards works.

[sai rama krishna]

So we cannot tweak approach 1 code to work right. I guess only approach 2 is solution for this challenge

[Piet Souris]

You can avoid jumps by introducing a boolean 'found13', that is set as soon as a 13 is found. The loop becomes something like:

if (...) found13 = true;
else if (found13) ...;
else ...;

[sai rama krishna]

you mean like below

	public int sum13(int[] nums) {
		int sum = 0;
		for (int i = 0; i < nums.length; i++) {
			if (!(nums[i] == 13)) {
				sum = sum + nums[i];
			} else if (i < nums.length - 1 && (nums[i] == 13)) {
				nums[i] = 0;
				nums[i + 1] = 0;
				sum = sum + nums[i] + nums[i + 1];
			}
		}
		return sum;
	}

Above passed all tests finally

[Campbell Ritchie]

sai rama krishna wrote:you mean like below . . .

No. Don't go changing the state of the parameter.

And Piet is right that it will fail with {13, 13, 1}

[sai rama krishna]

still thinking. I will update once i get some intuition on this solution

[Anna Valiaeva]

public int sum13(int[] nums) {
  int sum = 0;
  for(int i = 0; i < nums.length; i++){
    if(nums[i]!=13){
      sum+=nums[i];
    }
    else if (nums[i] == 13 && (i+1) < nums.length){
      i++;
    }
    else
    break;
  }
  return sum;
}

here is my code

[Piet Souris]

hi Anna,

welcome to the Ranch and enjoy the stay!

Next time, wrap the code in code tags:  Select the code and press the Code button. I have done this for you now.

Did you try your code on the array { 13, 13, 1}?

[Campbell Ritchie]

Piet Souris wrote:hi Anna,

welcome to the Ranch and enjoy the stay!

. . . Did you try your code on the array { 13, 13, 1}?

No, but I did, and as Piet expected, it failed.

[Carey Brown]

One thing I find interesting in all of these challenges is the number of iterations it takes in modifying the code to get it right. Often a modification breaks something that works the time before. It seems that the turn around time to detect a broken case and to try and fix it is exceedingly long and is involving too much trial and error. By the time you've gone through the cycle N times you could have written a test framework to facilitate your debugging. An example follows. Note you can add your own test cases as well as those suggested by others. A framework is semi-reusable in that the basic pattern is the same.

import java.util.Arrays;

public class TestFramework
{
	public static void main( String[] args )
	{
		TestCase[] testCases = loadTestCases();
		for( TestCase tc : testCases )
			test( tc );
	}
	
	private static void test( TestCase tc )
	{
		int result = sum13( tc.input );
		System.out.print( result != tc.expected ? "ERR " : "OK  " );
		System.out.println( "sum13( " + Arrays.toString( tc.input )
			+ " ) --> " + result + ", expecting " + tc.expected );
	}

	// CODE TO BE TESTED
	public static int sum13( int[] nums )
	{
		int sum = 0;
		for( int i = 0 ; i < nums.length ; i++ )
		{
			if( nums[i] != 13 )
			{
				sum += nums[i];
			}
			else if( nums[i] == 13 && ( i + 1 ) < nums.length )
			{
				i++;
			}
			else
				break;
		}
		return sum;
	}

	private static TestCase[] loadTestCases()
	{
		TestCase[] testCases =
		{
			new TestCase( new int[]{ 1, 2, 2, 1 }, 6 ),
			new TestCase( new int[]{ 1, 1 }, 2 ),
			new TestCase( new int[]{ 1, 2, 2, 1, 13 }, 6 ),
			new TestCase( new int[]{ 1, 2, 13, 2, 1, 13 }, 4 ),
			new TestCase( new int[]{ 13, 1, 2, 13, 2, 1, 13 }, 3 ),
			new TestCase( new int[]{ }, 0 ),
			new TestCase( new int[]{ 13 }, 0 ),
			new TestCase( new int[]{ 13, 13 }, 0 ),
			new TestCase( new int[]{ 13, 0, 13 }, 0 ),
			new TestCase( new int[]{ 13, 1, 13 }, 0 ),
			new TestCase( new int[]{ 5, 7, 2 }, 14 ),
			new TestCase( new int[]{ 5, 13, 2 }, 5 ),
			new TestCase( new int[]{ 0 }, 0 ),
			new TestCase( new int[]{ 13, 0 }, 0 ),
			new TestCase( new int[]{ 13, 13, 1 }, 0 ), // suggested
		};
		return testCases;
	}
}

class TestCase
{
	int[]	input;
	int		expected;
	public TestCase( int[] input, int expected )
	{
		this.input = input;
		this.expected = expected;
	}
}

[Campbell Ritchie]

Good idea, Carey. I would tweak that a bit: change the parameters for the test method/constructor to take (int expected, int... input) which enables you to pass 0, 13, 13, 1 rather than writing new int[]{...}. I tried the following, which returns 0 if I pass 13, 13, 1 to it on JShell:-

public int sum13(int... nums)
{
  int sum = nums.length > 0 && nums[0] != 13 ? nums[0] : 0;
  for (int i = 1; i < nums.length; i++)
  {
    if (nums[i] != 13 && nums[i - 1] != 13)
    {
      sum += nums[i];
    }
  }
  return sum;
}

What Piet noticed shows that the testing on CodingBat was in this case deficient and failed to pick up an incorrect program.

[sai rama krishna]

Thank you. your For loop and If statement and mine are pretty similar


My else statement block i am changing state of parameter as mentioned here in this thread

I like below your approach for else statement
Basically moving on by doing i++ without adding to sum

[Anna Valiaeva]

. . . Did you try your code on the array { 13, 13, 1}?

No, but I did, and as Piet expected, it failed.

public int sum13(int[] nums) {
  int sum = 0;
  for(int i = 0; i < nums.length; i++){
    if(nums[i]!=13){
      sum+=nums[i];
    }
    else if (nums[i] == 13 && (i+1) < nums.length){
      while(nums[i]==13 && (i+1) < nums.length)
      i++;
    }
    else
    break;
  }
  return sum;
}

I changed it a little

[Piet Souris]

Piet Souris wrote:You can avoid jumps by introducing a boolean 'found13', that is set as soon as a 13 is found. The loop becomes something like:

if (...) found13 = true;
else if (found13) ...;
else ...;

This is what I meant:

public static int sum13(int[] array) {
    var sum = 0;
    var found13 = false;
    for (int i: array) {
        if (i == 13) found13 = true;
        else if (found13) found13 = false;
        else sum += i;
    }
    return sum;
}

[Junilu Lacar]

Carey Brown wrote:One thing I find interesting in all of these challenges is the number of iterations it takes in modifying the code to get it right. Often a modification breaks something that works the time before. It seems that the turn around time to detect a broken case and to try and fix it is exceedingly long and is involving too much trial and error. By the time you've gone through the cycle N times you could have written a test framework to facilitate your debugging.

The tests are already provided so I'm not sure why you'd need to write your own framework.

Here's the progression for how I solved this:

public int sum13(int[] nums) {
  return 0;
}

Passes 7 tests, all others fail. This is purely coincidental though. However, this gives you a much better idea of how the program is being tested.

public int sum13(int[] nums) {
  int sum = 0;
  return sum;
}

Passes the same 7 tests. Still purely coincidental. Could have skipped directly to the next step but I'm doing TDD and I'm slowly replacing the fake hard-coded solution with one that uses variables.

public int sum13(int[] nums) {
  int sum = 0;
  for (int i : nums) {
    sum += i;
  }
  return sum;
}

Passes only 5 tests. Legitimate passes this time though. Some failures did not account for i == 13, so add that condition.

public int sum13(int[] nums) {
  int sum = 0;
  for (int i : nums) {
    if (i != 13) {
      sum += i;
    }
  }
  return sum;
}

Legitimately passes 10 tests. Failures involved previous i == 13, so add that condition in.

public int sum13(int[] nums) {
  int sum = 0;
  int last = 0;
  for (int i : nums) {
    if (i != 13 && last != 13) {
      sum += i;
    }
    last = i;
  }
  return sum;
}

Passes all tests. That's only 5 iterations in all and it took less than 2 minutes.

[Junilu Lacar]

If you were going to be picky about the code it would be 6 iterations, with the last one simply a refactoring to rename the last variable:

public int sum13(int[] nums) {
  int sum = 0;
  int prev = 0;
  for (int i : nums) {
    if (i != 13 && prev != 13) {
      sum += i;
    }
    prev = i;
  }
  return sum;
}

Reading the code (and the rest of this thread) and deciding to refactor actually took the most time: however long it was between the last edit of my previous reply and the time I started this reply.

That's the time that's actually interesting to me. How much time do we spend re-reading the code and trying to make it clearer? How much time do we spend tidying up and reorganizing and considering the implications of the decisions we leave in the code? For this particular exercise, it's interesting that it took less than 2 minutes to get a working solution but I had to read through the rest of the thread, re-read the requirements, re-read my code, then decide that "prev" would be a more apt name than "last".

[Junilu Lacar]

I made a recording to walk through the solution and explain the thought process for each step and realized that the first increment where you fake the sum returned actually covers two legitimate test cases that pass: 1) nums is empty and 2) nums only contains 0s. If that's the only input you ever get, then returning 0 would be the simplest solution.

EDIT: Now that I think about it, it's only when the array is empty that returning 0 is truly a legitimate solution/pass.

This is the problem with analyzing the thought process, sometimes you end up overthinking it.

I think the point of this for me is to gain insights on the inner workings of my brain and understanding how I get to a good solution using the shortest path possible in a systematic and logical way. So it's still trial and error but it's using the errors to make an informed decision on what the next trial should be.

Essentially:
1. Let me just try something and see what happens (wild guess trial)
2. Oh, some of the tests actually passed! Let's see why they passed
3. Ok, I understand why some of these passed now, let me write the real implementation.
4. Yeah, the test still passes so I must have understood correctly.
5. Now, why did these other tests fail?
6. Ok, now I understand why they failed, let's try something and see what happens (informed trial)
7. Go back to step 2 until all tests pass.

Here's the video of me walking & talking through the solution and thought process: https://youtu.be/HUwWjYpKPLA

[sai rama krishna]

Thank you for video. My mind works better with video than book

[Carey Brown]

Junilu Lacar wrote:The tests are already provided so I'm not sure why you'd need to write your own framework.

Because codingbat doesn't permit sprinkling code with print statements; a valuable debugging tool. Codingbat does not permit stepping through the code with an actual debugger. If you develop somewhere else, say, eclipse, then you're probably only testing the one use case that is giving you an error.

[Junilu Lacar]

I think the example walkthroughs I gave show that
1. You don't need System.out.println statements to debug
2. You don['t need a debugger to step through the code

The alternative approach can eliminate the need for the above:
1. Step the solution in one small piece at a time
2. Use one or a few similar failing tests to focus on the small piece you're stepping in
3. Run the tests frequently to verify your understanding of why the code is passing or failing

[sai rama krishna]

I agree. Array2 and Array3 are most complex out of all coding bat challenges based on my experience. I still need to do map1 and map2 and AP and recursion and functional yet

[Carey Brown]

Junilu Lacar wrote:I think the example walkthroughs I gave show that
1. You don't need System.out.println statements to debug
2. You don['t need a debugger to step through the code

The alternative approach can eliminate the need for the above:
1. Step the solution in one small piece at a time
2. Use one or a few similar failing tests to focus on the small piece you're stepping in
3. Run the tests frequently to verify your understanding of why the code is passing or failing

All well and good but that's not what I see happening with Sai's many attempts.

[Campbell Ritchie]

Congratulations

Because this thread which you started, appears in the February CodeRanch Journal, you are awarded a cow,

[sai rama krishna]

Thank you. I agree with all above points. When I am using eclipse I am using debugger and sometimes system.out.println statements