1

So I've been trying to do some code simplification, mainly because I'm not that fond of having Nested For loops however I'm experiencing trouble trying to simplify the below code. The code does functions perfectly fine and does as intended (code below is stripped down!).

int fill{200}, wid{600}, hei{400};
for (int w{ 0 }; w < fill; w++) {
    for (int h{ 0 }; h < hei; h++) {
        int offset{ w + h * (wid + fill) }
        //Offset is used to traverse a 1d array "fill" amount of times.
        /*Before:
        000000
        000000
        000000
        000000
          After:
        110000
        110000
        110000
        110000*/
    }
}

I've tried to reproduce the same output with 1 less Loop but I either don't get the right result or I go outside of the array. So I'm wondering can it be done?

SharkBytes
  • 211
  • 4
  • 18
  • Don't you think that when you have a "perfectly working code" and troubles with coming up with a transformed version, that transformed version won't be simpler? – luk32 Oct 21 '14 at 00:08
  • 3
    What a crazy modern syntax! – k06a Oct 21 '14 at 00:11
  • 1
    Of course it can be done - every program can be rewritten with just a single while loop. But why would you want this? More to the point, you could iterate over `i = 0; i < fill*hei`, and then set `int w = i / hei; int h = i % hei;` or so... – misberner Oct 21 '14 at 00:12
  • It's great to have working code, but not when it has a nested loop, that could potentially be eliminated. Anyway I'm interest to know if it would be possible. -luk32 – SharkBytes Oct 21 '14 at 00:15
  • Why eliminate only nested loops? You can eliminate **all** loops in a program by simply swimming in the Turing Tar Pit! – Yakk - Adam Nevraumont Oct 21 '14 at 02:15

1 Answers1

2

I am not sure if I would recommend it, but for the science... there you go. It gives OK to me. The idea is simple. You combine two numbers into one with multiplication, and retrieve them via division and modulo.

Just remember to be sure not to overflow at the multiplication. I will also leave a note that I did not check if all the types are chosen correctly. For example this alone int offset{ w + h * (wid + fill) }; raises a flag to me. So the below code is just for the math/method mainly.

#include <iostream>
#include <vector>
using namespace std;

int main() {
    std::vector<int> loop1, loop2;
    int fill{200}, wid{600}, hei{400};

    for (int w{ 0 }; w < fill; w++) {
      for (int h{ 0 }; h < hei; h++) {
        int offset{ w + h * (wid + fill) };
        loop1.push_back(offset);
      }
    }

    for (int i{ 0 }; i < fill*hei; i++) {
      int w = i / hei;
      int h = i % hei;
      int offset{ w + h * (wid + fill) };
      loop2.push_back(offset);
    }

    if (loop2 == loop1) cout << "OK\n";
    else cout << "NOT OK\n";
    return 0;
}
luk32
  • 15,812
  • 38
  • 62
  • I still feel dirty. To me it brings more potential problems with not a single visible advantage, but whatever floats your boat. You are one happier programmer now. I guess it's something. – luk32 Oct 21 '14 at 00:32
  • Let's be honest, dirty is having nested loops :P – SharkBytes Oct 21 '14 at 00:34
  • With regards to advantages, using 1 less loop has increased the codes performance by 10% (measured in FPS). Doesn't sound like much but I'm going to take it regardless. – SharkBytes Oct 21 '14 at 00:42
  • Hmmm, I would image compiler optimizations would take care of this. If it actually helped that's great. – luk32 Oct 21 '14 at 00:46