[Math] Could StatUtils use a method to find the index of the maximum value.
It currently has the maximum of a double array. -Ajo.
Re: [OT] Anyone going to JavaOne?
Not going, though I do seem to manage to get myself into the afterparties/happy hours every year. -- H On 19 September 2013 13:53, Ted Dunning wrote: > I am not going, but we have a ton of guys there. > > Drop by the MapR booth and say hi! > > > > > On Thu, Sep 19, 2013 at 12:50 PM, James Carman > wrote: > > > Is anyone planning on going? It would be great to meet some of you > > guys face-to-face for once, if you're going to be there. > > > > James > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Sent from my mobile device Envoyé de mon portable
Re: [OT] Anyone going to JavaOne?
I am not going, but we have a ton of guys there. Drop by the MapR booth and say hi! On Thu, Sep 19, 2013 at 12:50 PM, James Carman wrote: > Is anyone planning on going? It would be great to meet some of you > guys face-to-face for once, if you're going to be there. > > James > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[OT] Anyone going to JavaOne?
Is anyone planning on going? It would be great to meet some of you guys face-to-face for once, if you're going to be there. James - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OT] Anyone going to JavaOne?
On 19/09/2013 20:50, James Carman wrote: > Is anyone planning on going? It would be great to meet some of you > guys face-to-face for once, if you're going to be there. I'll be there. I'm speaking. [1] Mark [1] https://oracleus.activeevents.com/2013/connect/sessionDetail.ww?SESSION_ID=3651 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] DS: An alternative to DerivativeStructure
Hi Luc, I'll work on tests when I get a chance. RealFieldElement has a lot of functions so its a bit out of my way. Cheers, -Ajo On Thu, Sep 19, 2013 at 10:58 AM, Luc Maisonobe wrote: > Hi Ajo, > > Le 19/09/2013 16:26, Ajo Fod a écrit : > > Created: > https://issues.apache.org/jira/browse/MATH-1036#comment-13771933 > > This looks promising. Would it be possible to have this class implement > RealFieldElement and to have some unit tests? > > best regards, > Luc > > > > > > > > > On Thu, Sep 19, 2013 at 12:29 AM, luc wrote: > > > >> Le 2013-09-19 08:26, Ajo Fod a écrit : > >> > >>> Hello, > >>> > >> > >> Hi Ajo, > >> > >> > >> > >>> Ran into problems with DerivativeStructure today. It requires a lot of > >>> memory with 6000 or so independent variables. I poked around and found > >>> it the problem starts with the number of DSCompiler objects > >>> instantiated. > >>> > >> > >> Yes, this is a know side effect of the ability to handle both several > >> variables > >> and several derivative orders. It is even worse when you combine medium > >> numbers > >> but along both axes (say 20 derivatives and 20 variables, I guess it is > >> almost > >> impossible to fir in memory of regular desktop computers). > >> > >> > >> > >>> Given this and my earlier observation that in sparse derivative trees, > >>> the existing structure allocates space for all independent variables > >>> and hence is computationally inefficient, I designed a > >>> faster/leaner(less memory) structure. > >>> > >>> One shortcomming of DS is that it computes only up to the first > >>> derivative. This may not be a problem in many cases such as the > >>> minimization of a multivariate function where optimization can be much > >>> quicker with a gradient. Going as far as the hessian may be > >>> fundamentally too memory or time intensive. So, it is useful to have > >>> an easier method to computing just the first derivative. > >>> > >> > >> This sound interesting, I hope it could be added as a more specialized > >> alternative. The name should probably be adapted to reflect it is > designed > >> for order 1 and many variables (perhaps DerivativeStructure1N or > something > >> like that). > >> > >> > >> > >>> The design of DS is that all DS instances created either as a results > >>> of calling: > >>> > >>> DS.getConst(value); // for constants > >>> > >>> DS.getVariable(idx, value); // for independent variables > >>> > >>> ... OR as a rest of some computation. > >>> > >>> I felt it appropriate to add an addInPlace and multInPlace for > >>> aggregation processes so that objects are not copied over too often. > >>> > >> > >> If you handle a really large number of variables at the same time, it > >> makes sense (same discussion as why general matrices and vectors are > often > >> not immutable). > >> > >> > >>> Attached is the code. > >>> > >> > >> Attachments are automatically stripped from messages sent to the list. > >> Small > >> code snippets can be written directly in the mail, but larger > >> contributions can > >> only be attached to JIRA issues (but still discussion occurs on the > list, > >> yes, > >> its cumbersome, we are sorry for that). > >> > >> Thank you very much for you interest in this field of differentiation. > >> > >> best regards, > >> Luc > >> > >> > >>> Cheers, > >>> Ajo > >>> > >>> > >>> > --**--**- > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org< > dev-unsubscr...@commons.apache.org> > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >> > >> > --**--**- > >> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org< > dev-unsubscr...@commons.apache.org> > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Math] DS: An alternative to DerivativeStructure
Hi Ajo, Le 19/09/2013 16:26, Ajo Fod a écrit : > Created: https://issues.apache.org/jira/browse/MATH-1036#comment-13771933 This looks promising. Would it be possible to have this class implement RealFieldElement and to have some unit tests? best regards, Luc > > > > On Thu, Sep 19, 2013 at 12:29 AM, luc wrote: > >> Le 2013-09-19 08:26, Ajo Fod a écrit : >> >>> Hello, >>> >> >> Hi Ajo, >> >> >> >>> Ran into problems with DerivativeStructure today. It requires a lot of >>> memory with 6000 or so independent variables. I poked around and found >>> it the problem starts with the number of DSCompiler objects >>> instantiated. >>> >> >> Yes, this is a know side effect of the ability to handle both several >> variables >> and several derivative orders. It is even worse when you combine medium >> numbers >> but along both axes (say 20 derivatives and 20 variables, I guess it is >> almost >> impossible to fir in memory of regular desktop computers). >> >> >> >>> Given this and my earlier observation that in sparse derivative trees, >>> the existing structure allocates space for all independent variables >>> and hence is computationally inefficient, I designed a >>> faster/leaner(less memory) structure. >>> >>> One shortcomming of DS is that it computes only up to the first >>> derivative. This may not be a problem in many cases such as the >>> minimization of a multivariate function where optimization can be much >>> quicker with a gradient. Going as far as the hessian may be >>> fundamentally too memory or time intensive. So, it is useful to have >>> an easier method to computing just the first derivative. >>> >> >> This sound interesting, I hope it could be added as a more specialized >> alternative. The name should probably be adapted to reflect it is designed >> for order 1 and many variables (perhaps DerivativeStructure1N or something >> like that). >> >> >> >>> The design of DS is that all DS instances created either as a results >>> of calling: >>> >>> DS.getConst(value); // for constants >>> >>> DS.getVariable(idx, value); // for independent variables >>> >>> ... OR as a rest of some computation. >>> >>> I felt it appropriate to add an addInPlace and multInPlace for >>> aggregation processes so that objects are not copied over too often. >>> >> >> If you handle a really large number of variables at the same time, it >> makes sense (same discussion as why general matrices and vectors are often >> not immutable). >> >> >>> Attached is the code. >>> >> >> Attachments are automatically stripped from messages sent to the list. >> Small >> code snippets can be written directly in the mail, but larger >> contributions can >> only be attached to JIRA issues (but still discussion occurs on the list, >> yes, >> its cumbersome, we are sorry for that). >> >> Thank you very much for you interest in this field of differentiation. >> >> best regards, >> Luc >> >> >>> Cheers, >>> Ajo >>> >>> >>> --**--**- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@commons.**apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --**--**- >> To unsubscribe, e-mail: >> dev-unsubscribe@commons.**apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] DS: An alternative to DerivativeStructure
Created: https://issues.apache.org/jira/browse/MATH-1036#comment-13771933 On Thu, Sep 19, 2013 at 12:29 AM, luc wrote: > Le 2013-09-19 08:26, Ajo Fod a écrit : > >> Hello, >> > > Hi Ajo, > > > >> Ran into problems with DerivativeStructure today. It requires a lot of >> memory with 6000 or so independent variables. I poked around and found >> it the problem starts with the number of DSCompiler objects >> instantiated. >> > > Yes, this is a know side effect of the ability to handle both several > variables > and several derivative orders. It is even worse when you combine medium > numbers > but along both axes (say 20 derivatives and 20 variables, I guess it is > almost > impossible to fir in memory of regular desktop computers). > > > >> Given this and my earlier observation that in sparse derivative trees, >> the existing structure allocates space for all independent variables >> and hence is computationally inefficient, I designed a >> faster/leaner(less memory) structure. >> >> One shortcomming of DS is that it computes only up to the first >> derivative. This may not be a problem in many cases such as the >> minimization of a multivariate function where optimization can be much >> quicker with a gradient. Going as far as the hessian may be >> fundamentally too memory or time intensive. So, it is useful to have >> an easier method to computing just the first derivative. >> > > This sound interesting, I hope it could be added as a more specialized > alternative. The name should probably be adapted to reflect it is designed > for order 1 and many variables (perhaps DerivativeStructure1N or something > like that). > > > >> The design of DS is that all DS instances created either as a results >> of calling: >> >> DS.getConst(value); // for constants >> >> DS.getVariable(idx, value); // for independent variables >> >> ... OR as a rest of some computation. >> >> I felt it appropriate to add an addInPlace and multInPlace for >> aggregation processes so that objects are not copied over too often. >> > > If you handle a really large number of variables at the same time, it > makes sense (same discussion as why general matrices and vectors are often > not immutable). > > >> Attached is the code. >> > > Attachments are automatically stripped from messages sent to the list. > Small > code snippets can be written directly in the mail, but larger > contributions can > only be attached to JIRA issues (but still discussion occurs on the list, > yes, > its cumbersome, we are sorry for that). > > Thank you very much for you interest in this field of differentiation. > > best regards, > Luc > > >> Cheers, >> Ajo >> >> >> --**--**- >> To unsubscribe, e-mail: >> dev-unsubscribe@commons.**apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [COLLECTIONS] CollectionUtils.adapterCollection(Collection, Transformer)?
Hi John, I've attached my form. Thanks, Evan On Wed 18 Sep 2013 09:23:10 PM EDT, Bruno P. Kinoshita wrote: > True, maybe with EachElement and a Procedure [1], or maybe > IteratorToGeneratorAdapter, or something similar to the > ArrayListBackedAggregator and some custom function :) Or maybe with something > totally new. > > [1] https://gist.github.com/kinow/6617618 > > From: Matt Benson > To: Commons Developers List > Sent: Wednesday, September 18, 2013 5:29 PM > Subject: Re: [COLLECTIONS] CollectionUtils.adapterCollection(Collection, > Transformer)? > > > Looks like a job for [functor]. > > Matt > On Sep 18, 2013 2:59 PM, "Benedikt Ritter" wrote: > >> Hi, >> >> At work, I needed to create an adapter for an existing class that has a >> getter for a collection of objects. Now in my adapter I want to create a >> getter for a collection of adapted objects. >> I don't want to create a new list an add adapters for the contained objects >> to it. I just want to create the adapters on the fly when they are >> requested. >> >> I thought this should be implemented somewhere in commons-collections, but >> I could not find anything like that. I wonder if it would make sense to >> create such functionality. I have created an example at github [1]. What do >> you think? Am I missing something here? >> >> Regards, >> Benedikt >> >> [1] https://gist.github.com/britter/6614535 >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > business_cards_final.pdf Description: Adobe PDF document smime.p7s Description: S/MIME Cryptographic Signature
Re: [Math] DS: An alternative to DerivativeStructure
Le 2013-09-19 08:26, Ajo Fod a écrit : Hello, Hi Ajo, Ran into problems with DerivativeStructure today. It requires a lot of memory with 6000 or so independent variables. I poked around and found it the problem starts with the number of DSCompiler objects instantiated. Yes, this is a know side effect of the ability to handle both several variables and several derivative orders. It is even worse when you combine medium numbers but along both axes (say 20 derivatives and 20 variables, I guess it is almost impossible to fir in memory of regular desktop computers). Given this and my earlier observation that in sparse derivative trees, the existing structure allocates space for all independent variables and hence is computationally inefficient, I designed a faster/leaner(less memory) structure. One shortcomming of DS is that it computes only up to the first derivative. This may not be a problem in many cases such as the minimization of a multivariate function where optimization can be much quicker with a gradient. Going as far as the hessian may be fundamentally too memory or time intensive. So, it is useful to have an easier method to computing just the first derivative. This sound interesting, I hope it could be added as a more specialized alternative. The name should probably be adapted to reflect it is designed for order 1 and many variables (perhaps DerivativeStructure1N or something like that). The design of DS is that all DS instances created either as a results of calling: DS.getConst(value); // for constants DS.getVariable(idx, value); // for independent variables ... OR as a rest of some computation. I felt it appropriate to add an addInPlace and multInPlace for aggregation processes so that objects are not copied over too often. If you handle a really large number of variables at the same time, it makes sense (same discussion as why general matrices and vectors are often not immutable). Attached is the code. Attachments are automatically stripped from messages sent to the list. Small code snippets can be written directly in the mail, but larger contributions can only be attached to JIRA issues (but still discussion occurs on the list, yes, its cumbersome, we are sorry for that). Thank you very much for you interest in this field of differentiation. best regards, Luc Cheers, Ajo - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
