Earn extra honor and gain new allies!
Honor is earned for each new codewarrior who joins.
Learn more
  • Apologies, I only looked at this kata again today. I didn't receive a notification of your comment as it wasn't labeled as Issue.

    I'm not sure I follow though, can you expand? I'm trying to understand where the expectation of an i32 comes from.

    The solution setup currently takes a u8 for the length parameter and returns u64, so I expected the tests to infer that type and I didn't get any of the above warnings for my own solution either. I'm not sure why yours is returning i32.

    fn count_patterns(from: char, length: u8) -> u64 {}
    
  • The test cases in Rust pass incorrect data types...

    error[E0308]: mismatched types
       --> src/lib.rs:131:50
        |
    131 |             assert_eq!(count_patterns(dots[dot], length), solver[dot][length as usize])
        |                                                  ^^^^^^ expected `i32`, found `u8`
        |
    help: you can convert an `u8` to `i32` and panic if the converted value wouldn't fit
        |
    131 |             assert_eq!(count_patterns(dots[dot], length.try_into().unwrap()), solver[dot][length as usize])
        |                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    error: aborting due to previous error
    
    For more information about this error, try `rustc --explain E0308`.
    error: could not compile `qualified-rust`.
    
    
    NOTE: Line numbers in error messages can be incorrect due to concatenation.
    

    Forgot to mention that a workaround is to change, in your implementation, the type of the second parameter in count_patterns to u8. Hopefully your code can take it :), the practice tests will fail, but your code will run on the submission tests.

  • Did you solve this? I reckon you don't need to go all the way up to searchNum, but rather figure out what's the smallest shape a k-prime can have, when expanded, that's as much as you need to loop. No more.

  • Wow this one did a trick on me, I was testing puzzle with parameters up to 6 orders of magnitude.

    Understandbly, it was pretty slow and hard to optimize such a thing, and ended up writting pretty ugly code, and although it passed, I kept getting timeout.

    I am quite new to code wars so I did not realize that my timeouts were happening on the count_kprimes section, rather than the puzzle section.

    After refining the my algorithm to count primes, it all turned green!

    What a fun problem, though the second task, for large inputs, could be a task of its own.