[MATH] Density functions for all continuous distributions gives rise to re-consider the HasDensity-interface

Dear Community. I've just been going through all the continuous distributions in the MATH-library to check which implemented the HasDensity-interface. Only the F-distribution, t-distribution, Weibull distribution, and Cauchy distribution didn't implement it, and with MATH-330 (https://issues.apac

Re: [MATH] Density functions for all continuous distributions gives rise to re-consider the HasDensity-interface

a lot of sense.  If necessary, something like > AbstractContinuousDistribution could implement a default that throws > UnimplementedOperationException. > > On Fri, Jan 22, 2010 at 11:20 AM, Mikkel Meyer Andersen wrote: > >> This means that now every continuous distribution impleme

Re: [MATH] Density functions for all continuous distributions gives rise to re-consider the HasDensity-interface

I haven't added to the ContinuousDistribution-interface. I've only added to the AbstractContinuousDistribution-class. The relevant patch that I committed is https://issues.apache.org/jira/browse/MATH-332, so no compatibility break should occur. 2010/1/24 Phil Steitz : > Mikkel M

Re: svn commit: r904231 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/linear/AbstractRealVector.java site/xdoc/changes.xml test/java/org/apache/commons/math/linear/ArrayReal

Hi. Thanks! Why use an iterator instead of just a simple for-loop? And what about saving the values until the vector invalidates - I see pros and cons for both approaches, so it's more to hear what your thoughts were? Cheers, Mikkel. On 28/01/2010 8:42 PM, wrote: Author: luc Date: Thu Jan 28

Re: svn commit: r904231 - in /commons/proper/math/trunk/src:main/java/org/apache/commons/math/linear/AbstractRealVector.javasite/xdoc/changes.xml test/java/org/apache/commons/math/linear/ArrayRealVec

: svn commit: r904231 - in >> /commons/proper/math/trunk/src:main/java/org/apache/commons/math/linear/AbstractRealVector.javasite/xdoc/changes.xml >> test/java/org/apache/commons/math/linear/ArrayRealVectorTest.java >> >>> Mikkel Meyer Andersen a écrit : >>>&g

Re: svn commit: r904231 - in /commons/proper/math/trunk/src:main/java/org/apache/commons/math/linear/AbstractRealVector.javasite/xdoc/changes.xml test/java/org/apache/commons/math/linear/ArrayRealVec

2010/1/29 Luc Maisonobe : > Mikkel Meyer Andersen a écrit : >> 2010/1/29 Luc Maisonobe : >>> Bill Barker a écrit : >>>> >>>> -- >>>> From: "Luc Maisonobe" >>>>

Re: svn commit: r904231 - in /commons/proper/math/trunk/src:main/java/org/apache/commons/math/linear/AbstractRealVector.javasite/xdoc/changes.xml test/java/org/apache/commons/math/linear/ArrayRealVec

gt;>>> /commons/proper/math/trunk/src:main/java/org/apache/commons/math/linear/AbstractRealVector.javasite/xdoc/changes.xml >>>> >>>> test/java/org/apache/commons/math/linear/ArrayRealVectorTest.java >>>> >>>>> Mikkel Meyer Andersen a écrit :

Distributions: support

Dear Community, I'm planning to implement lower and upper bounds of the support for distributions in a generic way on AbstractContinuousDistribution and AbstractIntegerDistribution such that one can get e.g. 0 and n for the Binomial, -inf and inf of the Normal etc.? Proposed names for the methods

Re: Distributions: support

2010/7/11 Phil Steitz : > Mikkel Meyer Andersen wrote: >> Dear Community, >> >> I'm planning to implement lower and upper bounds of the support for >> distributions in a generic way on AbstractContinuousDistribution and >> AbstractIntegerDistribution such

Re: [math] speeding up percentile based statistics

Hi, Just a small pedantry correction: Luc, you wrote: > The evaluation that is only an approximation is the on-line algorithm, > because it does not keep all values in memory. However, even when > everything is in memory one should be aware that the result of the > computation is the sample quant

Re: [math] new pseudo random number generators

Hi, I think it sounds interesting. A few comments: 1) Does it support paralleled generation? 2) In regards to the user, which should be the default for e.g. sampling from probability distributions? 3) How is the performance compared to the existing algorithms in Commons Math? Cheers, Mikkel. 20

Re: [math] new pseudo random number generators

Hi, 2010/9/20 : > > - "Mikkel Meyer Andersen" a écrit : > >> Hi, >> >> I think it sounds interesting. >> >> A few comments: >> 1) Does it support paralleled generation? > > No, it updates its bits pool using an iterative formula.

