Le 15/07/2011 02:37, Greg Sterijevski a écrit :
The usual issues with numerical techniques, how you calculate (c * x + d *
y)/e matters...
It turns out that religiously following the article and defining c_bar = c
/ e is not a good idea.
The Filippelli data is still a bit dicey. I would like to
I've changed that in the patch (removed the constructor).
Le 15/07/11 00:39, Gilles Sadowski a écrit :
On Thu, Jul 14, 2011 at 11:17:50AM -0700, Ted Dunning wrote:
This sort of need is actually common in my experience.
On Thu, Jul 14, 2011 at 9:37 AM, Phil Steitz wrote:
Currently, none of
On Thu, Jul 14, 2011 at 1:18 PM, Oliver Heger
wrote:
> The build runs fine for me with Java 1.5 and 1.6 on Windows 7. Artifacts
> look good.
>
> I was wondering why the binary distribution does not contain jars for the
> sources and javadocs, but this is probably not necessary because the
> artifa
On Thu, Jul 14, 2011 at 4:06 PM, Jörg Schaible wrote:
> Hi Hen,
>
> Henri Yandell wrote:
>
>> Lang is ready to consider 3.0 release again.
>>
>> RC4 is available here:
>>
>> http://people.apache.org/~bayard/commons-lang3-3.0-RC4/
>>
>> SVN:
>>
>> http://svn.apache.org/repos/asf/commons/proper/la
The usual issues with numerical techniques, how you calculate (c * x + d *
y)/e matters...
It turns out that religiously following the article and defining c_bar = c
/ e is not a good idea.
The Filippelli data is still a bit dicey. I would like to resolve where the
error is accumulating there as
Hi Hen,
Henri Yandell wrote:
> Lang is ready to consider 3.0 release again.
>
> RC4 is available here:
>
> http://people.apache.org/~bayard/commons-lang3-3.0-RC4/
>
> SVN:
>
> http://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC4/
>
> Maven artifacts:
>
> http://people.ap
On Thu, Jul 14, 2011 at 11:17:50AM -0700, Ted Dunning wrote:
> This sort of need is actually common in my experience.
>
> On Thu, Jul 14, 2011 at 9:37 AM, Phil Steitz wrote:
>
> > Currently, none of the implementations support this,
> > but nothing in the currently defined RealMatrix / Abstract
2011/7/15 Oliver Heger :
> The build runs fine for me with Java 1.5 and 1.6 on Windows 7. Artifacts
> look good.
>
> I was wondering why the binary distribution does not contain jars for the
> sources and javadocs, but this is probably not necessary because the
> artifacts are available at the mave
The build runs fine for me with Java 1.5 and 1.6 on Windows 7. Artifacts
look good.
I was wondering why the binary distribution does not contain jars for
the sources and javadocs, but this is probably not necessary because the
artifacts are available at the maven repository.
A minor nit: The
Am 14.07.2011 21:43, schrieb Matt Benson:
On Thu, Jul 14, 2011 at 2:36 PM, Henri Yandell wrote:
On Thu, Jul 14, 2011 at 12:12 PM, Oliver Heger
wrote:
Am 14.07.2011 21:01, schrieb Matt Benson:
On Thu, Jul 14, 2011 at 1:54 PM, Gary Gregory
wrote:
-1, let's pick up the committed fix for
h
On Thu, Jul 14, 2011 at 2:36 PM, Henri Yandell wrote:
> On Thu, Jul 14, 2011 at 12:12 PM, Oliver Heger
> wrote:
>> Am 14.07.2011 21:01, schrieb Matt Benson:
>>>
>>> On Thu, Jul 14, 2011 at 1:54 PM, Gary Gregory
>>> wrote:
-1, let's pick up the committed fix for
https://issues.apac
On Thu, Jul 14, 2011 at 12:12 PM, Oliver Heger
wrote:
> Am 14.07.2011 21:01, schrieb Matt Benson:
>>
>> On Thu, Jul 14, 2011 at 1:54 PM, Gary Gregory
>> wrote:
>>>
>>> -1, let's pick up the committed fix for
>>> https://issues.apache.org/jira/browse/LANG-720
>>>
>>> I recall seeing traffic in the
Am 14.07.2011 21:01, schrieb Matt Benson:
On Thu, Jul 14, 2011 at 1:54 PM, Gary Gregory wrote:
-1, let's pick up the committed fix for
https://issues.apache.org/jira/browse/LANG-720
I recall seeing traffic in the escape/unescape area so it makes sense to
polish this new code as much as possibl
On Thu, Jul 14, 2011 at 1:54 PM, Gary Gregory wrote:
> -1, let's pick up the committed fix for
> https://issues.apache.org/jira/browse/LANG-720
>
> I recall seeing traffic in the escape/unescape area so it makes sense to
> polish this new code as much as possible IMO.
>
Potential argument against
FYI: The Clirr report contains an extra "-" that breaks the link.
The fixed link is
http://people.apache.org/~bayard/commons-lang3-3.0-RC4/site/lang2-lang3-clirr-report.html
Gary
On Thu, Jul 14, 2011 at 12:47 AM, Henri Yandell wrote:
> Lang is ready to consider 3.0 release again.
>
> RC4 is av
-1, let's pick up the committed fix for
https://issues.apache.org/jira/browse/LANG-720
I recall seeing traffic in the escape/unescape area so it makes sense to
polish this new code as much as possible IMO.
Gary
On Thu, Jul 14, 2011 at 12:47 AM, Henri Yandell wrote:
> Lang is ready to consider
What was the problem?
On Wed, Jul 13, 2011 at 8:33 PM, Greg Sterijevski wrote:
> Phil,
>
> Got it! I fit longley to all printed values. I have not broken anything...
> I
> need to type up a few loose ends, then I will send a patch.
>
> -Greg
>
> On Tue, Jul 12, 2011 at 2:35 PM, Phil Steitz
> wro
This sort of need is actually common in my experience.
On Thu, Jul 14, 2011 at 9:37 AM, Phil Steitz wrote:
> Currently, none of the implementations support this,
> but nothing in the currently defined RealMatrix / AbstractRealMatrix
> API prevents subclasses from adding an addRows method, or su
On 7/14/11 8:39 AM, Phil Steitz wrote:
> On 7/14/11 3:49 AM, Gilles Sadowski wrote:
>> On Wed, Jul 13, 2011 at 03:01:09PM -0700, Ted Dunning wrote:
>>> Actually, this is a major issue.
>> Indeed, it is an important design issue.
>>
>>> Take, for instance, the example of considering a Lucene index a
On 7/14/11 3:49 AM, Gilles Sadowski wrote:
> On Wed, Jul 13, 2011 at 03:01:09PM -0700, Ted Dunning wrote:
>> Actually, this is a major issue.
> Indeed, it is an important design issue.
>
>> Take, for instance, the example of considering a Lucene index as a linear
>> operator. The number of rows is
Hello.
> Indeed it was not easy to get the thing converted.
I hadn't understood that the work was done already.
> I will apply all the
> tests
> I already wrote for CMA-ES (they could be refactored out in a separate
> class later). The last two bugs I detected resulted only in
> a slight perform
Indeed it was not easy to get the thing converted. I will apply all the
tests
I already wrote for CMA-ES (they could be refactored out in a separate
class later). The last two bugs I detected resulted only in
a slight performance decrease and were only detected by debugging both
programs in paralle
Hello.
> [...]
> >>I would like to commit a Java port of the algorithm to commons.math.
> >>I maintained the structure of the original FORTRAN code, so the
> >>code is fast but not very nice.
>
> I guess it could be put in [math] first as is, with the same Fortran
> struture,
-1
I could help wi
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
Having immutable objects was what I initially had in mind, but I can
live with the other approach. Only, as rightly pointed out by others,
what I had implemented initially was not compatible with
AbstractRealMatrix. The new patch no longer implements getRowDimension()
and getColumnDimension().
Hi Sébastien.
> Happy 14th of July to all!
> OK, from what I understand, the patch I submitted yesterday does not
> comply with your requirements, as I provided a constructor for
> RealLinearOperator, with dimensions of the domain and codomain as
> parameters. Implicitely, I intended these to be f
On Wed, Jul 13, 2011 at 03:01:09PM -0700, Ted Dunning wrote:
> Actually, this is a major issue.
Indeed, it is an important design issue.
> Take, for instance, the example of considering a Lucene index as a linear
> operator. The number of rows is the number of documents (which is changing
> as d
Thanks Luc and Ted,
that's clear enough.
I'm looking forward to keep on working on linear operators and iterative
solvers when I'm back.
Sebastien
Le 14/07/11 10:24, Luc Maisonobe a écrit :
Hi Sébastien,
Le 14/07/2011 09:44, Ted Dunning a écrit :
Because when the interface changes, an abstra
Here is the letter from the Autor which I received yesterday.
There seems to be no problem regarding a signed agreement.
I will send him our conversation, so you can get directly in contact.
"Dear Dr Wolz,
Many thanks for your e-mail. I was delighted to hear of your interest in
BOBYQA and
Le 14/07/2011 00:02, Ted Dunning a écrit :
What is the license on the original Fortran code?
There seem to be no license expressed, so we merely have to ask to the
author. The PDF paper just states at the end that it is available "free
of charge". I guess the author does not really care about
Hi Sébastien,
Le 14/07/2011 09:44, Ted Dunning a écrit :
Because when the interface changes, an abstract class can add default
implementations (even if the implementations only throw unimplemented
operation exceptions).
That means that code that has used the abstract class won't have to break.
Because when the interface changes, an abstract class can add default
implementations (even if the implementations only throw unimplemented
operation exceptions).
That means that code that has used the abstract class won't have to break.
If you change an interface, the implementing code inevitabl
32 matches
Mail list logo
