6 kyu
van Eck sequences
34 of 36JohanWiltink
Loading description...
Algorithms
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Scala Translation submitted.
Approved. Thank you!
( And thanks for fixng the Javascript description bug! )
It is not clear from the instruction if functions other that
term
will be called before the sequence has grown enough. For Example, given the Van Eck Series: 0, 0, 1, 0, 2, 0, 2, 2, 1, 6, ...Is this an expected test case?
The test cases seem to always have enough calls to
.term
to let the sequence grow, however, the description reads as if there is no specific order in which the functions will be called.My question is: I'm working on translation this to Scala. Should i have a test case as described above? If yes: Will the difficulty of the kata be different between Javascript and Scala? If no: Should the Kata description be updated to reflect this clarification?
Or is it Secret Option no C: I'm blind and the original JS kata does infact test for such "out-of-order" calls?
Thanks for reading all that!
The description does not specify any order for calling methods, and it's secret option C: the random tests will very probably generate tests where methods other than
term
will be called with arguments that have not been generated byterm
. Note that the reference solution solves this by explicitly callingterm
before accessing the other methods.It would be possible to add a fixed test that addressed this hypothetical vulnerability, but it hardly seems worth it.
Does this answer your question?
Yes it did! I did assume that the random test does not guarantee the order of funtion calls. I am thinking of adding this as a fixed and random test, just so that it is explicitly checked every time. It's pretty straight forward the way im writing unit tests, and ensures that this behaviour is captured
Hope that doesn't violate any translation rules!
When I saw the "Don't Know"s, I instanly thought Numberphile
Any python/ruby translation forseen?
Not by me; I only speak JavaScript and Haskell. You're welcome to submit one ( yes please! ).
Mind that you don't accidentally randomly generate a seed of multiple
1
s only - strange things happen .. :PUnfortunately, I don't know JS nor haskell yet, so I'll have to wait...
After seeing how first 2 van Eck katas went, I didn't expect anyone to touch this sequence again :P It looks like the twists you added made it good enough, and hard enough. Well done!
One minor issue I have is: why is the method to find max number called
fast
? It has nothing to do with speed and it threw me off-guard :( Why not just call it max / maxSomething?"How fast does it grow?"
I considered asking for the rate of growth, but that would have been a float ( well, a rational ).
A Haskell translation may be forthcoming. Watch this space ..
Still working on it. Performance is rather disappointing ( two orders of magnitude :/ ).
I guess it's not going to happen.