Re: [math] new pseudo random number generators

Thanks for the test. I give a +1 fir this (with the already mentioned "but"'s like documentation etc.). Inclusion would also make it easier for others to test it a bit. 2010/9/21 Luc Maisonobe : > Le 20/09/2010 15:28, Mikkel Meyer Andersen a écrit : > >> I would l

Re: [math] new pseudo random number generators

> Here is an extract from the answer from Pierre L'Ecuyer: > >  Our code can be released under either a GPL or a commercial license. Well, what about the Apache License then? >  There is also a Java implementation with multiple streams and >  substreams in SSJ: see the package rng: >  http://www.i

Re: [math] new pseudo random number generators

2010/9/21 Luc Maisonobe : > Le 21/09/2010 09:26, Mikkel Meyer Andersen a écrit : >>> Here is an extract from the answer from Pierre L'Ecuyer: >>> >>>  Our code can be released under either a GPL or a commercial license. >> Well, what about the Apache Lic

Re: [math] new pseudo random number generators

2010/9/21 Luc Maisonobe : > Le 21/09/2010 10:08, Mikkel Meyer Andersen a écrit : >> 2010/9/21 Luc Maisonobe : >>> Le 21/09/2010 09:26, Mikkel Meyer Andersen a écrit : >>>>> Here is an extract from the answer from Pierre L'Ecuyer: >>>>> &g

[MATH] Updated: (MATH-384) DescriptiveStatistics based on double[]

Hi, I've finally made a patch proposal for MATH-384 ( https://issues.apache.org/jira/browse/MATH-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ) . Sorry for the delay. What do you think? Cheers, Mikkel. -- Forwarded message -- From: Mikkel Meyer And

[MATH] Updated: (MATH-385) Characteristic (support, mean, variance, ...) on Distributions

he logic before creating the testing functions. In addition, it would be very appreciated if anybody had proposals to which tests to make. Cheers, Mikkel. -- Forwarded message ------ From: Mikkel Meyer Andersen (JIRA) Date: 2010/9/22 Subject: [jira] Updated: (MATH-385) Characteristic

Re: [MATH] Updated: (MATH-384) DescriptiveStatistics based on double[]

No worries - it's not like I've been overly quick myself, so no need to stress; it's not that crucial :-). Cheers, Mikkel. 2010/9/23 Phil Steitz : > On 9/23/10 4:36 AM, Mikkel Meyer Andersen wrote: >> >> Hi, >> >> I've finally made a patch proposal

Re: [math] speeding up percentile based statistics

Hi, Why not simply make 3) the default, but also supply a *IMSureWhatIMDoing-method only implementing 2) (it is so cheap that we might as well do it instead of not doing any check at all). This means that users who read the documentation can gain something when they explicitly ask for it, while us

Re: [math] speeding up percentile based statistics

alues = values; > originalHash = hash; > copiedValues = values.clone(); > } > } > > Starting to work on it ... > > Luc > >> >> I would tend toward the copy option. >> >> On Sun, Sep 26, 2010 at 8:39 AM, Mikkel Meyer Andersen wrote: >> >>

Re: [math] speeding up percentile based statistics

2010/9/26 Gilles Sadowski : >> [...] >> >>  1) do nothing to check the array is the same between calls and blindly >>     assumes it IS the same. Users would really need to call clearCache >>     when they provide a new array >>     pros: very simple >>     cons: error-prone for the user as it reli

Re: [math] Problem with immutable distribution

