Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
That's briliant but from my point of view this loooks easier:
String numeroMaximo = Arrays.stream(Long.toString(number).split(""))
.sorted((a, b) -> b.compareTo(a))
.collect(Collectors.joining());
Oh man! I couldn't think it could have been done so clever like this :) Especially it avoids floating point computation and the hurdle of conversion floating point value to integer.
The tests look fine now, I think
Yes, there was low entropy as far as the
expectedResult
was concerned (only 3 random strings / 825 cases). The rest were given by the cases for the strand length (11) and the index at which the match starts (25 cases).3 * 11 * 25 = 825
. It was inefficient.I've updated the JS tests and was more explicit about the variation in the location of the match. Also, the
expectedResult
is now different for each case of the twodescribe
s, each with11 * 25
cases.Also updated the Java tests to match.
Might need to improve test for the reversal of arg order, as it relies on the low probability of multiple solutions being randomly generated.Later edit:
Wrote a solver inside tests, to specifically filter for cases with unique solutions for the test that required it and ran that over random sequences.Used static array of oracle unique solutions instead of a random method until something better to determine uniqueness of solutions comes up, as the solver should not be part of the test code.There's something wrong with the JS random tests, they're testing a few randomly generated tests for hundreds of times, so effectiviely there are only a few random tests.
Well, in this case we're writing test code for a coding challenge that evaluates user's code, so the tests should be robust enough for common things. Test code should be subjected to at least the same standard as user code. If user can easily break the tests and cause false positive/negative results just by mutating the input (which is not exactly something rare, or even intentional), we'd say that the test code is poorly written, not that user code is doing something malicious.
And in 99% of the cases, whether user mutates the input or not is irrelevant to the task at hand, so there are also no particular reasons to restrict users doing that. It's better to just let the tests gracefully handle it, rather than escalating the situation telling the user "why are you mutating the input, you're WRONG, re-write your code". That'd be like a inflexible, draconian commit hook rather than actual teaching.
I'm sorry if I came off as petty. I was taking a philosophical standpoint. This wasn't about performance, rather about responsibility. About the habits that become ingrained in the developer in different contexts. Should you be careful with the data you are given or not? In some languages where data is immutable, this doesn't matter. In others there is a clear rule that can be enforced (this was the Rust example). Yet in others, you should enforce these rules yourself.
I understand what you are saying, because people will toy around with various methods and will sometimes mutate the input. Sometimes they will find a solution by doing that, and then wonder why tests break. So it is important, as a platform, to be robust against that.
I am merely wondering whether or not this puts us in the mindset of solving local, isolated problems and we stop looking at the broader picture.
I don't mind changing the tests or doing this in one way or another. It is software after all. 🙂
I just felt the need to express something I felt strongly about. Maybe my worries don't have their place here.
Again, I appreciate the feedback.
I don't see how any of this has anything to do with Rust.
This is much more effort than just passing a copy. Not to mention, if you want to test the input isn't mutated, you'll need a separate copy to hold that information, so it doesn't save anything over just passing a copy. At best it's just a very petty practice that doesn't bring in anything useful.
Very well, I'll change the tests assuming that the args are disposable. But the way I see it, if the goal is to write robust code, it's also not a good thing to give people free reign to mutate the input in an operation that finds things (i.e. something that can always be done as a "read"). I could just as easily make this requirement explicit and add a test for it, rather than always passing a copy of the array to the user.
It is things like these that motivated the borrow-checker in Rust, where the ownership is made clear at compile-time. In short, we are going to do it the Rust-way, where the args don't have a lifecycle outside the function scope and the "easy" fix is to always pass a copy.
Test code should be as robust as the user code; it's not good (and generally unacceptable) if modifying the input can easily break the tests.
This should be mitigated if you pass a copy of the array to the user function. Other languages where strings are actually an array of mutable characters (e.g C and Ruby) will need this as well.
Yes, this is generally a question of the contract of the method. I did not expect the user to modify the input in-place.
What are the expectations? Should I mention this in the requirements of the kata? Should I switch to a
String
signature in Java for immutability?Now there's another issue in Java version: if user mutates the input the tests will erronously fail.
Thanks for the feedback. I've used a constant in Java version and improved the tests in both languages a bit.
JS version has no random tests.
Java version is currently broken, as tests implicitly relies on user code:
C++ tests using random
a
,b
bounds do not allow for inclusive interval[a, b]
.For example,
a=1095
andb=2427
expected{1306, 1676}
but2427
is also the sum of "digit powers"(2 + 16 + 8 + 2401)
, so more correct is{1306, 1676, 2427}
On subsequent re-runs my code passed.
Loading more items...