I'm all for the O(1), O(n) solution. If we have a good test coverage, we can work on the readability of the code. I can merge the feature after we have finished the svn -> git migration.
br, Benedikt 2015-04-27 11:01 GMT+02:00 Adrian Ber <[email protected]>: > Hi Bruno, > Yes, I will add comments and I will even post on my blog a detailed > explanation and proof that the algorithm complexities are indeed as I said. > > Thanks, > Adrian Ber > > > > On Monday, 27 April 2015, 11:54, Bruno P. Kinoshita < > [email protected]> wrote: > > > > Hi Adrian, > > Thanks for bringing the discussion to the mailing list. I believe you > explained well the existing issue. > I had a quick look at the code, but didn't really investigate the > algorithm space and time complexities. Assuming we have the scenario you > described with O(1) and O(n), my vote is: > [+1] Performance > [+0] Simpler code (I'm ok if the majority prefers this one too) > > However I believe @rfalke makes a fair point about the code maintenance. > So my only requirement for the solution with better performance, would be > that the code has good tests (simple to read, and with good coverage) and, > perhaps, some comments to explain what's going on to other developers that > could have trouble understanding the code. > All the best > Bruno > > From: Adrian Ber <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Monday, April 27, 2015 8:19 PM > Subject: https://issues.apache.org/jira/browse/LANG-1099 > > Hi everyone, > As per kinow (Bruno P. Kinoshita) recommendation, I'm writing to this > mailing list about commons-lang issue > https://issues.apache.org/jira/browse/LANG-1099. I created a pull > request: https://github.com/apache/commons-lang/pull/47. This generated a > discussion between two possible solutions for shift operation for arrays. > I'm proposing a solution in O(n) time complexity and O(1) space > complexity. On the other hand rfalke is proposing a solution in O(n) time > complexity and O(n) space complexity, arguing that the first solution, even > though better from a performance standpoint, could be harder to understand. > I hope I summarized correctly the discussion so far. What do you think? > In my opinion, especially taking into account that we're talking about a > generic library, I'll favor the optimized solution. I doubt that any user > of the library will complain about the code readability, as long as the > solution provided works as advertised. As the API is the same in both > cases, users will consider it a black box and will use it as such. If it > would been an end-user system and such options would have been affecting > the overall architecture decisions, then, depending on the performance > requirements of the system, I'd favor an easier to understand solution. > Thank you, > Adrian Ber > > > > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