Hi, Just to be sure: You propose to remove public void setDistribution(TDistribution value) Is this correct? If so, another proposal - I'm not sure it's a clever one - is ---CUT---    public TDistribution setDistribution(TDistribution value) { double n = value.getDegreesOfFreedom();

Re: [math] Problem with immutable distribution

Hi, 2010/9/29 Gilles Sadowski : >> Just to be sure: You propose to remove >> public void setDistribution(TDistribution value) >> Is this correct? > > Yes. > >> If so, another proposal - I'm not sure it's a clever one - is >> >> ---CUT--- >>     public TDistribution setDistribution(TDistribution va

Re: [math] Problem with immutable distribution

Hi, 2010/9/29 Gilles Sadowski : >> >> Just to be sure: You propose to remove >> >> public void setDistribution(TDistribution value) >> >> Is this correct? >> > >> > Yes. >> > >> >> If so, another proposal - I'm not sure it's a clever one - is >> >> >> >> ---CUT--- >> >>     public TDistribution se

Re: [Math] Factorial

Agree, we should be consistent with the JLS, so throwing exceptions in case of overflow isn't the right thing to do. Den 02/11/2010 22.06 skrev "Ted Dunning" :

Re: Komogorov distribution WASF Re: [jira] Commented: (MATH-431) New tests: Wilcoxon signed-rank test and Mann-Whitney U

mate alternative.  I will take a close look this evening, but it >>>>>> looks >>>>>> like the algorithm you are using should be exact.  If we can't >>>>>> reconcile the >>>>>> difference with R, it would be good to find a way to

Re: Komogorov distribution WASF Re: [jira] Commented: (MATH-431) New tests: Wilcoxon signed-rank test and Mann-Whitney U

2010/11/7 Phil Steitz : > On 11/7/10 10:10 AM, Mikkel Meyer Andersen wrote: >> >> 2010/11/7 Phil Steitz: >>> >>> Switching to the right list... >>> >>> - >>>>>> >>>>>> What we need there is a good algorithm for

Re: svn commit: r1034564 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/FunctionEvaluationException.java site/xdoc/changes.xml test/java/org/apache/commons/math/FunctionEvaluat

Thanks a lot for all this cleaning up. It's really appreciated! Den 12/11/2010 22.04 skrev : > Author: erans > Date: Fri Nov 12 21:03:38 2010 > New Revision: 1034564 > > URL: http://svn.apache.org/viewvc?rev=1034564&view=rev > Log: > MATH-438 > Removed deprecated class. > > Removed: > commons/prope

[MATH] Fwd: [jira] Commented: (MATH-437) Kolmogorov Smirnov Distribution

ass for FieldMatrix and RealMatrix providing multiply-functionality - unfortunately). Cheers, Mikkel. [1]: https://issues.apache.org/jira/browse/MATH-437 -- Forwarded message -- From: Mikkel Meyer Andersen (JIRA) Date: 2010/11/16 Subject: [jira] Commented: (MATH-437) Kolmogo

Re: [MATH] Fwd: [jira] Commented: (MATH-437) Kolmogorov Smirnov Distribution

2010/11/16 : > > - "Mikkel Meyer Andersen" a écrit : > >> Dear developers, > > Hi Mikkel, > >> >> We now have a working implementation of the cdf for the two-sided >> Kolmogorov Smirnov Distribution [1]. What do you think about it? Now >

Re: [math] Getting 2.2 out (or, Santa nous a laissé le charbon, mais peut-être par la Nouvelle Année...)

Hi, After a very busy December, I've actually just started on finishing MATH-384 and MATH-385 today (as you might see, I've assigned them to myself some hours ago). So they should be finished within this week (the small suggested changed and tests). Just to be sure that I do this correctly. Shoul

Re: [math] Getting 2.2 out (or, Santa nous a laissé le charbon, mais peut-être par la Nouvelle Année...)

And should I finish the patches up in https://svn.apache.org/repos/asf/commons/proper/math/trunk accordingly? Or do we deal with syncing 2.2 and 3.0 after releasing 3.0? Cheers, Mikkel. 2010/12/26 Mikkel Meyer Andersen : > Hi, > > After a very busy December, I've actually j

Re: [math] Getting 2.2 out (or, Santa nous a laissé le charbon, mais peut-être par la Nouvelle Année...)

2010/12/26 Phil Steitz : > 2010/12/26 Mikkel Meyer Andersen > >> Hi, >> >> After a very busy December, I've actually just started on finishing >> MATH-384 and MATH-385 today (as you might see, I've assigned them to >> myself some hours ago). So th

Re: [jira] Commented: (MATH-385) Characteristic (support, mean, variance, ...) on Distributions

              Key: MATH-385 >>                 URL: https://issues.apache.org/jira/browse/MATH-385 >>             Project: Commons Math >>          Issue Type: New Feature >>            Reporter: Mikkel Meyer Andersen >>            Assignee: Mikkel Meyer Andersen >&g

Re: [jira] Updated: (MATH-384) DescriptiveStatistics based on double[]

