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.
It's a good implementation, but by nature converting a number into a string is much more complicated than a simple while loop which runs a dozen or so times.
Because sentinal values are a bad idea for many reasons, though you probably already learned this in the 4 years since.
However I'm still bamboozeled as to why it returns
Option<Vec<i32>>
as opposed toOption<[i32; 3]>
. This isn't an arbitrary list, it's exactly 3 elements. I might even expectOption<(i32, i32, i32)
.Mind clarifying? Rust implicitly returns the last expression in a function body if that's what you were wondering.
not return
Seems like the more readable the code gets, the worse it performs.
It's probably because of all the references and function calls.
lol. I've checked on godbolt and we've been getting less and less efficient (at least in terms of assembly length). My initial solution was 186 lines, then 247, and yours is 504. It's not an actual speed comparison, but assuming it's a similar effect, that would show an inverse relation to legibility.
Yours is definitely the most legible, whereas my initial minimizes the number of passes.
Is there a reason
usize
is not used for the return type? It seems more natural if we're going to do conversions anyways, since a negative value is meaningless. Plus now there are situations where we can't give the correct answer.[i16::MIN, i16::MAX]
would product an answer of2^16 - 2
, which is way to big to fit in ani16
. I guess if we're going for minmalismu16
would be the appropriate type, but would require more conversion unless the input was also&[u16]
.I just realized someone already beat me to it in other fork here
I understand that take, but not from a JavaScript developer. I'm intrigued. What do you think makes it worse than JavaScript?
Hmm, the descritions looked identical, but in the editor there was some weird old/===/yours formatting that I removed in the new fork. They should be identical behind the scenes too now.
It seems like there are still issues with the description. Can you fork your translation and make a small change to the description like this?
The Rust translation needs some work.
tests
module with#[cfg(test)]
&[_]
is more idiomatic and flexible and should always be preferred over&Vec<_>
-> ()
return type is moot and discouraged.[a, b, c]
instead of[ a,b,c ]
.todo!()
macro is a more idiomatic way to mark unwritten code, rather than a comment that fails compilation.i64
s and returns 1 isfn(i64, i64) -> i64
. The user shouldn't have to write their own function signatures.Updated
You apparently need to merge the current description into this fork. Otherwise, I can't approve it.
Description cannot be approved, recent changes from related record must be merged first.
Rust tests are run in parallel with nondeterministic ordering, though with only two of them it would be easier enough to submit until such a solution passed. Added random tests.
Loading more items...