commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [lang] https://issues.apache.org/jira/browse/LANG-1099
Date Mon, 27 Apr 2015 09:43:55 GMT
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 <beradrian@yahoo.com.invalid>:

> 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 <
> brunodepaulak@yahoo.com.br> 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 <beradrian@yahoo.com.INVALID>
>  To: "dev@commons.apache.org" <dev@commons.apache.org>
>  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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message