Hi, Now MATH384 should soon be ready to be closed, too. I will commit in 2.2 and trunk when somebody (Phil?) has had the time to review the patch proposals. Cheers, Mikkel. 2010/12/27 Mikkel Meyer Andersen (JIRA) : > >     [ > https://issues.apache.org/jira/browse/MATH

Re: [GUMP@vmgump]: Project commons-math (in module apache-commons) failed

Hi, I'm not sure I understand this. According to http://vmgump.apache.org/gump/public/apache-commons/commons-math/gump_work/build_apache-commons_commons-math.txt it fails at CauchyDistributionTest, FDistributionTest, and TDistributionTest. I have a suspicion that it is my patch for MATH-385, but l

Re: [GUMP@vmgump]: Project commons-math (in module apache-commons) failed

Hi, Thanks. I've purified the tests in 2.2 in revision 1053471 and in 3.0 in revision 1053472. Cheers, Mikkel. 2010/12/28 Phil Steitz : > On Tue, Dec 28, 2010 at 1:06 PM, Phil Steitz wrote: > >> >> >> On Tue, Dec 28, 2010 at 4:11 AM, Mikkel Meyer Andersen wrote: &g

Re: svn commit: r1053836 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/stat/inference/ test/java/org/apache/commons/math/stat/inference/

Hi, This commit consists of new files, so I put @version $Revision: $ $Date: $ in the top. I thought SVN would then auto update these, but after checking out again to see if it worked, I see that it didn't. What should I do to make it work? Fire a svn propXXX, use other variables, or? Cheers, Mik

Re: svn commit: r1053836 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/stat/inference/ test/java/org/apache/commons/math/stat/inference/

2010/12/30 Luc Maisonobe : > Le 30/12/2010 16:18, Luc Maisonobe a écrit : >> Le 30/12/2010 11:00, Mikkel Meyer Andersen a écrit : >>> Hi, >> >> Hi Mikkel, >> >>> >>> This commit consists of new files, so I put >>> @version $Revision:

Re: svn commit: r1053836 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/stat/inference/ test/java/org/apache/commons/math/stat/inference/

2010/12/30 Mikkel Meyer Andersen : > 2010/12/30 Luc Maisonobe : >> Le 30/12/2010 16:18, Luc Maisonobe a écrit : >>> Le 30/12/2010 11:00, Mikkel Meyer Andersen a écrit : >>>> Hi, >>> >>> Hi Mikkel, >>> >>>> >>>> This c

Re: svn commit: r1053836 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/stat/inference/ test/java/org/apache/commons/math/stat/inference/

2010/12/30 Luc Maisonobe : > Le 30/12/2010 16:44, Mikkel Meyer Andersen a écrit : >> 2010/12/30 Luc Maisonobe : >>> Le 30/12/2010 16:18, Luc Maisonobe a écrit : >>>> Le 30/12/2010 11:00, Mikkel Meyer Andersen a écrit : >>>>> Hi, >>>> >

Re: svn commit: r1053920 - /commons/proper/math/trunk/pom.xml

/trunk/pom.xml >> URL: >> http://svn.apache.org/viewvc/commons/proper/math/trunk/pom.xml?rev=1053920&r1=1053919&r2=1053920&view=diff >> >> == >> --- commons/proper/math/trunk/pom.xml (o

Re: svn commit: r1054298 - in /commons/proper/math: branches/MATH_2_X/src/main/java/org/apache/commons/math/distribution/GammaDistributionImpl.java trunk/src/main/java/org/apache/commons/math/distribu

Hi, Phil, thanks for all these corrections and sorry for all the checkstyle mistakes. I'll see to that it doesn't happen again. I'll try to fix trunk in the following days. Cheers, Mikkel. Den 01/01/2011 22.45 skrev : > Author: psteitz > Date: Sat Jan 1 21:45:35 2011 > New Revision: 1054298 > > U

Re: [math] 2.2 compatibility issues

Hi, In general: I understand that removing e.g. functions to an interface is (seriously) breaking compatibility. Why is it just as bad to add e.g. functions to an interface? As far as I know, the binaries are still compatible, so where does this "adding breaks compatibility" stem from? And is it o

Re: [math] 2.2 compatibility issues

2011/1/2 Phil Steitz : > On Sun, Jan 2, 2011 at 1:42 PM, Mikkel Meyer Andersen wrote: > >> Hi, >> >> In general: I understand that removing e.g. functions to an interface >> is (seriously) breaking compatibility. Why is it just as bad to add >> e.g. functio

Re: [math] meaning of "support" in distributions classes

Hi, You're right, Phil. Support for beta is [0, 1] and not (0, 1) as stated on Wikipedia. As you mention, support for continuous distributions is closed, hence the corresponding isInclusive-functions can be discussed. I thought about it being useful for infinity, but we could let users deal with t

Re: [math] meaning of "support" in distributions classes

2011/1/3 Phil Steitz : > On Mon, Jan 3, 2011 at 2:23 AM, Mikkel Meyer Andersen wrote: > >> Hi, >> >> You're right, Phil. Support for beta is [0, 1] and not (0, 1) as stated on >> Wikipedia. As you mention, support for continuous distributions is closed, >

Re: [math] meaning of "support" in distributions classes

2011/1/3 Phil Steitz : > On Mon, Jan 3, 2011 at 1:41 PM, Mikkel Meyer Andersen wrote: > >> 2011/1/3 Phil Steitz : >> > On Mon, Jan 3, 2011 at 2:23 AM, Mikkel Meyer Andersen >> wrote: >> > >> >> Hi, >> >> >> >> You&#

Re: [math] meaning of "support" in distributions classes

ication that would make the Wikipedia Beta > example make sense (but make the Uniform example wrong ;) would be to > consider whether or not the endpoints are in the domain of the density > function.  I don't see that info as adding a lot of value, so am +1 for just > dropping the is

Re: [Math] Unit test too slow

Hi, Thanks for noticing. It's probably the exact test that takes so long. I'll have a look at the test and see if a smaller example (fewer observations) will do. Unfortunately it won't be within the next two weeks. Cheers, Mikkel. Den 08/01/2011 00.09 skrev "Gilles Sadowski" : > Hi. > > I recentl

Re: svn commit: r1056580 - /commons/proper/math/trunk/src/test/java/org/apache/commons/math/stat/inference/WilcoxonSignedRankTestTest.java

Thanks, Phil! Den 08/01/2011 02.04 skrev : > Author: psteitz > Date: Sat Jan 8 01:04:04 2011 > New Revision: 1056580 > > URL: http://svn.apache.org/viewvc?rev=1056580&view=rev > Log: > Commented out long-running test case. > > Modified: > commons/proper/math/trunk/src/test/java/org/apache/commons/m

Re: [Math] Unit test too slow

Agree. Den 08/01/2011 02.07 skrev "Phil Steitz" : > On Fri, Jan 7, 2011 at 7:54 PM, Mikkel Meyer Andersen wrote: > >> Hi, >> >> Thanks for noticing. It's probably the exact test that takes so long. I'll >> have a look at the test and see if

Re: svn commit: r1056747 - in /commons/proper/math: branches/MATH_2_X/src/site/xdoc/changes.xml trunk/src/site/xdoc/changes.xml

Hi, Thanks! It should probably be mikl, my username, instead of mikkel, my name. I don't have access to committing these two weeks, but I'll change it in two weeks time. Cheers, Mikkel. 2011/1/8 : > Author: psteitz > Date: Sat Jan  8 17:50:54 2011 > New Revision: 1056747 > > URL: http://svn.apa

Re: svn commit: r1060917 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

Hi, Just a quick question: when a == 0.0f or NA, then a is returned. Why not just put a special isNA() in the beginning and 0.0f in the existing code? Wouldn't it save a tiny bit not loading a? Cheers, Mikkel. Den 19/01/2011 20.26 skrev : > Author: sebb > Date: Wed Jan 19 19:26:19 2011 > New Revi

Re: svn commit: r1060917 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

Okay, cheers. Shouldn't the javadoc reflect the +/-0 or is that implicit? Den 20/01/2011 02.21 skrev "sebb" : > On 20 January 2011 01:16, Mikkel Meyer Andersen wrote: >> Hi, >> >> Just a quick question: when a == 0.0f or NA, then a is returned. Why not

Re: svn commit: r1060917 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

Never mind - didn't see the commit. Den 20/01/2011 02.34 skrev "Mikkel Meyer Andersen" : > Okay, cheers. Shouldn't the javadoc reflect the +/-0 or is that implicit? > Den 20/01/2011 02.21 skrev "sebb" : >> On 20 January 2011 01:16, Mikkel Meyer And

[MATH] Names of fields and arguments coincide (in reply to: svn commit: r1065146)

Hi, I noticed that you have code where fields and constructor arguments have the same name. As far as I remember that is not good practise, but I might be wrong :-)? Cheers, Mikkel. 2011/1/30 : > Author: erans > Date: Sat Jan 29 23:38:39 2011 > New Revision: 1065146 > > URL: http://svn.apache.o

