Any objections to fixing this?
On Wed, Sep 21, 2011 at 8:27 PM, Phil Steitz wrote:
> On 9/21/11 6:11 PM, Greg Sterijevski wrote:
> > One more question, there is a boolean argument called 'abort', what sense
> > does it make to keep checking an array given you have found one
> observation
> > whi
On 9/21/11 6:11 PM, Greg Sterijevski wrote:
> One more question, there is a boolean argument called 'abort', what sense
> does it make to keep checking an array given you have found one observation
> which violates monotonicity? I think abort is redundant and could be
> eliminated. Thoughts?
Looks
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=12413&projectId=98
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 22 Sep 2011 01:20:16 +
Finished at: Thu 22 Sep 2011 01:23:42 +
Total time: 3m 25s
Build Trigger: Schedule
One more question, there is a boolean argument called 'abort', what sense
does it make to keep checking an array given you have found one observation
which violates monotonicity? I think abort is redundant and could be
eliminated. Thoughts?
On Wed, Sep 21, 2011 at 7:41 PM, Phil Steitz wrote:
> O
If there are no objections, I will move the body of the current
checkOrder(double[] arg, ...) into a isMonotone method. I will also create a
parallel set of checkOrder, isMonotone functions for Comparable[] arrays.
-Greg
On Wed, Sep 21, 2011 at 7:41 PM, Phil Steitz wrote:
> On 9/21/11 4:33 PM,
On 9/21/11 4:33 PM, Greg Sterijevski wrote:
> Gilles,
>
> I do not understand why a non-monotone collection should throw a
> IllegalArgumentException...? There is nothing wrong with the argument, it
> just is not in corrected order. Wouldn't it be better to return a false?
I think as you guys are
Gilles,
I do not understand why a non-monotone collection should throw a
IllegalArgumentException...? There is nothing wrong with the argument, it
just is not in corrected order. Wouldn't it be better to return a false?
We have:
if (!ok && abort) {
throw new NonMonoto
The reason I am looking at checkOrder is your suggestion for
UpdatingMultipleLinearRegression, eg checking if the variables are presented
in monotonically increasing order...
On Wed, Sep 21, 2011 at 5:56 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> On Wed, Sep 21, 2011 at 05:17:59
I would not want to remove the current implementation (the one with double[]
as an arg). However, I might want to check lists to make sure that they are
monotonically increasing. I want to avoid writing a checkOrder method for
int[], long[], float[],..., if it is possible. Also, one should be able
On Wed, Sep 21, 2011 at 05:17:59PM -0500, Greg Sterijevski wrote:
> Meant to say add, not replace. My apologies. -Greg
I like this better! ;-)
[But, still, please check the intended meaning of the first argument of
(sub-classes of) "MathIllegalArgumentException".]
Gilles
Hi.
>
> In MathUtils there exists the method:
>
> public static boolean checkOrder(double[] val, OrderDirection dir,
> boolean strict, boolean abort) {
> ...code omitted...
> }
>
>
> I would like to replace it with the method:
>
> public static boo
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=12409&projectId=98
Build statistics:
State: Failed
Previous State: Failed
Started at: Wed 21 Sep 2011 22:20:17 +
Finished at: Wed 21 Sep 2011 22:23:45 +
Total time: 3m 27s
Build Trigger: Schedule
Meant to say add, not replace. My apologies. -Greg
On Wed, Sep 21, 2011 at 5:05 PM, Greg Sterijevski wrote:
> Hello All,
>
> In MathUtils there exists the method:
>
> public static boolean checkOrder(double[] val, OrderDirection dir,
> boolean strict, bool
Hello All,
In MathUtils there exists the method:
public static boolean checkOrder(double[] val, OrderDirection dir,
boolean strict, boolean abort) {
...code omitted...
}
I would like to replace it with the method:
public static boolean checkOrder(Co
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=12403&projectId=69
Build statistics:
State: Failed
Previous State: Failed
Started at: Wed 21 Sep 2011 20:20:51 +
Finished at: Wed 21 Sep 2011 20:21:09 +
Total time: 17s
Build Trigger: Schedule
Bui
Done in r1173788.
Sébastien
2011/9/21 Phil Steitz :
> On 9/21/11 5:23 AM, sebb wrote:
>> Why not just add some text to the tag to explain what has happened?
>>
>> Something like:
>>
>> @since 2.0 (changed to concrete class in 3.0)
>
> +1
>
> Phil
>>
>> 2011/9/21 Sébastien Brisard :
>>> Maybe that
On 9/21/11 5:23 AM, sebb wrote:
> Why not just add some text to the tag to explain what has happened?
>
> Something like:
>
> @since 2.0 (changed to concrete class in 3.0)
+1
Phil
>
> 2011/9/21 Sébastien Brisard :
>> Maybe that tag should be removed (drastic... but no possible confusion!).
>> Séb
On Wed, Sep 21, 2011 at 10:55 AM, sebb wrote:
> Project reports are now generated in random order.
> This started with site plugin version 2.3; CP 21 used site plugin 2.2
> so did not show the problem behaviour.
>
> Order of reports in M2 apparently comes from Maven core:
> http://jira.codehaus.o
Project reports are now generated in random order.
This started with site plugin version 2.3; CP 21 used site plugin 2.2
so did not show the problem behaviour.
Order of reports in M2 apparently comes from Maven core:
http://jira.codehaus.org/browse/MNG-5140
Apparently will be fixed in Maven 2.2.2.
Yes, that would be clear enough.
Sébastien
2011/9/21 sebb :
> Why not just add some text to the tag to explain what has happened?
>
> Something like:
>
> @since 2.0 (changed to concrete class in 3.0)
>
> 2011/9/21 Sébastien Brisard :
>> Maybe that tag should be removed (drastic... but no possible
Why not just add some text to the tag to explain what has happened?
Something like:
@since 2.0 (changed to concrete class in 3.0)
2011/9/21 Sébastien Brisard :
> Maybe that tag should be removed (drastic... but no possible confusion!).
> Sébastien
>
> 2011/9/21 Gilles Sadowski :
>> On Wed, Sep 2
Maybe that tag should be removed (drastic... but no possible confusion!).
Sébastien
2011/9/21 Gilles Sadowski :
> On Wed, Sep 21, 2011 at 06:25:13AM +0200, Sébastien Brisard wrote:
>> Hi,
>> I'm currently working on MATH-662. So far, I have merged
>> CholeskyDecomposition and CholeskyDecomposition
On Wed, Sep 21, 2011 at 06:25:13AM +0200, Sébastien Brisard wrote:
> Hi,
> I'm currently working on MATH-662. So far, I have merged
> CholeskyDecomposition and CholeskyDecompositionImpl. My question is
> very simple: CholeskyDecomposition exists as an interface since
> version 2.0 (as indicated in
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
Commons Parent 22 is now in Maven Central.
Components that upgrade to this release should note the following:
Starting with version 22, the RAT plugin has changed Maven group and
id, so any existing configuration needs to be updated.
To fix component POMs, please change any occurrences of:
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-functor has an issue affecting its community integration.
This iss
Phil Steitz wrote:
>When GKOP or GOP pools lack capacity, addObject does nothing. In
>some cases (I am dealing with one now internally to GKOP), it would
>be good to know if an instance was actually added or not. How about
>changing the interface (both OP and KOP versions) to return a
>boolean
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-discovery has an issue affecting its community integration.
This i
28 matches
Mail list logo
