Hi there.

My code is working both on my machine and on Rust Playground. However, the testing system returns the folowing error:
"called Result::unwrap() on an Err value: ParseIntError { kind: PosOverflow }"

Am I missing something or is the testing system failing wrongly?

Here's the link to playground and my code:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0b8fef83a1dca09af99986ed012ff56d

fn calc(s: &str) -> u32 {
     let mut total1 = String::new();
     for c in s.chars() {
         total1.push_str(&(c as u32).to_string())
     }
     let total2 :String = total1.replace("7", "1");
     println!("{} {}", total1, total2);
     total1.parse::<u32>().unwrap() - total2.parse::<u32>().unwrap()
}

fn main() {
     println!("{}", calc("ABC"));
}

The only failing test case says: "Should return 2 for input 1"

How can that possibly be?
The Fibonacchi sequence is 0, 1, 1, 2, 3, 5, ... etc.
Ok, suppose we reduce that to what the author suggests 1, 2, 3, 5, ... etc.
But then in both cases the biggest numbers equal or less the input limit 1 is
1 or [0, 1, 1] where 1 is odd and can not add to the sum and 0 (0 % 2 == 0) doesn't add to the sum either.

What is the author trying to say by this test case? Am I missing something? Is this poor wording of the kata or is this my poor English?

The kata itself is piece of cake. But I had real hard time getting throught the description :(

Also,

strings.Split(s, " ") is equvalent to string.Fields(s)

I'd say the proper way is:

import "unicode/utf8"

utf8.RuneCountInString()

Seen this on Go blog.
Cheers :)

No idea how it works :( The output in the logs looks completely random to me (and I'm outputting test case counts, functions input and all reasoning for returning this or that value).

I'm seeing testing system stop spittiong out my Printf's either after 4 test cases or 13 test cases (and I assume there are more than that). In what is showing up I see no mistakes. The funny thing is that more test cases show in logs when I add 100% non-working code (i.e. return true when both arrays are zero len, which is clearly against problem description). So there is actually no way to understand what's happening.

Having solved this in Python I do understand the solution and doing exactly the same with Go. I wonder what can be done to make logs more human-oriented (i.e. would let me log each and every test case like in other kata I've seen)?... :)

Played a little bit with logs. It looks to me that the text: "Log Expected : false to equal : true" does not apply to the nearest previous output but rather to the whole bunch of tests. It might be the case that the testing systems output was referring to some other test case (and the one I mentioned in the post was just the final one in log output). I'll try to get across tests and report. Apologies for the hassle :) I'll mark the issue as resolved in the meanwhile.

Will double-check this. Just solved the kata with Python with one-liner, will revert to Go no. Hold on a while!

Here's the log for the same test in Python:

First: [121, 144, 19, 161, 19, 144, 19, 11]
Second: [121, 14641, 20736, 36100, 25921, 361, 20736, 361]
Returning: False

And it passes the test with test with the same output.

Greetings everybody.

I'm passing all random test. Have rewritten my solution a couple of times in various ways (I'm solving in Go).

Still I'm stuck with this test:

 should handle basic cases
 Log:
Untouched input: //I'm just printing initial input which function receives
First: [121 144 19 161 19 144 19 11]
Second: [121 14641 20736 36100 25921 361 20736 361]
Returning: false //This is what my function returns according to the log.

And I'm getting:

Test Failed
 Log
Expected
    <bool>: false
to equal
    <bool>: true

How come it? :)

To make myself clear, here is the exact quote from problem description:

a = [121, 144, 19, 161, 19, 144, 19, 11]
b = [121, 14641, 20736, 36100, 25921, 361, 20736, 361]
comp(a,b) returns false because in b 36100 is not the square of any number of a.

I find that the input I logged is exactl the same as in problem descrption. And I'm returning false here as exepected.
Still the test fails.

Damn :) I've solved it, but the explanation of the problem leaves space for improvement. Note that you need to assess numbers from in range 1000 - nMax. Also you need to check (for every number irrespective of its length) that any 4 adjacent digits in it are <= maxSum. Also see other comments mentioning that closet to the mean accepted by the tests is in fact the biggest, not the smallest.

Otherwise, it was fun :)