Re: [MATH] Names of fields and arguments coincide (in reply to: svn commit: r1065146)

Hi, 2011/1/30 Gilles Sadowski : > Hello. > >> I noticed that you have code where fields and constructor arguments >> have the same name. As far as I remember that is not good practise, >> but I might be wrong :-)? > > Most (all?) of CM follows this convention. Just to be sure: Do you mean that in

Re: [MATH] Names of fields and arguments coincide (in reply to: svn commit: r1065146)

Thanks for clearifying :). Den 30/01/2011 16.01 skrev "Gilles Sadowski" : > On Sun, Jan 30, 2011 at 02:58:43PM +0100, Mikkel Meyer Andersen wrote: >> Hi, >> >> 2011/1/30 Gilles Sadowski : >> > Hello. >> > >> >> I noticed that you have co

Re: [math] the 2.2 release saga conclusion ?

Hi Luc, +1 Thanks for the constructive post. I agree with the compromise although I don't have the entire outlook of pros and cons. Cheers, Mikkel. Den 11/02/2011 18.50 skrev "Luc Maisonobe" : > Hi all, > > I would like to have 2.2 out as soon as possible. I would like to > propose yet another in

Re: [VOTE] Release math 2.2 based on RC2

+1 2011/2/20 Luc Maisonobe : > Tag: http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_2_RC2/ > > Distributions: http://people.apache.org/~luc/math-2.2-RC2/ > > Maven artifacts: http://people.apache.org/~luc/math-2.2-RC2/maven/ > > Documentation bundled with the binary distribution: >

