Fixed C and C++ test code. Sorry for the oversight.
Same occurs for C - took me some time before I realized source of not correct values.
Would be cool to add odd numbers of a and b to basic tests for next who will be trying to pass this kata.
Yes, now it works for me too.
Should be fixed, please check ;-)
(The reference solution used to calculate carmichael(2) = 0, which I've fixed)
carmichael(2) = 0
Why does the test say for example for n = 2903225426
Expected: 0, instead got: 60453792
When clearly 60453792 should be the correct solution, even Wolfram Alpha confirms this.
PS. And it's the JS version I'm trying, (if there are others :D)
aaaaah.... Good point. I will add a test for that, thx. :)
This comment is hidden because it contains spoiler information about the solution
Mmmmh, that's weird, because I have some tests that should have seen that kind of problems. Maybe there are several intricated things, in your faulty code?
Do you remember what kind of command was exactly involved? add? bounder? add_chaining?
I have currently things like this:
#Invalid \"bounder\" command resulting in butyne skeleton with valid operations:
Molecule().brancher(4).bounder((3,1,2,1), (3,1,2,1), (3,1,2,1))
exp = ['Atom(C.1: C2)', 'Atom(C.2: C1,C3,C3,C3)', 'Atom(C.3: C2,C2,C2,C4)', 'Atom(C.4: C3)']
Here, during the last bounding and from what I understand of what you said, it feels like your code should have failed because you'd have gotten something like:
'Atom(C.1: C2)', 'Atom(C.2: C1,C3,C3,C3,C3)', 'Atom(C.3: C2,C2,C2,C4)', 'Atom(C.4: C3)'
'Atom(C.1: C2)', 'Atom(C.2: C1,C3,C3,C3)', 'Atom(C.3: C2,C2,C2,C4)', 'Atom(C.4: C3)'
Obvisouly, that's not what happened to you, so I wonder what is the underlying "other" bug... :o
I mean the case when we make a bond but it is invalid and will throw an Error. I was still making X bond to Y but then the execution would fail and throw an error (because I was testing the valence-ok:ness separately, not testing both first and only then making the bonds if ok, as it should be done). I guess the fixed tests doesn't include a test for this situation, at least I passed them with my then faulty Atom.connectTo -method.
Glad you liked it. :)
About your suggestion, I'm not sure I'm following, becasue, from what I currently understand, this should have been catch by the fixed tests: normally, if one atom is bonded to another, but not the opposite, the string representation should be unbalanced about those. Like Atom(C4: C2,Y4,H,H), ..., Atom(Y4,H,H) where Y4->C4 isn't present, for example. Unless your toString implementation isn't correct or you had that problem about an explicit bond with a H when you get the error. Would you still have the data about that test, by any chance? (commands/inputs and you actual output)
Atom(C4: C2,Y4,H,H), ..., Atom(Y4,H,H)
Very good kata! A lot of work, but so rewarding when you get it right. This also thought me about JS classes (I've come accross them but never looked at them more deeply, I just always used functions and prototypes. But these getters and setters are awesome, although it might feel strange at first when you access the variable just like it were a normal paramater, btw is this how for example the canvas drawing context works: when you try to set for example context.fillStyle = "something", it is set to black?) Well I digress.
One possible suggestion I would make is to test the following: If we make a bond between two elements X and Y, and it is invalid, we set neither X to have Y as bondee nor Y X. I had this bug, where I would let the first happen even if the second would fail. Was only caught in the random tests and it was kind of a hassle to hunt down. Of course is seems obvious now :D.