in reply to Re^5: LeetCode Problem #1 - Two Sum - Improve and/or discuss.
in thread LeetCode Problem #1 - Two Sum - Improve and/or discuss.

In "Re: LeetCode Problem #1 - Two Sum - Improve and/or discuss.", you wrote:

"... you have to also allow the reverse order in your tests."

In "Re^2: LeetCode Problem #1 - Two Sum - Improve and/or discuss.", I replied to that saying that I agreed and that the spec had indeed said "any order". I changed @tests to include "any order".

In "Re^3: LeetCode Problem #1 - Two Sum - Improve and/or discuss.", you replied to that:

"not sure why you are duplicating the tests ... (?)"

There were no duplicates. I added (different) tests such that the result could be in "any order".

In "Re^5: LeetCode Problem #1 - Two Sum - Improve and/or discuss.", to which I'm now replying, you've removed the tests that allowed the results to be in "any order". You've modified is_deeply such that any additional tests added to @tests must have the results in ascending order for the is_deeply test to be successful. I do not agree that this is any sort of improvement; in fact, I'd consider it to be a bad move.

By the way, I don't see any difference between my &sort_arrayref and yours. I've looked closely at both; do let me know if I've missed something.

— Ken

Replies are listed 'Best First'.
Re^7: LeetCode Problem #1 - Two Sum - Improve and/or discuss.
by LanX (Saint) on Jan 24, 2022 at 22:13 UTC
    > By the way, I don't see any difference between my &sort_arrayref and yours. I've looked closely at both; do let me know if I've missed something.

    They are the same.

    > You've modified is_deeply such that any additional tests added to @tests must have the results in ascending order for the is_deeply test to be successful.

    OK, if you prefer to order them during the tests, so be it.

    > There were no duplicates. I added (different) tests such that the result could be in "any order".

    hmm ... those seemingly different "any order" arrays are sorted to the same expect-part in the tests.

    Hence half of your tests are redundant and violate the DRY principle.

    I really don't know how to explain it any better.

    FWIW: one actually needs more tests if the input isn't unique, since those cases are different but legit solutions.

    [[2,7,7,15], 9, [0,1]], [[2,7,7,15], 9, [0,2]],

    another case for multiple solutions would be

    [[2,7,4,5], 9, [0,1]], [[2,7,4,5], 9, [2,3]],

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      Consider if a new element is added to @tests:

      [[1,2,3,6], 5, [2,1]]

      So, 3+2=5 and the solution is found. In my code, with a sorted $test->[EXPECTED], the test passes; in yours, with an unsorted $test->[EXPECTED], the test fails.

      "FWIW: one actually needs more tests if the input isn't unique, since those cases are different but legit solutions. ... another case for multiple solutions would be ..."

      That's incorrect. The spec has, in emboldened text (under Contraints): Only one valid answer exists.

      — Ken