Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h3>A small UPDATE:</h3> <p>The algorithm I'm using here is a modified one you'd use for painting images. I'm pretending the array entries to be pixel data of an image and then I'm painting the image from left to right (1. LtoR) and from top to bottom (2. TtoB), however, the image data is stored from top to bottom (1. TtoB) and then from left to right (2. LtoR); IOW in a different order. Since an image can't have <em>holes</em>, this is the reason why it will not work with 5 or 6 columns. With 4 columns the output is</p> <pre><code>ACEG BDF </code></pre> <p>As an image this looks like this</p> <pre><code>OOOO OOO. </code></pre> <p>With O being a pixel of the image and . being an undefined pixel (a missing one). Missing ones may only be at the end of the image, not in the middle of it. That means it could also look like this</p> <pre><code>OOO OO. OO. OO. </code></pre> <p>All missing pixels are always at the end, if you read <strong>first</strong> from top to bottom and <strong>then</strong> from left to right, because in that case all missing pixels follow directly each other at the end. If I read the diagram TtoB and then LtoR, it must read like this "Pixel, Pixel, Pixel, Pixel, ..., Pixel, Missing, Missing, Missing, ..., Missing", it might never read "Pixel, Missing, Pixel" or "Missing, Pixel, Missing". All pixels are together and all missings are, too.</p> <p>With 5 columns, as the comment suggests, it should look like this</p> <pre><code>ACEFG BD </code></pre> <p>However, as image this would look like this</p> <pre><code>OOOOO OO... </code></pre> <p>And this is not allowed by the algorithm. If I read it TtoB and then LtoR, it will read: "Pixel, Pixel, Pixel, Pixel, Pixel, Missing, Pixel, Missing, Pixel, Missing". And as stated above, this is not allowed by the algorithm. So this simple pixel painting approach will not paint as many columns as requested if painting that many columns leads to holes in the image. In that case it will simply fill up the holes, however, this will cause less columns to be drawn.</p> <p>Let me think of a solution that will always paint the requested numbers of pixels (in a separate reply).</p> <hr> <p>You don't have to re-arrange the data in memory for that at all. Just print it in the desired order.</p> <p>Some C Code (I'm doing it extremely verbose, so everyone understands what I'm doing so. Of course this can be much more compact):</p> <pre><code>int Columns = 4; char * Array[] = {"A", "B", "C", "D", "E", "F", "G"}; int main ( int argc, char ** argv ) { // This is hacky C for quickly get the number of entries // in a static array, where size is known at compile time int arraySize = sizeof(Array) / sizeof(Array[0]); // How many rows are we going to paint? int rowsToPaint = (arraySize / Columns) + 1; int col; int row; for (row = 0; row &lt; rowsToPaint; row++) { for (col = 0; col &lt; Columns; col++) { int index = col * rowsToPaint + row; if (index &gt;= arraySize) { // Out of bounds continue; } printf("%s", Array[index]); } printf("\n"); // next row } printf("\n"); return 0; } </code></pre> <p>Note: This works fine with a value of 8 (so everything is painted within one row) and values of 4 and below (works fine with 3, 2 and 1), but it can't work with 5. This is not the fault of the algorithm, it is the fault of the constrain. </p> <pre><code>ACEFG BD </code></pre> <p>The constraint says the columns are read top to bottom to get the corrected sorted data. But above "<em>EFG</em>" is sorted and it's not top to bottom, it is left to right. Thus this algorithm has a problem. Using Columns = 3 will work</p> <pre><code>ADG BE CF </code></pre> <p>Using two will work as well</p> <pre><code>AE BF CG D </code></pre> <p>And one will put everything into one column. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload