5 kyu
Minimum and Maximum Product of k Elements - Advanced
72 of 113anter69
Loading description...
Arrays
Lists
Performance
Algorithms
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.
A truly excellent kata. Thanks @anter69.
Thanks!
Python 3.8 should be enabled.
it is/was already enabled :-)
Nobody removed it from the list of katas with 3.8 disabled on github, and I haven't completed the kata myself to verify. If it's already enabled, then fine.
Could someone help me with, what to do in case k is bigger than the size of vector for c++? What to return in this case? My code solves correct for examples that have k less than size.
According to the sample tests it should throw an error:
C++ version generates warnings.
Fixed
This comment has been hidden.
Only two complaints I have:
in Ruby at least (surely in Python too, and any language with automatic BigInt conversion) the array elements are Integers only and the min/max products may go way beyond
Float::MINandFloat::MAX. Might be good to specify it in the description so nobody tries to multiply the thing by a float.It's a detail, but judging from the test cases, k is a strictly positive integer. I wondered a bit whether I should return
1in the casek == 0, but it was never tested. Adding it directly to the description might be clearer.Once again, you did a very good work on this kata series. Kudos.
Description updated
That kata is really VERY GOOD! A very simple description with a quite challenging task to optimize and make a "cute" solution.
Validation tests could be much harder though, I even thought you made a crazy version of this at first. A robust solution should handle arrays of 100,000 with k in range(1, 200) at least. I'm saying at least because I suck at optimizing and even I could do that. (I can only handle ~200 of them in Ruby, but I'm quite sure you can get up to 1000)
Thanks for the compliment :-)
I'll look into improving the tests, although generating and handling large arrays (as suggested) is rather expensive. Furthermore, you get results with multiple thousand of digits...
Decription's link to Minumum and Maximum Product of k Elements is dead.
fixed typo & link
thanks!
This comment has been hidden.
Added tests
Mmmmh.. Two solutions have been wiped out. Is that due to an intentionnal modification? If not, you should seek for the related edge cases ;)
I twisted a bit the test cases, and I saw that those solutions were invelidated, but I couldn't find the problem with them yet...
seems related to arrays containing only negative numbers.
Yes, I found it also, and added a fixed test for that :-)
The kata is very interesting but it needs further instructions. For example, the array input: may it have repeated elements? Because that will change the solution (comparing the previous kata). Also it would be good to know the maximum values for the tests:
-maximum value of k
-maximum absolute values for the integers in the array
Updated the description a bit.
Btw, duplicates were possible in the previous kata as well...
your fixed tests are "vulnerable" to input mutation (not that they could be bypassed, but a user could end up having troubles if he mutates the input).
Fixed.
you should push the things way harder, IMO (my current solution is 4 times faster than yours (using
N_TEST=800in a fork, without theit/assert_equals).This comment has been hidden.
I could push it some more (and will probably increase the number of tests a little), but the basic idea was to make the naive solutions obsolete.
ok, but your current soluiton is somewhat "naive" too (just not the most naive one, I'd say). Would be good to push at least the thing to 5 kyu (but it's up to you, ofc).