GopherT's initial program itself can be modified to suit the clarified requirement.

for(i=0; i < 3; i++)
{
   zeroctr = 0;
   for(j=i+1; j < 5; j++)
   {
      if(NumArray[i] == NumArray[j]) ++zeroctr;
   }
   if(zeroctr == 3)
   {
      // 3 & Only 3 Matches occurred. Do whatever required.
   }
}

That won't work. Consider the case where all five entries are equal.

Also, consider the case where the first three entries are equal and the remaining ones are something else.

 

My bad!
Yes. Thanks WBahn.

I just realized that zeroctr comparison should have been with 2.

Case when all five entries are equal - will show as 3 matches occurred ?!?!
In fact, when the last 3 entries are equal, and one or more of the first 2 are the same as the last 3, will show as 3 matches occurred.

Case when first 3 entries are equal and others something else, should be ok I guess, with that zeroctr correction. Right?

Following code takes care of these, hopefully!

Code:
for(i=0; i < 3; i++)
{
   zeroctr = 0;
   for(j=i+1; j < 5; j++)
   {
      if(NumArray[i] == NumArray[j]) ++zeroctr;
   }
   if(zeroctr == 2)
   {
      // 3 & Only 3 are same. Do whatever required.
   }
   if(zeroctr > 2)
      break;          // More than 3 are same. No more just 3 possible.
}

 

My bad!
Yes. Thanks WBahn.

I just realized that zeroctr comparison should have been with 2.

Case when all five entries are equal - will show as 3 matches occurred ?!?!
In fact, when the last 3 entries are equal, and one or more of the first 2 are the same as the last 3, will show as 3 matches occurred.

Case when first 3 entries are equal and others something else, should be ok I guess, with that zeroctr correction. Right?

Following code takes care of these, hopefully!

Code:
for(i=0; i < 3; i++)
{
   zeroctr = 0;
   for(j=i+1; j < 5; j++)
   {
      if(NumArray[i] == NumArray[j]) ++zeroctr;
   }
   if(zeroctr == 2)
   {
      // 3 & Only 3 are same. Do whatever required.
   }
   if(zeroctr > 2)
      break;          // More than 3 are same. No more just 3 possible.
}

This is quickly becoming patchwork code where code is added to patch weaknesses that are found. It is also invoking magic numbers that will make it very hard to maintain -- if the problem changes to there being 10 patterns matched and they want to do "whatever" if exactly four occurrences of any one pattern exist in the array, what numbers would need to be changed? And would it still work?

Then there is the issue of modularity. This code has to be a wrapper around the "whatever" code which means that the two are intimately coupled. Much better to use a design approach that decouples the two by starting with a framework of:

if (CriteriaMet(array))
   DoWhatever(array);

Now you can go off and design the CriteriaMet() function while someone else goes off and designs the DoWhatever() function (even if that someone is also you) and not have to worry about how the other function does its job.

 

This is quickly becoming patchwork code where code is added to patch weaknesses that are found. It is also invoking magic numbers that will make it very hard to maintain -- if the problem changes to there being 10 patterns matched and they want to do "whatever" if exactly four occurrences of any one pattern exist in the array, what numbers would need to be changed? And would it still work?

WBahn
Your nit-picky and "WBahn's-Way-Or-The-Highway" traits are shining through again.
RamaD does it in fewer lines of code and your response is to call it "patchwork"? And you call 8 lines of code "very hard to maintain". Who specified that the requirement may change? If they might, why not do all the programming now and allow the user to set values with switches.

Could you let me know your scale of
- very hard to maintain
- hard to maintain
- maintainable
- easy to maintain?

And, where do your 11 lines of code fall on this scale? Even if it is awkward to you, I've never heard of 8 lines of code described as "very hard to maintain" when the goal is clearly available a few posts above.

Way to encourage creativity and participation in the hobby!

@RamaD
Nice work!

 

I'm oh so sorry for trying to point out good design practices. I guess your approach is to ignore good programming practices while learning to program with small programs and just let it bite you down the road. Well, you are free to that. I prefer to point out when someone is heading down a path that is pulling them incrementally toward poor programming practices so that they have the opportunity to see what is happening and reflect on it. Sorry you view that is such a bad thing.

 

WBahn, your points well taken.
I just started off with a brute force approach, and was improving the algo while I was just writing it. Program was more of a pseudo code for the algo. I was imagining that the OP would just pick the algo and carry on, and was never imagining a 'cut and paste'.

 

WBahn, your points well taken.
I just started off with a brute force approach, and was improving the algo while I was just writing it. Program was more of a pseudo code for the algo. I was imagining that the OP would just pick the algo and carry on, and was never imagining a 'cut and paste'.

Oh, that's not a problem at all. I have no problem with starting with a brute force approach and getting something to work, no matter how ugly, and then cleaning it up and refining it later. And I have no problem with solutions that get uglier before they get prettier. I just think that it's worth pointing out when incremental ugliness (ugly creep) is seeping in and how it might be cleaned up, either now or at a later stage, for general education purposes. The more we see it pointed out, the better we get at avoiding it in the first place and thoroughly scrubbing it from our final designs at the end of the day.

 

Hi guys, thanks for the extra replies. Many thanks RamaD!

Nice to see so much passion from members.