Hi all,
The provided patch for MATH-599 includes a number of no-brace if
statements like the following ones:
+if (method == Method.ILLINOIS) f0 *= 0.5;
+if (method == Method.PEGASUS) f0 *= f1 / (f1 + fx);
I'm not sure if we have an unwritten rule for this, bu
I agree with you that braces should always be used. Personally, I do have
one exception though, and that is if the statement following it is on the
same line. That way, it is one line, instead of 3 lines, which makes it
more readable. If the 'if' statement spans multiple lines, I always include
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-math has an issue affecting its community integration.
This issue
Le 24/06/2011 09:09, Dennis Hendriks a écrit :
I agree with you that braces should always be used. Personally, I do
have one exception though, and that is if the statement following it is
on the same line. That way, it is one line, instead of 3 lines, which
makes it more readable. If the 'if' sta
Hi.
> >I agree with you that braces should always be used. Personally, I do
> >have one exception though, and that is if the statement following it is
> >on the same line. That way, it is one line, instead of 3 lines, which
> >makes it more readable. If the 'if' statement spans multiple lines, I
>
> No, we tend to fix really everything, at least at release time.
I got this output this morning for trunk:
[INFO] There are 22792 checkstyle errors.
So there is a lot of work to do for the next release...
> If we
> let warnings, it becomes difficult to sort real problems from false
> positive
> I prefer to have _one_ rule for code formatting.
> [Also, you nvere know when you might need an additional statement wihtin
> the conditional branch (e.g. when debugging).]
I would indeed consider that a reasonable reason to indeed force the braces.
Dennis
Gilles Sadowski wrote:
Hi.
I agr
Le 24/06/2011 10:57, Dennis Hendriks a écrit :
> No, we tend to fix really everything, at least at release time.
I got this output this morning for trunk:
[INFO] There are 22792 checkstyle errors.
I have 137 errors only adding the check for braces, and only a handful
without this check!
D
> + * {@link org.apache.commons.math.odeODEIntegrator ODE solvers}, it
Seems to be missing a dot between ode and ODEIntegrator...
Dennis
er...@apache.org wrote:
Author: erans
Date: Fri Jun 24 09:43:33 2011
New Revision: 1139223
URL: http://svn.apache.org/viewvc?rev=1139223&view=rev
Log:
Jav
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=9296&projectId=97
Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 24 Jun 2011 10:20:33 +
Finished at: Fri 24 Jun 2011 10:21:05 +
Total time: 31s
Build Trigger: Schedule
Buil
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
+1
2011/6/24 Luc Maisonobe :
> Hi all,
>
> The provided patch for MATH-599 includes a number of no-brace if statements
> like the following ones:
>
>> + if (method == Method.ILLINOIS) f0 *= 0.5;
>> + if (method == Method.PEGASUS) f0 *= f1 / (f1 + fx);
>
> I'm not sure
Hello All,
I have been a user of the math commons jar for a little over a year and am
very impressed with it. I was wondering whether anyone is actively working
on implementing functionality to do regressions on very very large data
sets. The current implementation of the OLS routine is an in-core
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-math has an issue affecting its community integration.
This issue
On 6/24/11 11:44 AM, Greg Sterijevski wrote:
> Hello All,
>
> I have been a user of the math commons jar for a little over a year and am
> very impressed with it. I was wondering whether anyone is actively working
> on implementing functionality to do regressions on very very large data
> sets. The
Mahout has this.
We have an LSMR implementation that can accept a generic linear operator.
You can implement this linear operator as an out of core multiplication or
as a cluster operation.
You don't say how large you want the system to be or whether you have sparse
data. That might change the
Hi,
I've submitted an issue:
https://issues.apache.org/jira/browse/CODEC-125
I have BMPM implemented now, with good (but not complete) test coverage.
It's certainly ready for someone else to try to break it for me. So,
1. The original authors are very keen to see this integrated with
commons-co
Hi Ted,
I will look at the Mahout library. I was not aware of this. I will see if
this is amenable to my problems.
A large problem would be one where it does not make sense to pull all the
data into core, whether its 10Gb or 100Tb. While some of these design
matrices might be sparse, there is no
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-math has an issue affecting its community integration.
This issue
19 matches
Mail list logo
