As soon as you push the other changes, I will update my source and get to
work on this...
I thought SimpleRegression was a toy example, but after thinking about it,
there is much to like about the class.
-Greg
On Sat, Aug 13, 2011 at 1:16 AM, Phil Steitz wrote:
> On 8/12/11 10:59 PM, Greg Steri
On 8/12/11 10:59 PM, Greg Sterijevski wrote:
> Also, I was thinking that maybe it might be useful to bring SimpleRegression
> into line with the other regression techniques and give the user the ability
> to constrain the constant to zero?
+1 - just make sure to include clear javadoc and tests.
P
On 8/12/11 10:13 PM, Greg Sterijevski wrote:
> One more thing... (ala Detective Colombo).
>
> In add and remove observation there is a snippet which looks like:
>
> sumXX += dx * dx * (double) n / (n + 1d);
> sumYY += dy * dy * (double) n / (n + 1d);
> sumXY += d
Also, I was thinking that maybe it might be useful to bring SimpleRegression
into line with the other regression techniques and give the user the ability
to constrain the constant to zero?
-Greg
On Sat, Aug 13, 2011 at 12:13 AM, Greg Sterijevski
wrote:
> One more thing... (ala Detective Colombo)
One more thing... (ala Detective Colombo).
In add and remove observation there is a snippet which looks like:
sumXX += dx * dx * (double) n / (n + 1d);
sumYY += dy * dy * (double) n / (n + 1d);
sumXY += dx * dy * (double) n / (n + 1d);
xbar += dx /
+1 from me, on all counts! -Greg
On Fri, Aug 12, 2011 at 11:30 PM, Phil Steitz wrote:
> On 8/12/11 7:16 PM, Greg Sterijevski wrote:
> > Hello All,
> >
> > Before I chum the water with more JIRA tickets, I thought I would see
> > whether people thought this was important.
> >
> > In the SimpleReg
On 8/12/11 7:16 PM, Greg Sterijevski wrote:
> Hello All,
>
> Before I chum the water with more JIRA tickets, I thought I would see
> whether people thought this was important.
>
> In the SimpleRegression you have two methods:
>
> public void addData(double x, double y) {
> ...some code that is no
On 2011-08-13, sebb wrote:
> 1. Accept BSF as a Commons Component
+1
> 2. Offer Commons karma to BSF developers.
> The ones who made commits since the start of 2008 and are not already
> in Commons are:
> 2a) Rony G. Flatscher (rony)
> 2b) Ant Elder (antelder)
+1
Stefan
+1.
On Fri, Aug 12, 2011 at 5:28 PM, Matt Benson wrote:
> +1 for both sub-votes.
>
> Matt
>
> On Fri, Aug 12, 2011 at 7:13 PM, sebb wrote:
>> BSF [1] needs to move out of Jakarta.
>>
>> It's not really big enough to warrant its own TLP.
>>
>> IMO Commons would be a good alternative home for BSF.
Hello All,
Before I chum the water with more JIRA tickets, I thought I would see
whether people thought this was important.
In the SimpleRegression you have two methods:
public void addData(double x, double y) {
...some code that is not germane to discussion..
if (n > 2) {
+1 for both sub-votes.
Matt
On Fri, Aug 12, 2011 at 7:13 PM, sebb wrote:
> BSF [1] needs to move out of Jakarta.
>
> It's not really big enough to warrant its own TLP.
>
> IMO Commons would be a good alternative home for BSF.
>
> Can we please vote to:
>
> 1. Accept BSF as a Commons Component
>
BSF [1] needs to move out of Jakarta.
It's not really big enough to warrant its own TLP.
IMO Commons would be a good alternative home for BSF.
Can we please vote to:
1. Accept BSF as a Commons Component
2. Offer Commons karma to BSF developers.
The ones who made commits since the start of 200
Hi All:
Where are we WRT [pool] and generics in a release?
Thank you,
Gary
--
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
-
To unsubscribe, e-m
No
On Aug 12, 2011, at 12:17 PM, Oliver Heger wrote:
> [configuration] still has build files for Maven 1. Any objections if I remove
> them?
>
> Oliver
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For a
On Fri, Aug 12, 2011 at 3:17 PM, Oliver Heger
wrote:
> [configuration] still has build files for Maven 1. Any objections if I
> remove them?
Remove it! :)
Gary
>
> Oliver
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.
Hello All:
For a first cut at generics support in Codec, please checkout the
branch https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics
I wrote a migration guide in the root of the project called
Codec2-Migration.htm.
Let's discuss.
I plan on not touching trunk until the gen
On the [configuration] main site there is a link to old how-to documents
targeting the ancient version 1.2. As nobody is supposed to still work
with this version, I guess it should be okay to remove them. If there
are no objections, I will do this.
Oliver
-
[configuration] still has build files for Maven 1. Any objections if I
remove them?
Oliver
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On Thu, Aug 11, 2011 at 12:33 PM, sebb wrote:
> On 11 August 2011 19:38, Matthew Pocock wrote:
>> Hi,
>>
>> As those of you who've been following the CODEC-125 ticket will know, with
>> Greg's help I've got a port of the beider morse phonetic
>> matching (bmpm) algorithm in as a string encoder. A
On Fri, Aug 12, 2011 at 11:42 AM, sebb wrote:
> On 12 August 2011 16:08, Gary Gregory wrote:
>> On Fri, Aug 12, 2011 at 10:35 AM, sebb wrote:
>>> On 12 August 2011 15:29, Gary Gregory wrote:
On Fri, Aug 12, 2011 at 9:54 AM, sebb wrote:
> On 12 August 2011 14:33, Gary Gregory wrote:
>
On 12 August 2011 16:08, Gary Gregory wrote:
> On Fri, Aug 12, 2011 at 10:35 AM, sebb wrote:
>> On 12 August 2011 15:29, Gary Gregory wrote:
>>> On Fri, Aug 12, 2011 at 9:54 AM, sebb wrote:
On 12 August 2011 14:33, Gary Gregory wrote:
> Can we proceed like so?
>
> - I'll save
Hi Fran,
Le 12/08/2011 16:51, Fran Lattanzio a écrit :
I have a working prototype for real univariate functions that uses
finite differences. The code is very small and simple, but quite
messy. I'll clean it up soon. It's trivial to extend this to
univariate vectorial and matrix functions. I thi
On Fri, Aug 12, 2011 at 10:35 AM, sebb wrote:
> On 12 August 2011 15:29, Gary Gregory wrote:
>> On Fri, Aug 12, 2011 at 9:54 AM, sebb wrote:
>>> On 12 August 2011 14:33, Gary Gregory wrote:
Can we proceed like so?
- I'll save my generified codec in an svn branch ASAP.
- we c
Hi,
I installed an evaluation version of WinZip, created the 5GB and
100k_Files archives I've already created for InfoZIP, 7ZIP, Windows
Compressed Folders and OpenJDK7 jar and the reading tests work just
fine.
All tools I've tried (except for jar) have been able to extract the
archives written d
I have a working prototype for real univariate functions that uses
finite differences. The code is very small and simple, but quite
messy. I'll clean it up soon. It's trivial to extend this to
univariate vectorial and matrix functions. I think it's also worth add
Savitzky-Golay smoothing filters fo
On 12 August 2011 15:29, Gary Gregory wrote:
> On Fri, Aug 12, 2011 at 9:54 AM, sebb wrote:
>> On 12 August 2011 14:33, Gary Gregory wrote:
>>> Can we proceed like so?
>>>
>>> - I'll save my generified codec in an svn branch ASAP.
>>> - we can discuss that and get the best design
>>> - is it bin
On Fri, Aug 12, 2011 at 9:54 AM, sebb wrote:
> On 12 August 2011 14:33, Gary Gregory wrote:
>> Can we proceed like so?
>>
>> - I'll save my generified codec in an svn branch ASAP.
>> - we can discuss that and get the best design
>> - is it binary compatible?
>
> Or can it be made binary-compatibl
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11215&projectId=74
Build statistics:
State: Failed
Previous State: Ok
Started at: Fri 12 Aug 2011 14:21:28 +
Finished at: Fri 12 Aug 2011 14:21:44 +
Total time: 15s
Build Trigger: Schedule
Build N
On 12 August 2011 14:54, sebb wrote:
>> We have lang3 and digester3 under our belts now with new packages. Are
>> we going to change policy again? I hope not. We sure spent a lot of
>> time on this and thought we made a sane decision as a community.
>> Joda-time is its own world can do what it wan
On 12 August 2011 14:33, Gary Gregory wrote:
> Can we proceed like so?
>
> - I'll save my generified codec in an svn branch ASAP.
> - we can discuss that and get the best design
> - is it binary compatible?
Or can it be made binary-compatible without excessive compromises?
> - if not, which is m
Thanks! There is an additional method I am moving in. Its the inverse of the
condition number.
public double getInverseConditionNumber() {
return singularValues[FastMath.min(m,n) - 1] / singularValues[0];
}
This addition stems from an issue (MATH-602) I submitted awhile back.
Name
Can we proceed like so?
- I'll save my generified codec in an svn branch ASAP.
- we can discuss that and get the best design
- is it binary compatible?
- if not, which is my current view, then package is codec2
We have lang3 and digester3 under our belts now with new packages. Are
we going to cha
On Thu, Aug 11, 2011 at 04:31:15PM -0500, Greg Sterijevski wrote:
> At least three with some code I checked in last night. The point is that
> there is no reason to replicate the same thing over and over again.
I understand the point.
I've replaced those 2 occurrences which I detected (revision 11
On 08/12/2011 02:47 PM, Mark Thomas wrote:
On 12/08/2011 13:23, Mladen Turk wrote:
The Apache Commons Daemon team is pleased to announce the
commons-daemon-1.0.7 release!
Version 1.0.7 is bug fix release fixing the
CVE-2011-2729 security issue.
Source and binary distributions are available for
On 12/08/2011 13:23, Mladen Turk wrote:
> The Apache Commons Daemon team is pleased to announce the
> commons-daemon-1.0.7 release!
> Version 1.0.7 is bug fix release fixing the
> CVE-2011-2729 security issue.
>
> Source and binary distributions are available for download
> from the Apache Commons
The Apache Commons Daemon team is pleased to announce the
commons-daemon-1.0.7 release!
Version 1.0.7 is bug fix release fixing the
CVE-2011-2729 security issue.
Source and binary distributions are available for download
from the Apache Commons download site:
http://commons.apache.org/daemon/dow
Thanks for the information Luc. I didn't know those existed. I'm happy
to keep the discussion at the implementation levels.
On 8/12/2011 6:23 AM, Luc Maisonobe wrote:
Le 12/08/2011 00:30, Patrick Meyer a écrit :
I like the idea of adding this feature. What about an abstract class
that implemen
Hi Luc,
>
> I don't fully agree with this. Both numerical and analytical approach are
> useful and have advantages and drawbacks.
>
Wowww!
I certainly did not want to start a debate on this topic. I'm just
reporting on a conference I heard which lead me think that CM users
might find such a featur
On 2011-08-12, sebb wrote:
> On 12 August 2011 10:00, Stefan Bodewig wrote:
>> We basically have two options:
>> * forking the required classes of "XZ in Java" into Compress (Lasse
>> already has a CLA on file and I'm sure we could arrange for the two
>> code bases to stay in sync)
>> * add
Hi Sébastien,
Le 12/08/2011 07:50, Sébastien Brisard a écrit :
As Patrick suggested, this approach should really be extended to
multivariate functions. To cite but one example, I recently attended a
conf where Pr. Prevost (Princeton) talked about non-linear finite
elements calcs. The long standi
>> Shading a binary dependency could provide some middle ground.
>
> Just curious - what is the advantage of shading the jar?
It becomes again just one jar with no dependencies ...almost as if we
forked the code.
cheers,
Torsten
---
On 12 August 2011 11:19, sebb wrote:
>> - Removing deprecated methods does not require a package name change
>
> How so?
>
> If there are any external references to them in an application that
> cannot be removed, then both old and new jars will need to be
> deployed.
> Which cannot be done safely
Hi Bruce,
Le 12/08/2011 00:47, Bruce A Johnson a écrit :
I'd be quite interested in seeing Numerical Derivatives in CM. There are some
interesting ideas about Numerical Differentiation here:
http://www.holoborodko.com/pavel/numerical-methods/
Thanks for the link.
Do you think we should have
On 12 August 2011 10:00, Stefan Bodewig wrote:
> Hi,
>
> .xz is to LZMA what .gz is to the DEFLATE compression algorithm, and it
> starts to get used by quite a few tools/systems in the Unix/Linux
> world. For example more recent GNU tar versions use -J to support the
> format (like -z for gzip a
Le 12/08/2011 00:30, Patrick Meyer a écrit :
I like the idea of adding this feature. What about an abstract class
that implements DifferentiableMultivariateRealFunction and provides the
method for partialDerivative (). People could then override the
partialDerivative method if they have an analyt
On 12 August 2011 08:14, Emmanuel Bourg wrote:
> IMHO unless the main package name has to change due to binary
> incompatibilities in the new version I would stick to the original
> groupId/artifactId (ie org.apache.jcs/jcs).
+1, otherwise users will be forced to edit and recompile - such
changes
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
This is codec moving to the codec2 package.
I'll do the "usual" dance of adding a project defintion for the
CODEC_1_X branch and redirecting all current dependencies there together
with updating the project definition for codec's trunk.
Stefan
On 12 August 2011 08:37, Stephen Colebourne wrote:
> I've just noticed this thread.
>
> I'd like to ask those involved to consider if they can find a route
> where the package name and group do *not* change.
>
> - Changing to JDK 5 does not require a a package name change (generics
> are backward
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-configuration has an issue affecting its community integration.
Th
On 2011-08-12, Lasse Collin wrote:
> On 2011-08-12 Stefan Bodewig wrote:
>> the GNU core utils come with an xz command
> Minor correction: GNU coreutils doesn't include compression tools.
> GNU gzip is its own package and so are bzip2 (bzip.org) and xz
> (tukaani.org).
Thank you.
Stefan
-
On 2011-08-12 Stefan Bodewig wrote:
> the GNU core utils come with an xz command
Minor correction: GNU coreutils doesn't include compression tools.
GNU gzip is its own package and so are bzip2 (bzip.org) and xz
(tukaani.org).
--
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
-
> We basically have two options:
>
> * forking the required classes of "XZ in Java" into Compress (Lasse
> already has a CLA on file and I'm sure we could arrange for the two
> code bases to stay in sync)
>
> * add a (optional) binary dependency on "XZ in Java". Currently the
> package is not a
Hi,
.xz is to LZMA what .gz is to the DEFLATE compression algorithm, and it
starts to get used by quite a few tools/systems in the Unix/Linux
world. For example more recent GNU tar versions use -J to support the
format (like -z for gzip and -j for bzip2), the GNU core utils come
with an xz comman
Stefan Bodewig wrote:
> On 2011-08-12, Emmanuel Bourg wrote:
>
>> IMHO unless the main package name has to change due to binary
>> incompatibilities in the new version I would stick to the original
>> groupId/artifactId (ie org.apache.jcs/jcs).
>
> I agree with you. But if jcs changes the artif
I've just noticed this thread.
I'd like to ask those involved to consider if they can find a route
where the package name and group do *not* change.
- Changing to JDK 5 does not require a a package name change (generics
are backward compatible if the erased signatures don't change).
- Removing de
Emmanuel Bourg wrote:
> IMHO unless the main package name has to change due to binary
> incompatibilities in the new version I would stick to the original
> groupId/artifactId (ie org.apache.jcs/jcs).
+1
otherwise Stefan is right and we can adjust the groupId also.
- Jörg
On 2011-08-12, Emmanuel Bourg wrote:
> IMHO unless the main package name has to change due to binary
> incompatibilities in the new version I would stick to the original
> groupId/artifactId (ie org.apache.jcs/jcs).
I agree with you. But if jcs changes the artifactId (which has happened
in trunk
IMHO unless the main package name has to change due to binary
incompatibilities in the new version I would stick to the original
groupId/artifactId (ie org.apache.jcs/jcs).
Emmanuel Bourg
Le 12/08/2011 08:41, Stefan Bodewig a écrit :
Hi,
while looking through the Gump setup for JCS I realiz
59 matches
Mail list logo
