Add transpose test cases

[ErikSchierboom]

No description provided.

[petertseng]

I like what I see for integers.

The exercise description and source specifiy text as well, how do we want to handle that?

There is a PR on xRust that assume text inputs, and the additional implication here is that the rows/columns need not all be equal sizes. Some additional cases to deal with those would probably be appropriate.

[ErikSchierboom]

Good idea, I'll add some string cases too that take into account varying row/column lengths.

[ErikSchierboom]

@petertseng Having read the exercise, it does indeed explicitly mention text. If we would also like to support transposing non-string arrays, I think it makes sense to have a multiline string passed as an array of strings (each line being an array entry). What do you think?

[Insti]

Is it likely that a solution that solves for arrays of numbers will not also solve arrays of strings?
(My dynamically typed language bias may be showing through here.)

[ErikSchierboom]

@Insti Yes, but it is not clear from the exercise text that the string is passed as an array of strings instead of a string with newline characters.

[Insti]

The description:

Write a program that takes input text and outputs it -- transposed.

Would seem to suggest that the input (and output) is text with newlines which would make the arrays in the .json file inappropriate?

Edit to add:

I think it makes sense to have a multiline string passed as an array of strings (each line being an array entry)

Given the input and output are expected to be text, I strongly disagree with this.

[ErikSchierboom]

@petertseng @Insti Maybe we should then only focus on text and not on integers?

[Insti]

Yes, probably.

But it looks like fsharp is the only track that implements this problem?
In which case just change the description to match what you want to do 😃

[ErikSchierboom]

@Insti Well, I was coming around to that :) The only thing that would be modified is that multiple lines are passed as an array of strings.

[Insti]

Opinion:
A problem that involves transforming text into text is more interesting than one that turns an x by y array into a y by x array.
(Even if it's essentially the same thing with added split/join)

[ErikSchierboom]

@Insti Agreed. I'll close this PR.

[Insti]

A Word square would make an interesting test case.

H E A R T
E M B E R
A B U S E
R E S I N
T R E N D

[Insti]

And Word rectangles (from the same page)

F R A C T U R E
O U T L I N E D
B L O O M I N G
S E P T E T T E

[ErikSchierboom]

@Insti On second thought, maybe I should update the PR with some new, string-based examples?

[Insti]

@ErikSchierboom I think that's a good idea.

[ErikSchierboom]

@Insti @petertseng I've updated the test cases to work with strings. Better?

[Insti]

{"multi_line_string":"Multi\nLine\nString\n"}

[Insti]

Perhaps it should be: JSON doesn't allow for elegant formatting of multi-line strings, so all multi-line input and output is...

[ErikSchierboom]

That seems like a good wording. I copied the text from the existing JSON data from food-chain by the way.

[Insti]

This new version looks great 👍

It would be good with some simple initial test cases.

A1

A
1

and

ABC
123 

A1
B2
C3

and their inverses.

When doing an exercise, the less output I need to look through to work out what might be wrong the better.

[ErikSchierboom]

Good idea. Will add them.

[ErikSchierboom]

@Insti done!

[petertseng]

in the original text, the period belongs to the second line, so there should be a space before it in the transposed text

(That would be consistent with what the source https://www.reddit.com/r/dailyprogrammer/comments/4msu2x/challenge_270_easy_transpose_the_input_text says, and the PR exercism/rust#151 )

[ErikSchierboom]

Also fixed in the updated PR.

[Insti]

There doesn't seem to be a test case where the first line is longer than the second line.

[ErikSchierboom]

@Insti @petertseng I've updated the incorrect test cases, and added a test case where the first line is longer than the second line.

I've also looked at the xRust PR and it appears their test case also had some problems, where input spaces where stripped in the output.

[petertseng]

I think everything is in order (I haven't verified with code though).

It might be worth adding to the README a few things, because otherwise the problem seems unspecified.

• What happens when line are different lengths (pad to the left with spaces, but don't pad to the right)
• If a column in the input text contains only spaces on its bottom-most rows, should the corresponding output row contain the spaces in its right-most columns?
  • The source says they shouldn't.
  • I can see argument for why it should because that's what's in the input text, and we're just transposing it! And that's what the test cases expect
  • I absolutely do not care what we choose, and we currently chose "keep the spaces", so we can roll with that.

[ErikSchierboom]

@petertseng The README has been updated as suggested. Is it clear enough?

[petertseng]

remove this line, I think

[petertseng]

I like what I see here (with a few small fixes)

👍 from me once the fixes are applied

[ErikSchierboom]

@petertseng I've fixed the remaining issues and I'll merge it. Thanks for the help!

[petertseng]

I think I missed a small thing - no spaces after the comma, right?

(I also haven't checked with code, so I may have missed others, but I least see this)

[petertseng]

I'll send the PR. This was the only thing.