Collapsed style in StlPrettyPrint.

[ye-luo]

Proposed changes

Long vectors are lengthy. walkers_per_crowd has num_crowd elements. walkers_per_rank has num_rank elements.
num_crowd can be hundreds in CPU runs and num_ranks can be tens of thousands.
Usually these vectors has very limited distinct values and are better printed in collapsed style.
[3, 3, 2, 2] is printed as [3(x2), 2(x2)]

What type(s) of changes does this code introduce?

• New feature

Does this introduce a breaking change?

• No

What systems has this change been tested on?

epyc-server

Checklist

• Yes. This PR is up to date with current the current state of 'develop'
• Yes. Code added or changed in the PR has been clang-formatted
• Yes. This PR adds tests to cover any new code, or to catch a bug that is being fixed

[markdewing]

The internals of this operator would be better extracted to a function. More precisely, two functions - one for the original code (print all the values), and one for the run-length encoded output. Then the << operator can call the appropriate function. It seems likely that there would be cases where one would want to specify the type of output directly (regular or compressed).

[ye-luo]

All the use of this StlPrettyPrint.hpp need to be changed to the new style. Keeping two functions is only necessary when both use cases appear.

[markdewing]

Are you certain that the compressed output format is desirable every where an STL vector is printed? It seems unlikely to me (though that's just a prior belief before actually analyzing all such places). A point of program variation has been identified, and it seems wise to express it in the code. We may want separation between policy (what "<<" outputs for an STL vector) and implementation (how details of a particular format works).

I imagine the structure to be something like:

template <typename T>
std::ostream& prettPrintSTLVector(std::ostream& out, const std::vector<T>& rhs)
{
   ... old formatting code ...
}

template <typename T>
std::ostream& prettPrintSTLVectorRLE(std::ostream& out, const std::vector<T>& rhs)
{
   ... new formatting code ...
}

template<typename T>
std::ostream& operator<<(std::ostream& out, const std::vector<T>& rhs)
{
    return prettyPrintSTLVectorRLE(out, rhs);
}

Then the unit test code tests the implementations (prettyPrintSTLVector...) and not the policy ("<<").

[ye-luo]

Actually even with two functions. I feel it is cumbersome to make a selection via operator <<. by including different header files?

[markdewing]

There's probably a better design. Ideally, one could say something like std::cout << prettyPrintSTLVector(vec) << std::endl; to specify a particular format. Maybe the formatting functions should return a std::string? (std::string prettyPrintSTLVector(std::vector<T> &in))

[ye-luo]

Right now QMCDriverNew::startup is the only consumer. In general, there is no reason to print in qmcpack output in uncompressed format. As the print is always in one line and we never want long lines.
If printing is needed for debugging purpose, the develop can do whatever they need.
So I don't really feel the need to keep both.

[ye-luo]

@markdewing what does RLE stands for?
If we implement two versions, there is definitely need to separate them and test against individual ones. What @PDoakORNL mentioned about state manipulation is interesting but it looks like for rainy day fun. Can we defer all these attempts?

[markdewing]

RLE = Run-length encoding.

[markdewing]

Yes, we can defer this.

[PDoakORNL]

I initially used this for debugging, and one of the purposes I used this for was dump out data in a format python liked. Then I used to to write output from QMCDriverNew and that appears to be the only place in the codebase it's still used. The compressed version is much nicer for general users and for the places its actually used.

I would like there still to be an operator<< available for vectors because its annoying not to have one in application.

iostream does have some hooks that allow code to put temporary state into a stream which I think is what I would do if I wanted two operator<< implementations for std::vector I could switch between. That's definitely not needed at the moment and the c++ golf implementation will still be in the repo to recover if needed.

[ye-luo]

Start testing in-house