True enough.
Maybe the use of one those two could be strongly discouraged.
I personally was puzzled the first time I saw those two methods. I was
even wondering wether one of them would not return a shallow copy
(when possible), while the other would return a deep copy. Had to look
at the source to
2011/9/7 Sébastien Brisard :
> Hi,
> as noted in MATH-653, these two methods are redundant, and one should
> go. Pros and cons are
> * toArray() is fairly classical in the Java world
> * but getData() is consistent with ArrayRealVector.getDataRef().
> Personnaly, my preference goes to keeping toArr
In fact, getArrayRef does not belong to the RealVector class. It is
only defined in ArrayRealVector (which is backed by a double[]).
Sébastien
2011/9/7 Arne Ploese :
> If toArray() returns always a copy and if getArrayRef() throws an
> exception if there is no backing array, it would be much clear
If toArray() returns always a copy and if getArrayRef() throws an
exception if there is no backing array, it would be much clearer. A
property isArray() is needed in this case.
Arne
Am Mittwoch, den 07.09.2011, 04:19 +0200 schrieb Sébastien Brisard:
> Hi,
> as noted in MATH-653, these two method
On Wed, Sep 7, 2011 at 12:22 AM, Ralph Goers wrote:
> Why is the idea plugin defined? IntelliJ hasn't needed it in a long time.
>
Good question.
Should we get rid of it?
The warning at the start of all commons build is annoying.
Gary
>
> Ralph
>
> On Sep 6, 2011, at 7:23 PM, Gary Gregory wr
Why is the idea plugin defined? IntelliJ hasn't needed it in a long time.
Ralph
On Sep 6, 2011, at 7:23 PM, Gary Gregory wrote:
> Hi All:
>
> It feels like it's about time to vote on releasing version 22?
>
> Thoughts?
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in
Hi All:
It feels like it's about time to vote on releasing version 22?
Thoughts?
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://s.apache.org/rl
Spring Batch in Action: http://s.apache.org/HOq
Blog: http://garygregory.wordpress.com
Home: http://garygregor
Hi,
as noted in MATH-653, these two methods are redundant, and one should
go. Pros and cons are
* toArray() is fairly classical in the Java world
* but getData() is consistent with ArrayRealVector.getDataRef().
Personnaly, my preference goes to keeping toArray(). In order to
maintain consistency, s
I don't think MATH-653 has been marked as resolved...
2011/9/6 Gilles Sadowski :
>> [...]
>> >
>> >>Also, when
>> >>opening a new ticket, should it be assigned to someone, if this person
>> >>agrees to take care of it?
>> >
>> >If you are willing to fix some issue, you should probably assign it to
Hi,
please let me know what you think of the modified code I've attached
to MATH-655. I took Phil's into account (composition vs. inheritance).
I believe the provided classes would go into o.a.c.m.util.
Thanks beforehand for your comments,
Sébastien
On 7 September 2011 00:04, Gilles Sadowski wrote:
> Hello.
>
>> Modified:
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1165846&r
Hello.
> Modified:
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1165846&r1=1165845&r2=1165846&view=diff
> =
On Tue, Sep 6, 2011 at 4:53 PM, sebb wrote:
> On 6 September 2011 17:55, Gary Gregory wrote:
> > Here is the current set up:
> >
> > - To run tests: Same as before: "mvn test"
> > - To runt tests with the Java security manager: comment out some XML in
> the
> > POM and run "mvn integration-test"
On 6 September 2011 19:47, Oliver Heger wrote:
> Am 06.09.2011 04:40, schrieb sebb:
>>
>> On 5 September 2011 21:20, sebb wrote:
>>>
>>> On 5 September 2011 19:19, Oliver Heger
>>> wrote:
Am 05.09.2011 15:52, schrieb sebb:
>
> On 5 September 2011 10:42, Oliver Heger
> wrot
On 6 September 2011 17:55, Gary Gregory wrote:
> Here is the current set up:
>
> - To run tests: Same as before: "mvn test"
> - To runt tests with the Java security manager: comment out some XML in the
> POM and run "mvn integration-test"
>
> The policy file does for Sufire+JUnit 4 what Surefire d
Am 06.09.2011 04:40, schrieb sebb:
On 5 September 2011 21:20, sebb wrote:
On 5 September 2011 19:19, Oliver Heger wrote:
Am 05.09.2011 15:52, schrieb sebb:
On 5 September 2011 10:42, Oliver Heger
wrote:
Am 05.09.2011 02:03, schrieb sebb:
On 4 September 2011 20:07, Oliver Heger
wrote
> [...]
> >
> >>Also, when
> >>opening a new ticket, should it be assigned to someone, if this person
> >>agrees to take care of it?
> >
> >If you are willing to fix some issue, you should probably assign it to
> >yourself. That would help prevent duplicate work.
>
> As far as I know, it's this ot
Le 06/09/2011 14:29, Gilles Sadowski a écrit :
Hello.
Hi,
as agreed in this ticket, references to double[] solve(double[]) have
been wiped out from all decomposition solvers.
That's done already but might have been the object of another JIRA ticket,
as the changes did not depend on "RealV
Here is the current set up:
- To run tests: Same as before: "mvn test"
- To runt tests with the Java security manager: comment out some XML in the
POM and run "mvn integration-test"
The policy file does for Sufire+JUnit 4 what Surefire does by itself for
JUnit 3: It grants Surefire and JUnit just
On 6 September 2011 17:16, Gary Gregory wrote:
> On Tue, Sep 6, 2011 at 11:14 AM, sebb wrote:
>
>> On 6 September 2011 15:44, Gary Gregory wrote:
>> > On Tue, Sep 6, 2011 at 9:48 AM, sebb wrote:
>> >
>> >> On 6 September 2011 13:46, wrote:
>> >> > Author: ggregory
>> >> > Date: Tue Sep 6 12:
On Tue, Sep 6, 2011 at 11:14 AM, sebb wrote:
> On 6 September 2011 15:44, Gary Gregory wrote:
> > On Tue, Sep 6, 2011 at 9:48 AM, sebb wrote:
> >
> >> On 6 September 2011 13:46, wrote:
> >> > Author: ggregory
> >> > Date: Tue Sep 6 12:46:39 2011
> >> > New Revision: 1165645
> >> >
> >> > URL
I am an idiot and I don't have to commit while watching TV :)
Thanks for notifying, going to fix it now!
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Sep 6, 2011 at 6:01 PM, Matt Benson wrote:
> @since 3.0? Should this be 2.0? :) Same for previo
@since 3.0? Should this be 2.0? :) Same for previous commit to this...
Matt
On Mon, Sep 5, 2011 at 2:07 PM, wrote:
> Author: simonetripodi
> Date: Mon Sep 5 19:07:51 2011
> New Revision: 1165395
>
> URL: http://svn.apache.org/viewvc?rev=1165395&view=rev
> Log:
> added missing @since tag in
2011/9/6 Phil Steitz :
> On 9/6/11 12:00 AM, Mikkel Meyer Andersen wrote:
>> 2011/9/5 Phil Steitz :
>>> I have a couple of proposals for this class:
>>>
>>> 0) Merge the interface and impl. This is consistent with what we
>>> are doing in some other places where we have only one implementation.
>
I doubt there is a policy, but practically speaking it helps a lot if JIRA's
don't live forever. They should express an issue and that should get fixed
and the JIRA closed. The scope of work shouldn't be extended to cover
additional work.
Tasks under blanket JIRA's might help.
2011/9/6 Sébastie
On 6 September 2011 15:44, Gary Gregory wrote:
> On Tue, Sep 6, 2011 at 9:48 AM, sebb wrote:
>
>> On 6 September 2011 13:46, wrote:
>> > Author: ggregory
>> > Date: Tue Sep 6 12:46:39 2011
>> > New Revision: 1165645
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
>> > Log:
>>
On Tue, Sep 6, 2011 at 9:48 AM, sebb wrote:
> On 6 September 2011 13:46, wrote:
> > Author: ggregory
> > Date: Tue Sep 6 12:46:39 2011
> > New Revision: 1165645
> >
> > URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
> > Log:
> > Changes for [parent] 22-SNAPSHOT.
> >
> > Modified:
> >
I'm working on a fix now. Have a look when it is committed to see if
it can be improved.
On 6 September 2011 15:48, Paul Benedict wrote:
> Make the sun class be loaded dynamically -- not statically -- and if
> it is not present, just throw an UnsupportedOperationException? I
> think that would so
As a user of chain in a number of projects over the years, I've found
that the combination of extending Map and defining your own getter /
setter properties on the context to be ideal. With your own getters
and setters, you get better code completion and you have a more
old-fashioned entity object.
Make the sun class be loaded dynamically -- not statically -- and if
it is not present, just throw an UnsupportedOperationException? I
think that would solve Android's problem.
On Tue, Sep 6, 2011 at 8:36 AM, sebb wrote:
> On 6 September 2011 05:44, David Karlsen wrote:
>> I think tying to sun c
I added the file ComplexOctaveTest.java to JIRA MATH-620.
What really will happen, if Inf and NaN values com up I dont know at
this point - the complex signal path is in its infancy at the moment ...
(I currently have no need for that)
Arne
--
We use in XStream a dynamic approach:
http://svn.codehaus.org/xstream/trunk/xstream/src/test/com/thoughtworks/xstream/testutil/DynamicSecurityManager.java
http://svn.codehaus.org/xstream/trunk/xstream/src/test/com/thoughtworks/acceptance/SecurityManagerTest.java
sebb wrote:
> On 6 September 2011
On 6 September 2011 13:46, wrote:
> Author: ggregory
> Date: Tue Sep 6 12:46:39 2011
> New Revision: 1165645
>
> URL: http://svn.apache.org/viewvc?rev=1165645&view=rev
> Log:
> Changes for [parent] 22-SNAPSHOT.
>
> Modified:
> commons/proper/lang/trunk/src/test/resources/java.policy
>
> Modif
On 6 September 2011 05:44, David Karlsen wrote:
> I think tying to sun classes is a bad idea.
Yes, which is why the code checks to see if the class is present.
If the Java 6 method is available, then it uses that, otherwise it
checks for the Sun method.
If neither is available, then the code thr
On 9/6/11 12:00 AM, Mikkel Meyer Andersen wrote:
> 2011/9/5 Phil Steitz :
>> I have a couple of proposals for this class:
>>
>> 0) Merge the interface and impl. This is consistent with what we
>> are doing in some other places where we have only one implementation.
> Fine with me.
>> 1) Extend th
Hello.
> as agreed in this ticket, references to double[] solve(double[]) have
> been wiped out from all decomposition solvers.
That's done already but might have been the object of another JIRA ticket,
as the changes did not depend on "RealVector".
> The same thing should probably be done with
Not sure it went through the first time...
Le 6 septembre 2011 08:33, Sébastien Brisard
a écrit :
> Hi,
> as agreed in this ticket, references to double[] solve(double[]) have
> been wiped out from all decomposition solvers.
> The same thing should probably be done with solve(double[][]), but
> G
On Sep 5, 2011, at 23:34, Henri Yandell wrote:
> On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
>> On 3 September 2011 05:37, Henri Yandell wrote:
>>> I'm less concerned with the 115 errors, unless they're all as grievous
>>> as the StringUtils one - ie) the method causing trouble is not the
>>> o
On Sep 5, 2011, at 23:35, sebb wrote:
> On 6 September 2011 04:26, Gary Gregory wrote:
>> Can the clirr version be inherited from the parent pom?
>
> Tried that just now.
>
> Has to be defined in reporting section.
>
> That works fine, except it does not appear to be possible to suppress
> the r
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
Hi Niall,
thanks for the hint!
Anyway (DISCLAIMER: I'm putting in the original chain author's shoes,
so I couldn't say the truth) I immagine that users would be interested
on having, as a Context, not just a place where storing computed
element to be shared between chain commands, but having also
>As shown in this exemple the exception is really something local to
user code and there is a guarantee [math] will not mess with it. The
user >is safe.
>
>I would like to finish implementing this for ODE (i.e. simply commit
what I have already done), and to extend it to the rest of [math],
>>>comp
2011/9/5 Phil Steitz :
> I have a couple of proposals for this class:
>
> 0) Merge the interface and impl. This is consistent with what we
> are doing in some other places where we have only one implementation.
Fine with me.
> 1) Extend this class to actually provide a distribution - i.e.
> imple
43 matches
Mail list logo
