Hi there,
I found that the description of the nucleotide task which I did in C was misleading.
It states to format the output like this:
"GATTACA" -> 'A': 3, 'C': 1, 'G': 1, 'T': 2
"INVALID" -> error
When in fact the tests specify the output to be like this:
"GATTACA" -> "A:3, C:1, G:1, T:2"
"INVALID" -> ""
I’m happy to create a PR that fixes this if you agree on my proposal.
Thanks!
The problem specs are language agnostic and describe the problem. The description from the problem spec is then used across all 75+ tracks. Given that each track is a different language, the description isn’t meant to exactly match the syntax/test of any specific language. They explain the problem; they do not show exact results. I’m not sure what you’re proposing to fix here. Are you suggesting making the C description different from the spec? Make the spec match the C tests? Something else?
The description explains the shape of the program. The tests are the actual language specific requirements.
Thanks for the explanation, it makes sense that it’s language agnostic and I understand that limitation.
That being said, why then is it that the test for this task on the C track does not test for the defined structure? That aspect seemed a bit off to me, as in most other places, the instructions where quite accurate w.r.t. the desired output format.
I see how in some tracks, that example looks reasonable close enough to code. However, the test suite is provided and clears that up pretty quickly I believe. Adding a single-row table might convey the same idea of counting up each letter separately.
| Word | A | C | G | T |
|---|---|---|---|---|
| GATTACA | 3 | 1 | 1 | 2 |
Not a C person but my understanding is that it’s a no-frills experience so perhaps there wasn’t a built-in hashmap / dictionary equivalent when the exercise was added?
Are you looking at the structure in the description or in the problem specs’ canonical data file? Most exercises stick fairly close to the canonical data. If this exercise differs from that, the “why” is likely only answerable by the people that implemented the tests. You could try to look up the change history in GitHub to understand the changes.
Thanks for your patience here.
I did have a look around, but I think it’s just meant to represent the intended output as a dictionary or map independent of the used language. That was not clear to me at the time when working on the specific task, assuming that the text was specific to the language.
In the end it’s not an actual problem, I do like @BNAndras proposal to use a table, but I that is up to your discretion.