https://issues.apache.org/jira/browse/LANG-1099

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

https://issues.apache.org/jira/browse/LANG-1099

Adrian Ber
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
Reply | Threaded
Open this post in threaded view
|

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

Bruno P. Kinoshita
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 <[hidden email]>
 To: "[hidden email]" <[hidden email]>
 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

   
Reply | Threaded
Open this post in threaded view
|

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

Adrian Ber
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 <[hidden email]> 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 <[hidden email]>
 To: "[hidden email]" <[hidden email]>
 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

 

 
Reply | Threaded
Open this post in threaded view
|

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

Benedikt Ritter-4
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 <[hidden email]>:

> 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 <
> [hidden email]> 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 <[hidden email]>
>  To: "[hidden email]" <[hidden email]>
>  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
Reply | Threaded
Open this post in threaded view
|

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

garydgregory
On Mon, Apr 27, 2015 at 2:43 AM, Benedikt Ritter <[hidden email]> 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 <[hidden email]>:
>
> > 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 <
> > [hidden email]> 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 <[hidden email]>
> >  To: "[hidden email]" <[hidden email]>
> >  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: [hidden email] | [hidden email]
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