What is the C++ Implementation for This?

[programmingflea]

I have a Windows text file with the following info inside it:

25 05 38 26 53 04
07 45 50 33 19 34
55 25 21 30 09 39
26 11 30 12 13 41
32 23 44 11 50 39
45 30 07 44 55 54
21 10 35 46 48 27
52 41 05 53 11 50
40 38 17 43 10 54
45 27 29 12 39 31
24 42 38 02 18 09
13 43 28 06 53 30
45 47 29 30 53 13
38 45 28 48 47 36
25 34 18 06 07 55


How can I code them to break that info apart into six columns and put each column into their own array? (Like in the image below...) Kindly include pseudo-code please - so as to guide me at least...

[Banfa]

Using a standard stream if you just keep reading integers it should skip the white space in between, including newlines, so just keep reading integers and keep track of which array to add them to. Since this is C++ prefer vectors over arrays.

vector<vector<integer> > dataStore; // Vector of vectors
 
integer nextVector = 0;
 
while not EOF
{
  Read Integer from File as i
 
  dataStore[nextVector].push_back(i);
 
  nextVector++;
  if (nextVector == 6)
    nextVector = 0;
}
 
Foreach dataStore As entry
  Foreach entry As value
    print value;
 

[dev7060]

How can I code them to break that info apart into six columns and put each column into their own array? (Like in the image below...) Kindly include pseudo-code please - so as to guide me at least...

Using arrays

integer arr[m][n], i = -1, j = 0
while (!EOF)
  arr[j % m][(j++ % m) ? i : ++i] = value read from file

[Banfa]

That is a a really good attempt and writing in a single line what you should be using multiple lines for; I see the following problems

1. i is never reinitialised to 0 at the end of a row, it carries on counting up and quickly goes out of bounds, I think ? i : should be something like ? (i=0) :
2. (j++ % m) must be wrong otherwise you are going down 1 row and across 1 column in your array for nearly every integer read.
3. The value n is not used anywhere; this whole thing might work better with a single control variable k = 0; then arr[k / n][k++ % n];
4. [j % m] is unnecessary, it just causes the beginning of the array to be over-written if the file has more data than you are expecting. This may be intentional but a stop condition and an error message would be better.
5. While your operations on j in line 3 may not actually be undefined behaviour if you are using C++17 or later that is a poor assumption to make (multiple access to a single variable between sequence points where at least 1 of those accesses changes the value of the variable is undefined behaviour; C++17 added [] as sequence points).

The code is very hard to read, I have written and deleted several errors that weren't errors just from failing to get the operation clear in my head to begin with, more simpler lines of code is nearly always better then fewer more complex lines :D

[dev7060]

Thanks for the feedback. I appreciate the insights.

According to the approach I'm using, I think 'i' doesn't need to be reinitialized to 0. Modulo is taking care of the shifting.

'n' is used just for the demonstration of the maximum index value. I didn't want to use a magic number like 15.

Logic behavior may be compiler dependent (shoulda mentioned that). Although, I tested it on a bunch of online compilers. Same result.

I tend to introduce compact one-liners during competitive contests where the test cases are provided respecting a format and the main focus is to solve the problem and pass the test cases. I agree readability does matter especially in a collaborative environment. Thanks for pointing this out. I see this may rather appear complex to others. Will keep this in mind in the future for the sake of better expressiveness.

The algo is solely based on the format depicted by the OP in the post and attachment which appeared to me as a fixed number of rows and columns and the pseudo-code was posted keeping in mind the ideal environment.

Here's a run that I think works well as I expect it to

#include <iostream>
 
#include <iomanip>
 
using namespace std;
 
