Ad
  • Default User Avatar

    First of all, thank you very much for your detailed answer!

    I think you are right about your three points.
    [1] The parameter/variable names are changed to hyphen conventional symbol names.
    [2] I have refactored the example test to be (hopefully) much clearer.
    [3] Invalid input values are now ignored.

    By the way: I also took this opportunity to add a random test.

  • Custom User Avatar

    I am also interested in this rationale.

  • Custom User Avatar

    I lost some good 20 minutes here, maybe more.
    This kata is annoying for the right reason.
    If you want a tip, get to know your programming language of choice.
    Rounding, truncating and floats are common source of problems in computer science.

    If you want a further tip: build your own tools, define your own functions, when needed.
    If a built-in function accepts an Integer and returns a Float (considering you need an Integer result), you're in trouble, guarantee that you can have your desired result without relying in rounding or truncating.

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Default User Avatar

    exactly i struggled so hard with this i was trying some nested loops to loop over rows than numbers and other bullshit, didnt work. Then i looked at solutions and was smiling that it is that simple if u know math for this kind of a problem

  • Custom User Avatar

    I really liked this kata, I don't really know why the low satisfaction rating, but I can guess[1].

    Issue:

    Expected #f, but instead got #f
    This was posted as an issue last year but still an issue today.

    Suggestions:

    [1] I think the description overcomplicates the kata and that's why it is marked as a low satisfaction rate.
    You can use longer names as variables/parameters, which is, as far as I know, a good practice in Lisp, instead of using "v_r", "v_s", etc.
    They're not even in the most accepted style used in Lisp which is to use hyphen conventional symbol names instead of underscore.
    I don't think the extra-work and confusion about the symbol names worth and it doesn't add any value to the kata description or to the practice or learning, specially considering a 8 Kyu kata.
    But hey, that's only my opinion.

    [2](check-= (swim-distance 10 5 5) 11.1803 0.001))
    This is also a question. I don't know the implementation of check-=, Why do the 0.001 as a parameter?
    For a good moment I was totally confused about what I should return, as the description said to return the distance but there was more parameters in the test case.
    Although as they're not as a list I should have just guessed the 0.001 was not relevant to test my solution, but still, since looking at the test and writing your own tests is part of how codewars is used, I think the test function should be improved to be easier understood and read.

    [3]In case of invalid input values (e.g. negative river width) the function should return 0.
    A negative river width is conceptually an invalid input value, but not practically, the tests will always pass and this is everything I can say without spoiling the solution.
    Also, in my humble opinion, the cases where the swimmer velocity is zero and the river width is zero should be stated in the description instead of the wrongly stated (and irrelevant) negative river width case.
    It's lame to have to fail just to see that you need to implement those two easy test cases...
    This is again a problem of lacking of description.

    In general I liked this kata a lot. As simple as it is, I liked it more than the majority of katas I've done in codewars so far.
    But I think the lack of clarity in the description doesn't add value to the kata. You can just make a clear description and if you think people will solve the problem too easily, think that it is a 8 Kyu kata, it should be easy anyways.

  • Custom User Avatar

    @hobovsky thanks for pointing it out!
    I confess I've only noticed the tag in this one after reading your comment and checking it again.

  • Custom User Avatar

    codewars should implement a "tag" system, so people can tag it as a joke, goof, annoying or whatever, and people that aren't here for this can just filter and avoid it completely.

    There are tags on Codewars. They do not work well, that's true, but this kata already has puzzle (i.e. annoying joke) tag.

  • Custom User Avatar

    Thanks for replying @jessedo. Can you tell me what kind of assertions did you do to solve this kata, so maybe I can learn something?

    The rest of this reply is a rant, read only if you don't mind to interact further. :)

    I agree that programming isn't only about coding skills, still I can't see how this kata can be useful.
    I've read a good bit of the discussion thread, and there is a lot of interesting replies both from people complaining about the kata and from people defending it.

    A lot of people are talking about this kata "teaching" TDD and making assertions regarding the result and testing, but you should not write code to pass tests, and as someone have said, TDD isn't a basic concept so it would not be 8, 7 and maybe not even 6 Kyu anyway if it was really focusing on practicing TDD.
    Even if it was the case, there is no teaching since the description is very bad and focused on tricking and joking, and it would not be teaching something exactly correct if it was the case to exploit the tests to make assertions.
    (Although, if you or someone is writing code to pass tests, that's good for you that it's working in your job, I would be fired, and I'm not familiar with this passing-tests programming paradigm.)

    Another thing that this kata have is a poorly written description.
    Not only it's bad to be poorly written per se, but it also difficult a lot for people that aren't native and/or don't speak English fluently.

    This is an interesting math trick, but I can't blame people that didn't learned about it or that couldn't spot it.

    This kata should, at least, have a clearly description if it's really trying to teach something and to offer any kind of practice even if it's not about code, and forgetting about jokes, although a "jokewars" would be cool, considering the fact that you would be entering knowing that it's about code goofs, oneliners, "troll code", etc.
    I know this is a long rant already, but this makes me realize that since the katas are not "professionaly created" (I mean, by teachers, really focusing on teaching something when it's not the case of "useful" practices), codewars should implement a "tag" system, so people can tag it as a joke, goof, annoying or whatever, and people that aren't here for this can just filter and avoid it completely.

  • Default User Avatar

    'If "This is not about coding skills", it should not be in "codewars".'
    I disagree. Programming isn't only about coding skills. Making assertions about what the return of a function can look like is an important part of it.
    This kata forces you to either do a lot of unnecessary work or make clever assertions and make your life easy.
    But I agree that it shouldn't be 8 kyu.

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Default User Avatar

    You have already an answer by Chrono7.

    did those 6 completions used the current Racket 7.2 or another version?

    They used 7.2; the tests were the same.
    I verified your examples with Python. I get the same results as with Racket.

  • Custom User Avatar

    epsilon = 0.1 actual = (3 3.4666666667) expect = (10 3.0418396189)

    With only 3 iterations your value is far from PI with a given precision of 0.1.

  • Custom User Avatar

    In Racket my testcase for epsilon 0.1 finishes in 3 iterations instead of 10.
    Also my testcase for epsilon 0.01 finishes in 25 iterations instead of 100.
    Etc.

    I don't know what kind of implementation are you waiting for, should I write my algorithm less eficient just to pass the test cases?
    I don't get it, I'm recursively creating Libniz formula 1 - 1/3 + 1/5 - 1/7 ..., exactly what the kata is asking for, still the way the test cases are written I just can't pass, although I'm converging correctly to π.

    I'm marking this as an issue, although I don't know if it is an issue.
    Did I understood the Kata description poorly? Let me know.

    Log epsilon = 1 actual = (1 4.0) expect = (1 4.0) epsilon = 0.1 actual = (3 3.4666666667) expect = (10 3.0418396189)

    Log 0.00014 epsilon = 0.00014 actual = (1786 3.1410327432) expect = (7143 3.1417326508)

    This might be something related to how different languages deal with float, big numbers, etc, and maybe the result can vary from lang version to lang version. I'm just guessing.
    Only 6 of 3893 completions was in Racket, did those 6 completions used the current Racket 7.2 or another version?
    Did the test cases where the same when they completed it?

    I'm honestly not sure if the problem is in my algorithm or in the test cases written for this language/version.

  • Custom User Avatar

    This is the best kata I've found so far in codewars.
    The majority of kata is either math focused or not about code practice at all.
    This kata however, focus on practicing concepts about the language the kata was designed for.

    I like math, and I understand the importance of a good math background to be a flexible and creative software engineer, but some kata are either out of place or make you lose time with tricky descriptions or loose test cases.

  • Loading more items...