Omnimaga
General Discussion => Technology and Development => Other => Topic started by: alberthrocks on May 29, 2014, 09:28:28 pm
-
UPDATE: Specifics and clarifications can be found here (http://www.omnimaga.org/index.php?topic=21156.msg384842#msg384842).
Here's something that came up at work today. Seemingly simple, but it's a lot more complicated than it looks! (At least for me, heh...) I've came up with a solution already, so try it out!
Give it a try:
http://pastebin.com/FWLmveKF (http://pastebin.com/FWLmveKF)
The challenge (if you can't access the above):
=====================
= Make That Table! =
=====================
CHALLENGE:
Using any programming language, write a program that takes the following INPUT and converts it into a valid table OUTPUT.
Input represents any table, space-delimited. The first line is the table header, and the second line is the table secondary header.
Output must be based on the input. Display statements of the final result without any steps to get to the final results will be disqualified.
=======================================================================
= INPUT: =
=======================================================================
Hoooligans! Party Animals Count Alpha_Delta Rounded First
Second Third
1234 12.4562294932 12.4958 193583.149592983 28592 2948502.5
39502050 104.682950380298 193.499499 19384885444.2223 1234567 123592
=======================================================================
= OUTPUT: =
=======================================================================
Hoooligans! | Party Animals Count | Alpha_Delta | Rounded | First |
===============================================================================================
| | | | Second | Third
-----------------------------------------------------------------------------------------------
1234 | 12.4562294932 | 12.4958 | 193583.149592983 | 28592 | 2948502.5
39502050 | 104.682950380298 | 193.499499 | 19384885444.2223 | 1234567 | 123592
-
What kind of restrictions are there on input format? Will the table always be nicely spaced already? Will every data cell contain a number? Will there always be at least one row of data?
And how about the output format? Can we pad lines to the end with spaces? Should there be precisely no extra table width on the left but one character of extra table width on the right, as in your example?
-
What kind of restrictions are there on input format? Will the table always be nicely spaced already? Will every data cell contain a number? Will there always be at least one row of data?
And how about the output format? Can we pad lines to the end with spaces? Should there be precisely no extra table width on the left but one character of extra table width on the right, as in your example?
Sorry for the lack of specificity.
You can assume the following:
- Everything is right-justified and well spaced. A human can easily distinguish the columns.
- Assume that there will always be a header (first line) and a sub-header (second line).
- You can safely assume that every value cell (third line and down) will be filled.
- There will always be rows of data, but consider only using the first few, since the actual data could be thousands of lines long.
- As for output, the table I made was just a quickly done table to show how it could look like. The main goal of this challenge is to show that you are able to map the header and subheader to the column data below. Therefore, the output needs to show that you are successful in doing so. A simple table will do, or even a CSV that can easily be imported to Excel.
Hope that helps (and makes it easier)! Feel free to ask any more questions as necessary!
Oh, and here's proof of solution (when it eventually gets posted):
Solution hash: 4ff5917ff0f821103799498d79a4c70665eb8a68f3b6cf715986c93d3db9e2a6
Verifiable here (http://www.bichlmeier.info/sha256.html)
EDIT: Updated pastebin with specifics above!
-
Is the purpose of this precisely to make an ASCII table? Or is it simply to convert the data into a more standard tabular format? Because you mentioned that converting it to CSV that can be imported into Excel would suffice, but I would like to point out that the input data can be imported into Excel just fine as-is, in which case my solution would be to do nothing. :P
-
Is the purpose of this precisely to make an ASCII table? Or is it simply to convert the data into a more standard tabular format? Because you mentioned that converting it to CSV that can be imported into Excel would suffice, but I would like to point out that the input data can be imported into Excel just fine as-is, in which case my solution would be to do nothing. :P
True true... yeah, the point of it is to figure out which columns represent which data, aka successfully parse the input table. So either would work as long as they are generated from scratch. :)
-
Bump bump! Anyone find a solution yet? :D