I've made a fork here that gets rid of rounding and tests for approximate equality.

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.

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.

ideally there would be no rounding because why would there be? additionally, it doesn't specify tie breaker rule so you'll have python and js producing different results for 0.5

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.

.

https://www.codewars.com/kumite/65a235e48041f7053f928704?sel=667077cb9139cffc0ec3052d

I did NOT mean to reject this fork. If you can create it again, I'll accept it

everytime I look at this and remember that I used lambda I hate myself a little more. :)

I am blown away by the solution :D

Very simple :D

So far, I'm learning how few commands I know in Python :P

Wow, ok, this makes everything look so simple. Surprised Face :O