Python Resistor Color Trio currently doesn’t test for values over 1,000 which cannot be represented as kiloohms.
There is one test with zeros = red (2) … which is for value 2,000. This allows code the following to pass, which would generate incorrect values for zeros = red (2) and the second digit as anything other than 0. Note: this solution is akin to something that was used in a solution I was mentoring and not speculative.
if value > 1000:
return f"{num // 1000} kiloohms"
return f"{number} ohms"
Upon looking at the canonical data for this exercise, I see the canonical data doesn’t address that case, so this is more of a question for the canonical data than Python.
Should I open an issue on that repo or keep discussions here?
The awk version of this test has much more comprehensive testing (and extends the units). Thoughts on syncing from awk test cases to the canonical data?
We use the canonical data for the exercise.
If you are up for updating that canonical data you are free to do so(by me) and the python track will probably bring in those changes.
We don’t do that many costum cases and try to relay on canonical data to cover most cases. There are cases we make our own tests, like error hanedling and if there is a specific case we want to cover.
Although for this exercise we wont do an extra test to cover that case unless it comes directly from canonical data.
I just bumped into this myself on the Elixir track. I was about to open a new topic, but this one was detected as similar. Nice .
The linked PR has some interesting discussion, namely that the case red, red, red is ambiguous: it could be 2.2 kiloohms or 2000 ohms. Different tracks seem to have different example solutions. It would lead to churn for many tracks if one solution was picked over the other.
While I completely understand that, I still find the current situation a bit dissatisfying. I have looked at community solutions of Elixir to learn from them, and I’ve found that some of the top-listed ones are actually “incorrect”, meaning their solution loses precision in some cases. (red, red, red -> 2 kiloohms) Now I’m not sure what I want to do for my own solution.
I’m not really advocating for some specific action, just wanted to share my experience.
Per the discussion in the above PR, there’s different opinions about what is “correct” in this situation. It’s hard to objectively label something as incorrect when some people think that’s the most correct solution
Just did the exercise in Ruby, came to the same conclusion.
The discussion kinda ignores the loss of precision thing and focuses on 2.2k vs 2200 just as a matter of taste, without the implication that the exercise promotes bad solutions. 2k instead of 2.2k (or 2200) is objectively a wrong result.
Also, how does the canonical-data propagate to tracks? The Ruby track doesn’t have the tests with megaohms etc.
This is subjective, not objective. This assumes that a loss of precision is necessarily wrong. That is not necessarily a correct assumption.
Via the configlet sync tool and, depending on the track, automated or manual test generation. Syncing requires some manual work and a pull request. See configlet sync | Exercism's Docs and related building docs.