int main() {
  int m = 6, n = 15;
  int arr[m][n];
  int i = -1, j = 0, count = 90;
  /*
  Sample inputs:
  90 89 88 87 86 85
  84 83 82 81 80 79
  ...
  12 11 10 9  8  7
  6  5  4  3  2  1
  */
  /*
  OP: "put each column into their own array"
  https://bytes.com/attachments/attachment/10468d1612527460/untitled.jpg
  90 84 ... 12 6 ->  say a[0][0] ... a[0][14]
  89 83 ... 11 5-> say a[1][0] ... a[1][14]
  ...
  85 79 ... 1 -> say a[5][0] ... a[5][14]
  */
  while (count) {
    /* condition checks and required breaks here */
    arr[j % m][(j++ % m) ? i : ++i] = count--;
    //arr[j % m][(j++ % m) ? i : (j = 1, ++i)] = count--; //better
  }
  for (i = 0; i < 6; i++) {
    cout << "Array " << i + 1 << " : ";
    for (j = 0; j < 15; j++) {
      cout << setw(2) << arr[i][j] << " ";
    }
    cout << "\n";
  }
  return 0;
}

O/P:

[Banfa]

Excellent, now I see my post was about 70% rubbish, I was clearly not keeping the actual problem in mind as I read your post.

I don't think line 30 is better, it adds complexity without removing the need for the % in the first subscript.

I retract points 1, 2 and 4 that I made unequivocally. They are just wrong.

On point 3, the point I was trying to make n is that it is not used in the algorithm, if the file contains more data than expected then your algorithm will just run off the end of the array. You can simulate this with your test code by just changing line 10 to initialise count to say 100 while leaving line 8 alone.

I accept your point that both this and the fact you have put the algorithm on a single line stem from your competition coding; coding for production and coding for competition are 2 different things.

Point 5 still stands in its entirety, you may have tested it on several platforms but one of the most tricky things about undefined behaviour is that the system is free to do anything. That includes working as expected right up until you ship it to a customer; so it is important to be able to recognise constructs that produce it or may produce it and avoid them.

<anecdote>
Anecdote About Undefined Behaviour
Early in the 1990's I was working on a SCADA system. One of our customers reported that the computer only worked at one end of their office.

Slightly bemused we requested more details and were told that the system had been working fine for several months, then the client had decided to reorganise the office and as part of that had move our system from the eastern end of the office to the western end (a move of about 15m). When they switched it back on it crashed and continued to consistently crashed every time. So they moved the computer back to the eastern end of the office were upon it started working again without issue.

They proffered the opinion that they thought there was a Ley Line running under the western end of the office effecting operation and we need to harden our software/computer against Ley Lines.

I was dispatched to investigate, equipped with a development machine. And after a day or so's reproduction of the problem and poring over the code base I found this

void someFunction()
{
   int *p=0;
 
   // 30-40 lines of code that doesn't reference p
 
   *p = 5;
 
   // Another 30-40 lines of code that doesn't reference p
}
 

As you can see this is definitely undefined behaviour (although at the time I didn't know the term) as we are dereferencing a NULL pointer. Back in the 90s dereferencing a NULL pointer like that didn't produce the instant segmentation fault what it would today because of the segmented memory map that existed and the fact that virtual memory spaces didn't exist so there was less checking and verification.

Obviously I removed these 2 lines of code and all was good, Ley Line Hardening done. Back at the office I checked and discovered that they had been in the code for a couple of years with no problems reported.

Obviously the moral of this story is always test your software on top of a Ley Line 😁
</anecdote>

[dev7060]

On point 3, the point I was trying to make n is that it is not used in the algorithm, if the file contains more data than expected then your algorithm will just run off the end of the array. You can simulate this with your test code by just changing line 10 to initialise count to say 100 while leaving line 8 alone.

I tried covering the more than expected values aspect; the statement was rather looking complex. A separate conditional would be better.

Point 5 still stands in its entirety, you may have tested it on several platforms but one of the most tricky things about undefined behaviour is that the system is free to do anything. That includes working as expected right up until you ship it to a customer; so it is important to be able to recognise constructs that produce it or may produce it and avoid them.

Kinda sparked a new perspective to look at undefined behavior.

Anecdote About Undefined Behaviour

Interesting. Thanks for sharing.

[mh11111]

Thanks for the link here. Hope it will work best.