Ad
  • Custom User Avatar

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

  • Default User Avatar
  • Custom User Avatar

    Probably it has been fixed or it was you mutating the input

  • Default User Avatar

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

  • Custom User Avatar
  • Custom User Avatar

    You cannot have a flush and a pair. Your example has two deuces of diamonds. That would be an illegal desk.

  • Custom User Avatar

    It could be used "String.Concat(text.Select(...))" instead of join and nested ternary expressions usually frowned upon.

  • Custom User Avatar

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

  • Custom User Avatar

    Please add test case when two flushes and there are difference between pairs. There are solution that passed ignoring this corner case. Like so:

    var expected = new List<PokerHand> {
        new PokerHand("2D 2D 3D 5D 7D"),
        new PokerHand("AT 3T 3T 5T 6T")
    };
    
  • Custom User Avatar

    Hello, could you teach me how or where to find the Taylor series formula? I have used numerical methods to solve this task which worked for me.

  • Default User Avatar

    Sorry, I only changed the "SUBMIT" tests...

  • Custom User Avatar

    Yay, so much better now! Thanks! But example tests seem to be not updated :)

    Changing my vote right away!

  • Default User Avatar

    I modified the testing function in C++. I hope you will have a look to see if it is correct.
    Thanks for your help and your kind posts!

  • Custom User Avatar

    About kata/tests:

    • Default assertion messages seem to display values with 6 digits of precision, while kata requires 7. That's why I (and not only me, as it seems) get really useless message of Expected: equal to 1.14665, Actual: 1.14665 while values are Expected: 1.1466510000000001, Actual: 1.1466509999999999. It would be really helpful if tests provided customized (instead of default) assertion messages with better precision of actual/expected.

    • Truncation is really not helpful, because value like 1.146651 expected by one of the test... simply does not exist. It cannot be represented by double value, and it can be either 1.1466510000000001 or 1.1466509999999999, but there is no such value as 1.146651, no matter how much you'd like to truncate it. Even if you do double foo=1.146651;, foo is not equal to 1.146651, but 1.1466510000000001.

    • Ad "[...] the variety of solutions through all languages seems to show that with 6 decimals there is no need to do the calculations in the same way original solution does nor to use tricks" - would you be so kind then to take a look at my solution and tell me what exactly I do wrong that my result misses the expected value?

    But as you say, you created the kata long time ago, and you probably know all of this now. Problem is that you've probably long forgotten about the issues, but new users still encounter them, and get frustrated. I really mean no offense, I really do not mean to attack you or anything, but all I want to do is to warn potential users who would want to solve the kata, and leave some remark for those who would like to author a kata so they could see what to avoid. I do not mean to bash you, nor to bash the kata - just trying to leave some info others could find useful. I did not even expect any particular feedback, and honestly I even thought that if I would get any, it would be rather something like "GTFO", or similar ;)

    And your dedication and contribution to CW is much bigger than mine. Really appreciated.

    Regards!

  • Default User Avatar

    When I first wrote this kata (3 years ago) I wanted to put in evidence some rules when calculating with doubles:

    • with a bit of math simplify the expression as much as possible
    • avoid numbers too big (e.g. factorials)
    • avoid to multiply by a number the result of a division to abstain from multiplications of errors (though here it doesn't seem to make a difference in the tests).

    Maybe I was wrong about these aims... nobody is perfect!
    I knew there would be discussions about the tests with no tolerance so I have limited to 6 the number of decimals of the truncated result; the variety of solutions through all languages seems to show that with 6 decimals there is no need to do the calculations in the same way original solution does nor to use tricks. Nevertheless in some more recent translations I introduced a tolerance with a custom "assertFuzzyEqual" test function.
    I think C++ tests are not "screwed" (though maybe more difficult than in the C version) since several guys passed with different kinds of code.
    Sorry for this long advocacy.
    PS: @hobovsky -> thanks for your dedication to CW!

  • Loading more items...