[MATH] Matrix hierarchy reorganization

Dear community, I've started on implementing Kalman filter and have once again run into a structural challenge in regards to matrix hierarchy (as with https://issues.apache.org/jira/browse/MATH-435 and https://issues.apache.org/jira/browse/MATH-437 ). We have two base types of matrices: RealMatri

Re: [MATH] Matrix hierarchy reorganization

2011/2/21 : > Hi Mikkel, > > - "Mikkel Meyer Andersen" a écrit : > >> Dear community, >> >> I've started on implementing Kalman filter and have once again run >> into a structural challenge in regards to matrix hierarchy (as with >> ht

Re: [VOTE] Release math 2.2 based on RC3

Simone, Apparently there is some problems with Maven 3. Please try Maven 2 instead. To quote Luc from earlier: "I think I have read somewhere that maven 3 have issues with the site plugin which was not ready for production. Could you try using maven2 ?". Cheers, Mikkel. 2011/2/23 Simone Tripodi :

Re: [VOTE] Release math 2.2 based on RC5

+1 Den 25/02/2011 18.19 skrev "Jörg Schaible" : > Luc Maisonobe wrote: > >> Tag: >> >> >> All artifacts in Nexus staging repository: >> > < https://repository.apache.org/content/repositories/orgapachecommons-051/org/apache/com

Re: [VOTE] Release math 2.2 based on RC6

+1 Cheers, Mikkel. 2011/2/28 Simone Tripodi : > +1 > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Mon, Feb 28, 2011 at 6:56 AM, Dimitri Pourbaix > wrote: >> Luc, >> >>> Votes, please. This vote will close in 72 hours, 2011-03-01T20:00:00 UTC >>> >>> [ ] +

[MATH] MATH-437 Kolmogorov Smirnov Distribution

ven't got any attention, so now it's included as a private method although that obviously isn't the way to do it. Cheers, Mikkel. 2011/3/18 Mikkel Meyer Andersen (JIRA) : > >     [ > https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.syste

Re: [continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)

Sorry for this. I'm not sure why my mvn site didn't catch this. Solved in r1083733 and r1083734 for AbstractFieldMatrix.java and KolmogorovSmirnovDistributionImpl.java, respectively. 2011/3/21 Continuum@vmbuild : > Online report : > http://vmbuild.apache.org/continuum/buildResult.action?buildId=5

Re: [math] RandomData/RandomDataImpl

Hi, In my opinion, we have to be careful. It's not that I don't like the idea, but it might be a slippery approach merging interfaces with the uniquely implementing class - where do we stop merging? Also, RandomDataImpl actually does have substantial non-trivial functionality like hexStrings, Poi

Re: svn propchange: r1083698 - svn:log

Hi Luc, In this case I changed the log because I gave the wrong issue id. Sorry for that confusion. But in general, yes, I will try to do that. Although I'm not sure how detailed to be when a commit fixes an issue. I think I'm quite elaborate when the commit fixes minor stuff such as typos, fixin

Re: svn propchange: r1083698 - svn:log

Okay, I'll try to do that. Thanks for pointing it out :-). 2011/3/21 Luc Maisonobe : > Le 21/03/2011 21:00, Mikkel Meyer Andersen a écrit : >> Hi Luc, >> >> In this case I changed the log because I gave the wrong issue id. >> Sorry for that confusion. >> &g

Re: svn propchange: r1083698 - svn:log

eldMatrix". Cheers, Mikkel. 2011/3/21 Phil Steitz : > On 3/21/11 1:00 PM, Mikkel Meyer Andersen wrote: >> Hi Luc, >> >> In this case I changed the log because I gave the wrong issue id. >> Sorry for that confusion. >> >> But in general, yes, I w

Re: svn commit: r1083965 - /commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/KolmogorovSmirnovDistributionTest.java

