Algorithms that require plotting

[leios]

Hey guys,

There are a few algorithms in the archive that require plotting and a few more are on the way. Obviously, not all languages come with a plotter, so I have been outputting the data into a file format that can be plotted with gnuplot. I don't know if this is good practice or not. On the one hand, it provides a stable output format that allows all code from the AAA to look the same in the end and everything can be plotted with a simple gnuplot plot.gp - command.

On the other hand, some languages already have in-built plotters.

I feel that the languages that do not have plotters, should have a consistent output format. Gnuplot is good for this because it's cross-platform and kinda the standard for HPC plotting.

Should we require everyone to output to gnuplot or should we allow them to use their in-built plotters?

As a note: I think it is best to put the gnuplot script in a separate directory in the code/ directory for each algorithm

Anyway, I wanted to hear your thoughts on this.

[jiegillet]

I think it's a great idea, as you know I've started doing this with split-op.

Although since a single script can only work with a specific format for the output data, we probably need you to take the lead into specifying that format with your Julia code (or whichever language you want to use). It's also probably best if we have the gnuplot script early on so that people can test it with their implementation.

[leios]

Yeah, this is what I was thinking. I mainly didn't want to limit the people who might be using julia / python / matlab / etc that have their own in-built plotters. For consistency, though, I think it's better to output everything in the same format. That way, we can check to make sure their code works with a simple diff command instead of looking at two separate images.

Also: I like having the code output raw data

[berquist]

+1 for being able to do git diff --color-words --ignore-all-space --no-index on two data files.

[jiegillet]

I don't think you can use git diff unless we decide to add the output files to the repo.

[leios]

But maybe we should? I mean, a single data file to compare against might be a good idea in some cases.

It's not like the data will be gigabytes in size, either.

[jiegillet]

Yeah, why not. It could also be a very natural way to require code testing like we've been talking about. For some algorithms anyway.

[berquist]

Text will compress well under version control, and only one copy of the output would be needed (the "reference").

[leios]

Yeah, alright. Let's put that on the list of things for me to do during Hacktoberfest (next month).

[berquist]

Though, you don't need to have any under VC if you don't want. git diff --no-index actually means "run Git's diff algorithm on any arbitrary files, ignoring a Git index if one is present".

So it's enough to have a reference implementation that you can run (say Julia), but you may not want to require people who are writing their algorithm in Python, Java, ... to run the Julia code, etc. A minor choice.

[jiegillet]

(Sorry, a bit unrelated) Does GitHub compress files?

[berquist]

No. But when Git compresses non-binary files into objects under .git (whenever you commit), IME it does a pretty good job.

[june128]

I had an output file discussion before and the result of the strawpoll, I created, was: no output file. (#55 (comment))
So I think we shouldn't include the output file in the repo to keep in-line with previous decisions. It's also not adding much benefit, since the output file is generated by the code.

[leios]

Ah, yeah. I remember this discussion now. Gale--Shapley was a bit of a different case, though. It wasn't meant to output actual data and there was nothing to plot.

Still, the discussion was already had and a result was made after about 8 votes. I feel like we should respect that. Should we have another vote here to see if the community stance has changed?