See the fork for a proposal of a C solution. Feel free to reject if you do not like the idea if this kata in C at all. Everyone, feel free to fork and improve if Johan likes the idea.
Generators, as any other kind of "object oriented" design, can be done in C in a way which is not that difficult concept-wise, but requires some boilerplate. Since C has no syntactic sugar for generators (nor pretty much anything else), it requires users to define a structure to hold the state of the generator, a generator function, a constructor function, and (possibly) a destructor function. All of these should be pretty simple, and I think still in scope of a 5 kyu or difficultish 6 kyu. Empty functions can be even provided by the solution setup.
I can prepare a draft of a C translation if you want.
The intention is very much to generate all infinitely many elements of the sequence, of which then at most a million will be tested. But the example solution should not approximate Infinity with a million; it should showcase how to generate infinitely many elements. All existing languages work this way. I have no idea if C has an appropriate datatype for this ( if it doesn't, it may have to be invented to translate this kata ).
Also, the language block in the description should match all other languages as closely as possible. This looks a bit loveless.
If you want to ( and can ) address these concerns, you can fork the translatrion, so your work is not lost.
I see what's wrong in your solution, added some more fixed and random tests to invalidate it. I was confused because the exception you added surely had nothing to do with your code passing by luck.
Yes, i am talking about the python version. I got my code runnable on 3rd try again. I got 2 Failures ("'98th' should equal '97th'", input is > 1000). This code shouldn't pass, but it does quite quickly.
That's weird because the control function expects "65th" for "6493" (you can test that yourself copying it) and there is not fixed test for that year, are we talking about Python version right?
Should be so. Therefore i pointed out this issue, because my solution did pass, which it shouldn't have.
I added this exception, because it showed me one test asser_equal("64th", getCentury(6493)).
The expected value for that year is 65, what your code returns is wrong. You can't expect random tests to cover all the years from 1000 to 9999, they're only 100. If by chance it would test for 6493 your code wouldn't pass.
See the fork for a proposal of a C solution. Feel free to reject if you do not like the idea if this kata in C at all. Everyone, feel free to fork and improve if Johan likes the idea.
Draft of a C translation. It is not complete yet, tests and descirption could use some work, I created it to showcase possible solution in C.
Generators, as any other kind of "object oriented" design, can be done in C in a way which is not that difficult concept-wise, but requires some boilerplate. Since C has no syntactic sugar for generators (nor pretty much anything else), it requires users to define a structure to hold the state of the generator, a generator function, a constructor function, and (possibly) a destructor function. All of these should be pretty simple, and I think still in scope of a 5 kyu or difficultish 6 kyu. Empty functions can be even provided by the solution setup.
I can prepare a draft of a C translation if you want.
I briefly considered translating this kata to C until I saw the term 'generator'
This is not what I want for the kata.
The intention is very much to generate all infinitely many elements of the sequence, of which then at most a million will be tested. But the example solution should not approximate Infinity with a million; it should showcase how to generate infinitely many elements. All existing languages work this way. I have no idea if C has an appropriate datatype for this ( if it doesn't, it may have to be invented to translate this kata ).
Also, the language block in the description should match all other languages as closely as possible. This looks a bit loveless.
If you want to ( and can ) address these concerns, you can fork the translatrion, so your work is not lost.
anyone fancy verifying translation ?
paperfolding sequence C translation
It is 4(36) so your calculation is wrong. The last digit of that is 4: https://www.wolframalpha.com/input/?i=%284%5E%283+%5E6%29%29+mod+10
You're doing this instead: (43)6
Found a false testcase "int[4,3,6]" in C#.
My calculation:
4 ^ 3 ^ 6 = 4 ^ 18 = 68.719.476.736
I expect 6 to be the last digit, or am i wrong ?
My Output:
SampleTest
Log
4:18
Test Failed
Expected: 4
But was: 6
iam sry for the confusion. i simply saw the failure and didnt examine it. thx for your help
I see what's wrong in your solution, added some more fixed and random tests to invalidate it. I was confused because the exception you added surely had nothing to do with your code passing by luck.
Yes, i am talking about the python version. I got my code runnable on 3rd try again. I got 2 Failures ("'98th' should equal '97th'", input is > 1000). This code shouldn't pass, but it does quite quickly.
That's weird because the control function expects "65th" for "6493" (you can test that yourself copying it) and there is not fixed test for that year, are we talking about Python version right?
Should be so. Therefore i pointed out this issue, because my solution did pass, which it shouldn't have.
I added this exception, because it showed me one test asser_equal("64th", getCentury(6493)).
The expected value for that year is 65, what your code returns is wrong. You can't expect random tests to cover all the years from 1000 to 9999, they're only 100. If by chance it would test for 6493 your code wouldn't pass.
i got this scrappy code runnable by setting an exception {if (year == 6493): return "64th"}
Loading more items...