6 kyu
Reversing Euclid's GCD. Parameters out of results
17 of 130Wittybit
Loading description...
Algorithms
.avif)
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.
Haskell translation
Approved
Nice kata!
Hi,
In python at least: the unique sample test is totally useless... => needs more than that one.
Cheers
At this point I can just port normal tests here (except for big ones)
fixed tests, yes, sure. :+1:
done
NASM: I recommend to move all preloaded code into tests and rewrite it in C.
[>] moved
NASM:
The user function should never modify
rbx.The result should be in
raxandrdx. Inline assembly is not necessary to get user results. Just return a struct with two fields.All auxiliary test functions must be
static(gcd,uinf_print,do_one_test).Thank you for the review! Now things should be more proper.
I still left some adscititious functions like print and convert available in case someone will want to use them.
There could probably be a harder version of this kata with higher iterations using a solution in O(log(iterations)) time
There might be! Mayhap if someone will make one (or when I'll come up with a solution that fast (I might have some ideas)).
This comment has been hidden.
Finally made a NASM version... which barely holds together.
Python new test framework should be used (Refer this & this for more detail)
Ruby 3.0 should be enabled (Refer this & this for more detail)
Looks like @FArekkusu has fixed the python tests already, so we can thank him now.
I don't know Ruby, so upgrading it might take a bit of time.
done
:^)In my opinion, the assertion messages are quite confusing as
divisoranditerationsare input arguments:Divisor is not wich was expected expected:<X> but was:<Y>Number of iterations doesn't match expected:<X> but was:<Y>I'd expect to see the error messages addressing output parameters instead.
Also, here is a few suggestions for the Java translation:
Too slow programtimeout, which I don't think could be done faster then O(iterations)I'll change speed checks (Or maybe remove them completely?) because rihht now they just check wether the provided solution is not more than 3x slower than the intended one (which perhaps fails for basic cases where time varies greatly).
A little typo in the description:
.. divisor of w[H]ich will be ..That was not the only typo, but thanks. I'm trying to fix things now.
This comment has been hidden.
I might have to take a look at that.
Nice idea for a kata! Thanks.
Thank you very much!