|
|
|
:I get it now. Rather than getting the max then plucking those with that length from a list, you calculate the length sort on it and store it, then select from the maximum end of the sorted list until the length is no longer equal to the length of the first. Neat. Thanks for taking the time to explain. --[[User:Paddy3118|Paddy3118]] 21:07, 20 September 2011 (UTC)
:Sorting is slow because it takes O(n log n) time; whereas finding the maximum and filtering a list takes linear time. YouIt areis correcttrue that yoursorting previousis solutionbeing alsodone usedregardless sorting,(because byof the <code>groupby(sorted(...))</code>), andso thusboth alsoyour incurredprevious the cost of sorting,example and thus was no better. However, the solutionscurrent thatexample use sortingtake O(Tonyjv'sn solutionlog and the other one using groupbyn) aretime stilloverall. inferiorBut tosince the solutionsgrouping that use a hash table based dictionary or equivalent (defaultdict) to grouppart and thenthe scan for thefinding maximum andlength filterpart theare listindependent, whichI aredon't muchsee fasterhow --choosing lineara timeslower onalgorithm averagefor --the assuminglatter thepart hashwill functionimprove isthe notalgorithm terribleoverall. --[[User:Spoon!|Spoon!]] 01:43, 21 September 2011 (UTC)
|