Sorry. Thanks for correcting. 2011/3/21 : > Author: sebb > Date: Mon Mar 21 21:29:07 2011 > New Revision: 1083965 > > URL: http://svn.apache.org/viewvc?rev=1083965&view=rev > Log: > Convert to Junit4 > > Modified: >     > commons/proper/math/trunk/src/test/java/org/apache/commons/math/distributio

Re: svn propchange: r1083713 - svn:log

Sorry for this mess in logs for r1083698 and r1083713. It should be okay now. 2011/3/21 : > Author: mikl > Revision: 1083713 > Modified property: svn:log > > Modified: svn:log at Mon Mar 21 22:12:56 2011 > -- > --- svn:lo

Re: [math] cleaning code

Hi Luc, Thanks! I'll fix MannWhitneyUTestImpl. Cheers, Mikkel. Den 27/03/2011 18.48 skrev "Luc Maisonobe" : > Hi all, > > I have squashed a number of findbugs and checkstyle warnings introduced > by recent changes (more than one hundred). > > There are a few remaining bugs for which I would like

Re: [math] [sandbox] merging Apache Commons BSP into Apache Commons Math

+1 >From me, too. Den 14/05/2011 11.08 skrev "Luc Maisonobe" : > Hello, > > Some weeks ago, I have imported in the sandbox a new component, Apache > Commons BSP which implements Binary Partitioning Trees (see the thread > about this creation here: ). > >

Re: [math] [GUMP@vmgump]: Project commons-math (in module apache-commons) failed

I'm +1 on using @Retry instead of fixed seed. 2011/5/16 Dr. Dietmar Wolz : > Nikolaus Hansen, Luc and me discussed this issue in Toulouse. > We have two options to handle this kind of failure in tests of stochastic > optimization algorithms: > 1) fixed random seed - but this reduces  the value of

Re: [math] [sandbox] merging Apache Commons BSP into Apache Commons Math

+1 >From me as well. Den 18/05/2011 22.22 skrev "Phil Steitz" : > On 5/18/11 2:54 AM, Luc Maisonobe wrote: >> Le 18/05/2011 11:49, Gilles Sadowski a écrit : >>> On Wed, May 18, 2011 at 10:03:59AM +0100, Stephen Colebourne wrote: On 18 May 2011 09:11, Luc Maisonobe wrote: >> Should I replac

[MATH] Patches ready for improvement of generating random values from Gamma and Exp

Dear community, I've made improvements to generating random Gamma and Exp distributed values. Gamma: A result of a user-need. See https://issues.apache.org/jira/browse/MATH-585 Exp: It needed some maintenance, too :-). See https://issues.apache.org/jira/browse/MATH-597 Both have patch proposals

[MATH] Commit review of MATH-597

Hi, I've now made a commit. I'm now writing to be sure that I did it correctly. First of all, I of course committed the code. I also added the following to changes.xml. I did this in the same commit (this is best, right?): Implemented faster generation of random exponential distribu

Re: [math] EmpiricalDistribution

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

Re: [math] EmpiricalDistribution

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

Re: [math] EmpiricalDistribution

2011/9/7 Phil Steitz : > On 9/6/11 8:58 AM, Mikkel Meyer Andersen wrote: >> 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: >>>>>

Re: [math] break up MathUtils?

2011/10/3 Phil Steitz : > I agree with Gilles' recent comment that this class is bloated.  Any ideas on > how to break it up?  Now would be a good time to so it. > > Phil One way would be to divide it into DiscreteUtils (int's and long's) and ContinuousUtils (float's and double's). Cheers, Mikkel

Re: [math] Support for Abelian Groups and Rings?

2011/10/3 Sébastien Brisard : >> I would be curious to see how such a class would actually help you.  I have >> to admit that a big part of my curiosity is due to the fact that I don't >> understand how it really would help.  It could be, as you say, beautiful but >> useful is sometimes are more di

Re: [math] break up MathUtils?

2011/10/3 Gilles Sadowski : > On Mon, Oct 03, 2011 at 05:42:15PM +0200, Mikkel Meyer Andersen wrote: >> 2011/10/3 Phil Steitz : >> > I agree with Gilles' recent comment that this class is bloated.  Any ideas >> > on how to break it up?  Now would be a good time to

Re: [math] Add methods opposite() and inverse() to o.a.c.m.FieldElement

2011/10/4 Luc Maisonobe : > Le 04/10/2011 05:22, Sébastien Brisard a écrit : >> >> Good morning everyone, >> I would like to add the above mentioned methods to FieldElement. This >> would avoid awkward commands such as >> x.getField().getZero().substract(x) (for x.opposite()) >> and >> x.getField()

