On Mon, Apr 27, 2015 at 2:43 AM, Benedikt Ritter <[email protected]> wrote:
> 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. > +1 Gary > > 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 > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
