You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by "Bruno P. Kinoshita" <br...@yahoo.com.br> on 2015/04/27 10:49:56 UTC

Re: [lang] https://issues.apache.org/jira/browse/LANG-1099

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)

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

Re: [lang] https://issues.apache.org/jira/browse/LANG-1099

Posted by Gary Gregory <ga...@gmail.com>.

On Mon, Apr 27, 2015 at 2:43 AM, Benedikt Ritter <br...@apache.org> 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 <be...@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 <be...@yahoo.com.INVALID>
> >  To: "dev@commons.apache.org" <de...@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
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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

Re: [lang] https://issues.apache.org/jira/browse/LANG-1099

Posted by Benedikt Ritter <br...@apache.org>.

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

Re: [lang] https://issues.apache.org/jira/browse/LANG-1099

Posted by Adrian Ber <be...@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 <br...@yahoo.com.br> wrote:

Hi Adrian,

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