Re: [math] Distributions over sample spaces other than R

2011/10/30 Phil Steitz : > On 10/29/11 10:20 AM, cwinter wrote: >> Phil Steitz wrote: >>> I would say pull DiscreteDistribution out.  That is where the >>> difference really lies.  I have thought about suggesting that we >>> eliminate it altogether; but I still think there may be value in >>> suppo

Re: [math] Distributions over sample spaces other than R

I see your point, Phil, and agree with you. Thanks for clarifying. Cheers, Mikkel. Den 01/11/2011 18.24 skrev "Phil Steitz" : > On 11/1/11 1:05 AM, Mikkel Meyer Andersen wrote: > > 2011/10/30 Phil Steitz : > >> On 10/29/11 10:20 AM, cwinter wrote: > >>> Ph

Re: [math] Matrices and Vectors again

I also think it is a good idea, but with the addition of thinking parallelisation into the framework (e.g. in the map functionality). Whether it should be done in a branch or not, I don't know, but I guess the people who do know will reply on that :-). Cheers, Mikkel. 2011/11/23 Ted Dunning : > I

Re: [math] Inconsistencies (bugs) in PascalDistribution?

2011/11/28 Phil Steitz : > On 11/28/11 12:18 AM, Sébastien Brisard wrote: >> Hello, >> while working on MATH-711, I think I stumbled upon some >> inconsistencies in the implementation of the Pascal distribution. In >> fact, these might well be a bug, but since I'm a bit rusty on >> probabilities, I

Re: [math] Inconsistencies (bugs) in PascalDistribution?

2011/11/29 Sébastien Brisard : > Hi Mikkel >> >> Thanks for discovering this! I did the implementation, and apparently >> assumed notation as the referred source. Sorry for this. >> > I think there is nothing wrong in the source. Only, you adopted a > different definition of the random variable rep

Re: [math] Inconsistencies (bugs) in PascalDistribution?

2011/12/5 Sébastien Brisard : > Hi Mikkel, >> >> No, you are more than welcome to do the patch and I'll review it :-). Thanks! >> >> Cheers, Mikkel. >> > I've committed a correction (r1210359). Could you please review it and > post your comments on the JIRA ticket (MATH-715). > Thanks a lot! > Séba

Re: [math] Inconsistencies (bugs) in PascalDistribution?

2011/12/5 Sébastien Brisard : > Hi Mikkel, >> It seems like only the test was changed in r1210359 (svn diff -r >> 1210359). This does _not_ correspond to the log (svn log -r 1210359). > > Here is an excerpt of the email sent automatically when I committed > revision 1210359 > > ==BEGIN EXCE

[MATH] Re: svn commit: r1232324 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/distribution/ test/R/ test/java/org/apache/commons/math/distribution/

Hi, You write for x >= 0, but isn't only x > 0? Cheers, Mikkel. Den 17/01/2012 08.12 skrev : > Author: celestin > Date: Tue Jan 17 07:12:02 2012 > New Revision: 1232324 > > URL: http://svn.apache.org/viewvc?rev=1232324&view=rev > Log: > Implementation of log-normal distributions (MATH-733). Patc

Re: [MATH] Re: svn commit: r1232324 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/distribution/ test/R/ test/java/org/apache/commons/math/distribution/

2012/1/17 Sébastien Brisard : > Hi Mikkel, >> Hi, >> >> You write for x >= 0, but isn't only x > 0? >> >> Cheers, Mikkel. >> > OK (although the formula does make sense, since the limit exists). > Thanks for pointing that out, > Sébastien > Hi, I agree, but normally the support is not including the

Re: [Math] Toward releasing 3.0 ?

as still reservations > >  - MATH-431: the two tests were contributed by Mikkel Meyer Andersen >   (is he still active?) and I have cleaned up the exceptions while >   working on another issue. There are still things to do, as can be >   seen in the comments to the issue (mainly the results are

Re: [math] Gamma Distribution Algorithm

Hi Paul, Have you looked at the nextGamma in org.apache.commons.math.random? It should be much faster than using the inversion method. Cheers, Mikkel. 2012/3/29 Ted Dunning : > Yes the sample method is inherited, but the inverse cumulative distribution > function is not. > > On Wed, Mar 28, 2012

Re: [math] Gamma Distribution Algorithm

Dear all, I have created MATH-774 https://issues.apache.org/jira/browse/MATH-774 and assigned it to myself. I will check if other of the implemented methods in oacm.random are not used either and open new issues if that is the case. Thanks for making us aware of this, Paul. Cheers, Mikkel. 2012

  1   2   >