I agree with everything hobovsky said. This solution happened to pass because of an implementation detail of the tests, but I just made them a bit stricter, and the solution should now be rejected.

I don't see this solution in the list of solutions though. Neither in the passing nor in the invalidated ones. What's going on? Did you actually submit it? Or maybe some Codewars worker queue simply hasn't caught up yet?

I made the tests a bit stricter. You really need to convince the relevant authorities that Yossarian is crazy. You have an appointment with the psychiatrist – don't try to skip it. And don't shoot the doctor – he's just doing his job.

Similar pairs would imply some approximate matching rather than exact whole word matching.
Perhaps ignoring case by mapping to lower case:

var seenWords = Arrays.stream(words).map(String::toLowerCase).collect(Collectors.toSet());

But similar pairs is also not quite right -- more like "count duplicates".
Otherwise the similar pairs eg in
{"Volvo", "Volvo", "BMW", "Mazda", "BMW"}
would be 2 -- a pair of Volvos and a pair of BMWs.

And how many pairs are there in { "Volvo", "Volvo", "Volvo", "Mazda" } ?
Actually 3 - there are 3 ways to pick a pair of Volvos from the list 😆!

I disagree that positive lookaheads (?=...) make the problem easier. They would make possible solutions generating answers that are more efficient/concise, but the original complexity still needed for the powers of single primes (eg 17), and could allow for larger factors to be tested.

Integer ops or not, the point is that the constants can be reduced as in the examples above. And yes, taking into account the integer division, (a * (3 / 2)) == a * 1 == a. But (a / 2) * 3 can not be simplified. So these optimizations should be accepted in the solutions, particularly for a 1-kyu level.

But here you should be careful. Because '/' is integer division.
So (a / 2) * 3 is not same as (a * (3 / 2)) i.g. a == 1
My gut tells me that this additional feature will be implemented through many crutches :)

Nice Kata, but for a 1-Kyu level the requirements for the optimization (pass2) could be stricter.
Eg most of the soltions submitted will reduce ((1 + 3) + x) to (4 + x), but additional cases that should be achievable are:

• ((x + 1) + 3) = (x + 4)
• ((x - 1) - 3) = (x - 4)
• (0 + x) = x
• (x * 1) = x
• (x - y - z + 10 / 5 / 2 - 7 / 1 / 7) = (x - y - z + 0) = (x - y - z)

Clearly there are always multiple solutions, but prioritising the possible answers as follows seems to succeed:
(1) Solutions that don't involve fractions.
(2) Solutions that refer to the "first seen" variables in the list of examples.

Hi Clair. If the original problem is from "a company's coding assessment", then maybe they also want to see what you do with an inadequately stated requirements specification, which is a very common real-world situation!
If they can't or won't clarify, then I would simply state your assumptions and provide your solution that passes.
Otherwise if you have more automated tests you could also try some different assumptions (eg there must be as many '-' as there are '.') and modify your code.
BTW, you really don't need a 'stack' in your code since you only need to keep track of how many '.' you have seen -- so a simple int is enough.
Good luck!

That's the question I got from a company's coding assessment, I agree, there is some information doesn't clarified, and I try what you said in my code and try that test again , but stll left 3 test cases couldn't pass, unfortunately, all the weighted test cases are hiden.

The description of "input1" and "input2" seems somewhat C language centric, and input1 is quite redundant as can be seen in your initial code -- it is never referenced. Better to just describe the single input as being the "Sequence of strings, each representing a new message in the set" and leave it to the language specific variant whether that is an array, a list, a length + a pointer, or whatever.
Another example with extra dashes might clarify that unmatched '-' are ok, just no unmatched '.'. Assuming that is the case, then:
".---.-" is OK (extra dashes but every dot still has a corresponding dash)
".--..-.-" is not OK (extra dashes, but not enough dashes after the 2nd and 3rd dots)