6 kyu

Temperature converter

504 of 1,004kusm
Description
Loading description...
Functional Programming
Data Structures
Strings
Mathematics
Fundamentals
View
AllIssues12QuestionsSuggestions3Show Resolved
  • Please sign in or sign up to leave a comment.
  • tobeannouncd Avatar

    Round converted temp value to an integer(!).

    • The Python test cases expect the value truncated to an integer, rather than rounded to the nearest integer, which is unclear from the description.
    • For solutions that convert to an intermediate unit before converting back into the target unit, the choice of unit can lead to floating point errors which result in incorrect truncation. This turns the exercise into one of two possibilities:
      1. Guessing which intermediate unit the reference solution uses.
      2. Hard-coding the 56 conversions between each combination of units.
  • gstone Avatar

    Did this in python

    Great simple challenge for people new to coding although the instruction could have been a little more clear on how to handle rounding. I discovered that I could simply cast my result to an integer at the end and get a correct answer (i.e. if my final number is 150.9, casting to an int would result in 150 which would be accepted) although the given instruction was simply to "round" to an integer, which in a mathematics sense typically implies that .5 and less (inclusive) rounds down where greater than 0.5 rounds up. I would recommend specifying to round down as it could give those who are new to coding a chance to learn that it is usual for numbers to be rounded down when they are cast to an int.

    Overall this was a good kata. I did this kata in my own IDE in order to practice VIM and this was a good exercise for it.

  • Kaham Avatar

    Python:

    The requirement "Round converted temp value to an integer(!)." is technically correct, but misleadingly fails to state that validation expects NO type casting to an int if the from and to scale are the same.

    For example: temp = 80.48, from_scale = 'F', to_scale = 'F' -> It should work for random inputs too: 80 should equal 80.48

    I would argue that this use of mixed-type returns is bad practise (i.e. always expect int, or always expect a 2-digit float), but at the very least this requirement could be detailed in the problem statement.

  • saudiGuy Avatar

    python new test framework + random tests are required. updated in this fork

  • ejini战神 Avatar

    Description should be language-agnostic

  • ejini战神 Avatar
    • Ruby 3.0 should be enabled (Refer this & this for more detail)
  • ejini战神 Avatar

    No random tests in Ruby

  • G_kuldeep Avatar

    Nice Kata:)

  • Voile Avatar

    Random tests sometimes has a result of x.5, which is suspectible to floating point errors depending on the exact way the conversion is calculated.

  • rsalgado Avatar

    Just an observation; for the Ruby version of this kata, please make the changes in the tests (and the code in general) to stick to Ruby's snake_case conventions.

  • AlexHandy1 Avatar

    Very frustrating to find another Kata with non-descriptive error messages e.g. 1 failing with "Expected: 230, instead got: 63" Please list the inputs you are testing for so can actually deduce where the problem is. In this case, what was the input? What is the temp conversion?

    Thanks

  • computerguy103 Avatar

    This comment has been hidden.

  • kopijunkie Avatar

    This comment has been hidden.

  • Ciccio99 Avatar

    Nice simple challenge, I think attempting to code these in way that could be used in multiple applications is what makes it challenging.

  • seevee Avatar

    Ruby tests and submission evaluation should use 'convert_temp' rather than 'convertTemp'.

  • wthit56 Avatar

    You say to round down to an integer. So shouldn't -273.15 round down to 274, instead of the expected 273?

  • GiacomoSorbi Avatar

    Ruby version submitted :)

  • walshd15 Avatar

    No real issues, I just think it could use more test-cases

  • ZozoFouchtra Avatar

    JS translation kumited.

  • staticor Avatar

    may cause some issuses in case of float 2 integer .

  • jolaf Avatar

    When working with linear conversions with fractional ratios, the results would be fractional numbers, though they could be pretty close to integers in some cases. See my solution for illustration of this problem. For a good kata, it would be nice to specify the expected behavior of the converter in this matter. I see three possible ways to deal with it:

    A. Specify that the expected results are integers (nobody ever wishes to deal with fractional degrees in real life), and so the computed results must be rounded and returned as integers.

    B. Specify that the expected results should be precide up to a certain number of decimal digits and expect the returned values to be floating point rounded to that number of decimal digits.

    C. Specify that you expect the results as precise as possible, expect calculated values to be floating point, and compare them to the expected values with some expected inaccuracy, for example, you could create a special function for that and write tests like this:

    def isClose(got, expected):
    if abs(float(got - expected) / (expected or 1)) < 0.01:
        return "OK"
    else:
        return "Got %s, expected %s" % (got, expected)

Test.assert_equals(isClose(convert_temp(100, "C", "F"), 212), "OK")
  • jolaf Avatar

    Very nice kata, thank you!

    However, there're some issues that must be addressed.

    First, please use test.assert_equals() instead of test.expect(). It provides information about what was the expected value and thus helps to locate and fix bugs. Please look here for details: http://www.codewars.com/docs/python-test-reference-1