Re: [Math] Little thought about multi-threading

Hello, 2012/7/23 Thomas Neidhart : > On 07/22/2012 11:25 PM, Gilles Sadowski wrote: >> [...] Threaded execution, on the other hand, can be very, very helpful for a number of math algorithms and thread management inside commons math is a very reasonable option in those cases. T

Re: [Math] Little thought about multi-threading

Hi, 2012/7/30 Gilles Sadowski : >> > [...] >> >>> Well, you probably don't want to switch to Java 7 now, [...] >> >> >> >> Oh, yes, please! 8-P >> > >> > I would be in favor of this too, but we could also target it for the 4.0 >> > release together with the parallelization stuff. >> > >> > Thomas

Re: [Math] MATH-821 (Was: [continuum] BUILD FAILURE: ...)

Hello, 2012/7/13 Gilles Sadowski : > Hi. > >> >> as you already mentioned, this bug is filed in MATH-821. I really need >> some input, because I do not really know how to fix this bug in a >> statisfactory way. > > I'd suggest that users of "OpenMapRealVector" step up and provide advice on > how t

Re: [Math] Towards release 3.1

Hi Gilles, > > More than 60 issues have been resolved since the release of Commons Math > 3.0. > I think that it is time to lay out a road map for the next release (3.1), > with a target date of early September (at which point, 3.0 will be 6 months > old). > I agree. > > The following issues have

[all] NSWC and Apache license

Hello, I'm currently working on MATH-738, and am considering porting part of the FORTRAN "NSWC Library of Mathematics Subroutines" [1] (Naval Surface Warfare Center). The website states "This software is made available, without cost, to the general scientific community. The 1993 edition is an

Re: [all] NSWC and Apache license

Hi Kevan, thanks for your answer. 2012/8/8 Kevan Miller : > > On Aug 8, 2012, at 2:36 AM, Sébastien Brisard wrote: > >> Hello, >> I'm currently working on MATH-738, and am considering porting part of >> the FORTRAN "NSWC Library of Mathematics Subroutines&

Re: [all] NSWC and Apache license

Hi Jason, > > I can make some enquiries to see if it can be changed. Do you know which NSWC > released it, Dahlgren, Carderock and which code 90,50, etc? > Thanks, that would help a lot ! It's Dahlgren [1], FORTRAN 77. If the answer you get is a straightforward yes, that's fine. If it is a "no",

Re: [all] NSWC and Apache license

Hi, 2012/8/8 Luc Maisonobe : > Le 08/08/2012 17:58, Christian Grobmeier a écrit : >> On Wed, Aug 8, 2012 at 5:38 PM, Sébastien Brisard >> wrote: >> >>>>> Does that mean that porting it into Commons-Math is possible >>>>> (license-wise?). I w

Re: [all] NSWC and Apache license

Hi all, thanks for these answers. I need to digest all this. Of course, the primary origin (not going back to the original author) would be duly acknowledged. In fact, I've started translating the FORTRAN source. It's so much work that I'm considering writing the Java program from scratch, using th

[math] Changes in the Gamma class

Dear All, I'm currently working on accuracy improvements of the incomplete beta function, based on the NSWC library [1]. It's quite a long work, but it looks promising, since the implementation of the Gamma function they propose (I had to work first on Gamma before starting the actual work on Beta)

Re: [Math] MATH-843

Hi Gilles, > > Please have a look at MATH-843: > https://issues.apache.org/jira/browse/MATH-843 > > As indicated there, I think that the current documentation is clear enough. > I don't know how to test the assertion of the reporter. > In the absence of further comment, I'll resolve the issue as

Re: [math] Changes in the Gamma class

Hi 2012/8/16 Gilles Sadowski : > On Wed, Aug 15, 2012 at 04:58:39PM +0200, Sébastien Brisard wrote: >> Dear All, >> I'm currently working on accuracy improvements of the incomplete beta >> function, based on the NSWC library [1]. It's quite a long work, but i

Re: [Math] MATH-843

Hi, 2012/8/17 Gilles Sadowski : > Hello Sébastien. > >> > >> > Please have a look at MATH-843: >> > https://issues.apache.org/jira/browse/MATH-843 >> > >> > As indicated there, I think that the current documentation is clear enough. >> > I don't know how to test the assertion of the reporter. >>

[math] Double.NaN or NotStrictlyPositiveException?

Hi, the current implementation of Gamma.logGamma(double) fails silently when the argument is not strictly positive, returning Double.NaN. Previous discussions on this ML show that we all agree (do we?) that throwing an exception is preferrable. Since I'm reimplementing this function, I propose to c

Re: [all] displaying some class and sequence diagrams for our components

Hi Luc, 2012/8/20 Luc Maisonobe > > Le 20/08/2012 15:52, Simone Tripodi a écrit : > > Hi Gary! > > > >> I still like the idea! I was hoping at an automagic solution ;) > > > > Me too! :) > > I have used several tools that were able to do such automatic diagrams > generation. All tools that suppor

[math] About MATH-849 and the NSWC library

Dear all, please review the code I've attached to MATH-849. The improvement in accuracy is great. I also implemented, besides logGamma(x), a new function -- namely Gamma(x). I would like to know if you feel the references to the NSWC library is fair. Thanks for your advice, Sébastien PS : with th

[math] UnexpectedNegativeIntegerException

Hi, in MATH-849, I have proposed an implementation of Gamma(x) (previously, class Gamma had only logGamma(x)). Gamma(x) is not defined for x negative integer. In such instances, I would like to throw an exception instead of returning Double.NaN. However, creating a new exception in o.a.c.m.exceptio

Re: [math] UnexpectedNegativeIntegerException

Hi Luc, 2012/8/23 Luc Maisonobe : > Le 23/08/2012 05:16, Sébastien Brisard a écrit : >> Hi, >> in MATH-849, I have proposed an implementation of Gamma(x) >> (previously, class Gamma had only logGamma(x)). Gamma(x) is not >> defined for x negative integer. In such

Re: [math] UnexpectedNegativeIntegerException

Hi Gilles, 2012/8/23 Gilles Sadowski : > On Thu, Aug 23, 2012 at 10:05:10AM +0200, Sébastien Brisard wrote: >> Hi Luc, >> >> 2012/8/23 Luc Maisonobe : >> > Le 23/08/2012 05:16, Sébastien Brisard a écrit : >> >> Hi, >> >> in MATH-849, I have pr

[math] Formatting

Hi, in MATH-851, a discussion about code- and comments-formatting as yet again taken place. It is true we are a bit fuzzy on this side. I propose to start writing something up in the developer's guide. This will be a start, and every one of you could then comment on these guidelines. The idea is to

Re: [math] Formatting

Hi, > > Probably easiest to use the Wiki for this, at least initially. > I'm not very fond of the Wiki: maybe I could just start a JIRA ticket, that would allow recording our discussions. > If there are compulsory rules - e.g. no tabs - a reason should be > given, for example: > Tab settings vary

Re: [math] UnexpectedNegativeIntegerException

Hi, thanks for all these answers. 2012/8/23 Phil Steitz : > On 8/23/12 5:37 AM, Luc Maisonobe wrote: >> Le 23/08/2012 13:37, Gilles Sadowski a écrit : >>> On Thu, Aug 23, 2012 at 12:35:18PM +0200, Sébastien Brisard wrote: >>>> Hi Gilles, >>>> >>>

Re: [math] About MATH-849 and the NSWC library

Hi Thomas, thanks for reviewing. > > static final double HALF_LOG_2_PI is not used anymore > well spotted! I'll get rid of that. I'm also currently revisiting MATH-753, I would like to get rid of all things related to the Lanczos approximation (which is no longer used for Gamma, but still necessa

Re: [math] Formatting

Hi, the idea is *not* to come up with dozens of impossible, picky and useless rules, but a few rules which we do care about, are easily enforced, and ensure some kind of consistency. Of course, consistency in code formatting is more easily enforced than in comments formatting. But I have to say th

Re: [math] UnexpectedNegativeIntegerException

, Aug 23, 2012 at 12:35:18PM +0200, Sébastien Brisard wrote: >>>>>> Hi Gilles, >>>>>> >>>>>> 2012/8/23 Gilles Sadowski : >>>>>>> On Thu, Aug 23, 2012 at 10:05:10AM +0200, Sébastien Brisard wrote: >>>>>>>

Re: [math] introducing DerivativeStructure into solvers hierarchy

Hello, and thanks for all this work! The new framework looks great... Can't wait to find a use-case... 2012/8/24 Gilles Sadowski : >> [...] >> >> I see three different solutions for this. >> >> 1) don't try to merge at all, and duplicate the Newton solver with the >>new type. >> 2) change the

Re: [math] UnexpectedNegativeIntegerException

Hi Gilles, 2012/8/24 Gilles Sadowski > > Hi. > > > > [...] > > > > I see that's another area where everyone has its own opinion because > > of various experiences. I was previously in favor of exceptions, but > > maybe it's too much for such a low-level component as a standard or > > special func

Re: [math] Re: Single root for Exceptions

Hello, 2012/8/29 Luc Maisonobe : > Le 29/08/2012 01:40, Gilles Sadowski a écrit : >> Hi. > > Hello, > >> [...] >>> >>> I think I get your point, but again given transitive / nested >>> dependencies I would not want to depend on it, even if all of the >>> components have single-rooted exceptio

Re: [math] Re: Single root for Exceptions

Hello, 2012/8/30 Gilles Sadowski : > Hello. > > To summarize: > (1) Does anyone disagree with having all CM exceptions inherit > from a new "MathRuntimeException" which itself will inherit > from the standard "RuntimeException"? +0: my background is not good enough. > (2) Does anyone d

[math] Binary or text resource files?

Hi, testing of special functions involves comparing actual values returned by CM with expected values as computed with an arbitrary precision software (I use Maxima [1] for this purpose). As I intend these tests to be assesments of the overall accuracy of our implementations, the number of test val

[math] Please have a look to MATH-852: Improvements to the Developer's Guide

Thanks a lot! - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Binary or text resource files?

Hi Gilles, thanks for your answer. 2012/8/30 Gilles Sadowski : > Hello. > >> testing of special functions involves comparing actual values returned >> by CM with expected values as computed with an arbitrary precision >> software (I use Maxima [1] for this purpose). As I intend these tests >> to b

Re: [math] Re: Single root for Exceptions

Hi, 2012/8/30 Gilles Sadowski : > On Wed, Aug 29, 2012 at 06:33:05PM -0700, Phil Steitz wrote: >> On 8/29/12 3:04 PM, Gilles Sadowski wrote: >> > Hello. >> > >> > To summarize: >> > (1) Does anyone disagree with having all CM exceptions inherit >> > from a new "MathRuntimeException" which it

Re: [math] Re: Single root for Exceptions

Hello, [...] Thus, shall I open a JIRA ticket with the tasks of completing the "throws" clauses of all CM methods? Does someone absolutely needs this task tobe completed before releasing 3.1? [I don't think that it's possible without a huge effort from everyone.

Re: [math] Binary or text resource files?

Hello, right, until we reach a consensus, I've inlined the reference data as double[][], trying to keep those arrays to a reasonable size. I really would like to provide publicly available extensive validation of all special functions we have (and will) implement. It seems to me very important. BOO

Re: [math] Binary or text resource files?

2012/8/30 Gilles Sadowski : > Hello. > >> testing of special functions involves comparing actual values returned >> by CM with expected values as computed with an arbitrary precision >> software (I use Maxima [1] for this purpose). As I intend these tests >> to be assesments of the overall accuracy

Re: [Math] Formatting (Was: svn commit: r1379270 - /commons/proper/math/trunk/...)

Hi Gilles, 2012/8/31 Gilles Sadowski : > Hello Sébastien. > >> Author: celestin >> Date: Fri Aug 31 03:12:16 2012 >> New Revision: 1379270 >> >> URL: http://svn.apache.org/viewvc?rev=1379270&view=rev >> Log: >> MATH-849: changed boundary case x = 8.0 in double Gamma.logGamma(double). >> >> Modifie

Re: [Math] Formatting (Was: svn commit: r1379270 - /commons/proper/math/trunk/...)

Hi sebb, 2012/8/31 sebb : > On 31 August 2012 14:52, Sébastien Brisard wrote: >> Hi Gilles, >> >> 2012/8/31 Gilles Sadowski : >>> Hello Sébastien. >>> >>>> Author: celestin >>>> Date: Fri Aug 31 03:12:16 2012 >>>> New Rev

Re: [math] Re: Single root for Exceptions

Hello, 2012/8/31 Thomas Neidhart : > On 08/31/2012 11:17 AM, Luc Maisonobe wrote: >> Le 31/08/2012 03:22, Sébastien Brisard a écrit : >>> Hello, >>> >>>>>>> [...] >>>>>>> >>>>>>> Thus, shall I open a JIRA t

Re: [math] Re: Single root for Exceptions

DefiniteOperatorException" clause in the signature of PreconditionedIterativeLinearSolver.solveInPlace as well? Sébastien 2012/9/1 Sébastien Brisard : > Hello, > > > 2012/8/31 Thomas Neidhart : >> On 08/31/2012 11:17 AM, Luc Maisonobe wrote: >>> Le

Re: [math] Re: Single root for Exceptions

Hi Luc, 2012/9/1 Luc Maisonobe : > Le 01/09/2012 10:03, Sébastien Brisard a écrit : >> Hi, >> >> in ConjugateGradient, I get the following error >> >> "Exception NonPositiveDefiniteOperatorException is not compatible with >> throws clause in >>

Re: [math] Re: Single root for Exceptions

Hi, 2012/9/1 Gilles Sadowski : > Hello. > >> >>> >> >>> in ConjugateGradient, I get the following error >> >>> >> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with >> >>> throws clause in >> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator, >> >>> Re

Re: [math] Re: Single root for Exceptions

createFieldIdentityMatrix, so what should we do 1. Populate the throws clause of createFieldIdentityMatrix with DimensionMismatchException anyway? 2. try/catch with empty catch, which I find ugly? Sébastien 2012/9/3 Sébastien Brisard : > Hi, > > 2012/9/1 Gilles Sadowski : >> Hello. >&g

Re: [math] Re: Single root for Exceptions

Hi again, 2012/9/1 Gilles Sadowski : > Hello. > >> >>> >> >>> in ConjugateGradient, I get the following error >> >>> >> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with >> >>> throws clause in >> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator, >>

[math] Deprecate, then remove OpenMapRealVectors?

]. Before any decision is taken, we need some input from potential users (if any) of this class. Any feedback would be most welcome! Thanks in advance, Sébastien Brisard [1] http://markmail.org/thread/vu2ulvyt7pseyheq [2] https://issues.apache.org/jira/browse/MATH-803 [3] https://issues.apache.org

Re: [all] FindBugs' Switch statement found in class.method where default case is missing

Hello, 2012/9/4 James Carman : > Something like: > > throw new IllegalArgumentException("This should never happen because > we are so smart we thought of every possibility in our case > statement."); > > would suffice :) > Not that it really matters, since this is never going to occur, but I think

Re: [all] FindBugs' Switch statement found in class.method where default case is missing

I wasn't necessarily saying that we should always use > IllegalArgumentException (although it can be applicable if the thing > being switched upon is an argument to the method). The idea was that > we could throw an exception of some sort in our default clause. > > On Tue, Sep 4,

Re: [Math] About "NullArgumentException" (Was: svn commit: r1381284 - in /commons/proper/math/trunk/...)

Hi Gilles, 2012/9/6 sebb : > On 5 September 2012 22:46, Gilles Sadowski > wrote: >> On Wed, Sep 05, 2012 at 06:30:08PM -, l...@apache.org wrote: >>> Author: luc >>> Date: Wed Sep 5 18:30:08 2012 >>> New Revision: 1381284 >>> >>> URL: http://svn.apache.org/viewvc?rev=1381284&view=rev >>> Log

Re: [Math] About "NullArgumentException" (Was: svn commit: r1381284 - in /commons/proper/math/trunk/...)

Hi Luc, 2012/9/6 luc : > Hi all, > > Le 2012-09-06 07:08, Sébastien Brisard a écrit : > >> Hi Gilles, >> >> 2012/9/6 sebb : >>> >>> On 5 September 2012 22:46, Gilles Sadowski >>> wrote: >>>> >>>> On Wed, Sep 05, 20

Re: [Math] About "NullArgumentException"

Hi, 2012/9/10 Gilles Sadowski : > On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote: >> On 9/9/12 4:34 AM, Gilles Sadowski wrote: >> > Hi. >> > >> > Further discussion on the JIRA page >> > https://issues.apache.org/jira/browse/MATH-856 >> > cannot reach a consensus on solving the issu

Re: [Math] About "NullArgumentException"

Hi What should I do there? I'm trying to work on MATH-854. It turns out that FieldElement.add throws a NAE. Should I catch it below, and rethrow it with a more detailed message (including the entry index)? Best, Sébastien /** {@inheritDoc} */ public FieldVector add(FieldVector v)

[math] Is this good practice?

Hi, I thought it was not good practice to rely on exception in unexceptional circumstances. In ArrayFieldVector, there are numerous occurences of the following pattern public FieldVector add(FieldVector v) throws DimensionMismatchException { try { return add((ArrayF

Re: [Math] About "NullArgumentException"

Hello, 2012/9/11 Gilles Sadowski : > On Mon, Sep 10, 2012 at 01:31:12PM -0700, Phil Steitz wrote: >> On 9/10/12 11:47 AM, Sébastien Brisard wrote: >> > Hi >> > What should I do there? >> > I'm trying to work on MATH-854. It turns out that FieldElement

Re: [Math] About "NullArgumentException"

Hi, 2012/9/11 Gilles Sadowski : > On Mon, Sep 10, 2012 at 08:47:35PM +0200, Sébastien Brisard wrote: >> Hi >> What should I do there? > > If we adopt the "flexible" policy (cf. other post), then you can do what you > want. ;-) > This is absolutely what I do no

Re: [math] Is this good practice?

Hi, 2012/9/11 Gilles Sadowski : > On Mon, Sep 10, 2012 at 10:07:11PM +0200, Benedikt Ritter wrote: >> Hi, >> >> 2012/9/10 Luc Maisonobe : >> > Le 10/09/2012 21:08, Sébastien Brisard a écrit : >> >> Hi, >> > >> > Hi Sébastien, >>

Re: [Math] About "NullArgumentException"

Hi Phil, 2012/9/10 Phil Steitz : > On 9/10/12 11:47 AM, Sébastien Brisard wrote: >> Hi >> What should I do there? >> I'm trying to work on MATH-854. It turns out that FieldElement.add >> throws a NAE. Should I catch it below, and rethrow it with a more >>

Re: svn commit: r1383770 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/exception/util/ main/java/org/apache/commons/math3/linear/ main/resources/assets/org/apache/commons/mat

Hi Gilles, 2012/9/12 Gilles Sadowski : > Hello Sébastien. > > On Wed, Sep 12, 2012 at 04:43:39AM -, celes...@apache.org wrote: >> Author: celestin >> Date: Wed Sep 12 04:43:38 2012 >> New Revision: 1383770 >> >> URL: http://svn.apache.org/viewvc?rev=1383770&view=rev >> Log: >> Removed Localize

Re: [Math] About "NullArgumentException"

Hi Gilles, 2012/9/12 Gilles Sadowski : > On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote: >> Hi Phil, >> >> 2012/9/10 Phil Steitz : >> > On 9/10/12 11:47 AM, Sébastien Brisard wrote: >> >> Hi >> >> What should I do there? &

Re: [Math] Towards release 3.1

Hi Gilles, 2012/9/12 Gilles Sadowski : > Hello. > > This thread was left alone for some time, although the main issue was not > settled: I requested the release of a new version of CM. > > I quote my remarks from an earlier message in this thread: > >> [...] issues resulted in some work being done

Re: [Math] About "NullArgumentException"

2012/9/12 Gilles Sadowski : > On Wed, Sep 12, 2012 at 01:14:32PM +0200, Sébastien Brisard wrote: >> Hi Gilles, >> >> 2012/9/12 Gilles Sadowski : >> > On Wed, Sep 12, 2012 at 06:46:29AM +0200, Sébastien Brisard wrote: >> >> Hi Phil, >> >> >

Re: svn commit: r1383770 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/exception/util/ main/java/org/apache/commons/math3/linear/ main/resources/assets/org/apache/commons/mat

>> >> } catch (final MathArithmeticException e) { >> >> -throw new >> >> MathArithmeticException(LocalizedFormats.ENTRY, i); >> >> +throw new >> >> MathArithmeticException(LocalizedFormats.INDEX, i); >> >> } >> >> } >> > >> > Do w

Re: [Math] Towards release 3.1

> [...] > I have been working on the stat package > throws stuff. If I can have the weekend to finish, I could finish > that; otherwise we release with this issue partly done (which is OK > by me, as long as we push out the ticket). > I'm still working on the linear package, and there is still a l

[math] Documenting exceptions in interfaces (MATH-854)

Dear all, in previous discussions, it was decided that Interfaces (and, I suppose abstract methods) should *not* have a throws clause. So, yesterday, I started modifying the javadoc of FieldVector. Each "throws" clause was simply replaced by the following statement "Implementations should throw [..

Re: [math] Documenting exceptions in interfaces (MATH-854)

Hi, 2012/9/13 Gilles Sadowski : > Hello. > > I'm also feeling tired of those issues. I must point out that this seems so > complicated _because_ we depart from best practices (as finely described in > e.g. "Effective Java"). > Whatever seems a help (and probably is sometimes) in one direction lead

Re: [math] Documenting exceptions in interfaces (MATH-854)

Hi, 2012/9/13 Gilles Sadowski : > On Thu, Sep 13, 2012 at 12:04:52PM +0200, Sébastien Brisard wrote: >> Hi, >> >> 2012/9/13 Gilles Sadowski : >> > Hello. >> > >> > I'm also feeling tired of those issues. I must point out that this seems so >

Re: [math] Documenting exceptions in interfaces (MATH-854)

Hi Phil, thanks for this answer. 2012/9/13 Phil Steitz : > On 9/12/12 11:27 PM, Sébastien Brisard wrote: >> Dear all, >> in previous discussions, it was decided that Interfaces (and, I >> suppose abstract methods) should *not* have a throws clause. > > I probably sh

Re: [Math] About "NullArgumentException"

Hi, 2012/9/13 Gilles Sadowski : > On Thu, Sep 13, 2012 at 01:10:41AM +0200, Gilles Sadowski wrote: >> Hello. >> >> [For those who don't wish to read the whole post, please at least go towards >> the end and indicate your preferred option. Thanks.] >> >> [... long post skipped ...] >> >> Back to sq

Re: [Math] About "NullArgumentException"

Hi Phil >> >> Back to square one, with 3 fully consistent alternatives: >> 1. CM to always check for null? Then "NullArgumentException" inheriting from >> "MathIllegalArgumentException" is fine because we promise to the user >> that >> no NPE will ever propagate through the CM layer. [Br

Re: [Math] About "NullArgumentException"

Hi Gilles, 2012/9/14 Gilles Sadowski : > On Fri, Sep 14, 2012 at 10:41:50AM +0200, Luc Maisonobe wrote: >> Le 14/09/2012 08:46, Sébastien Brisard a écrit : >> > Hi Phil >> > >> >>> >> >>> Back to square one, with 3 fully consistent a

Re: [Math] About "NullArgumentException"

Hi Gilles, 2012/9/17 Luc Maisonobe : > Le 17/09/2012 11:50, Gilles Sadowski a écrit : >> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote: >>> OK, I give up. Lets do option 2. Just warn users in the User Guide >>> somewhere that our APIs are in general not null-safe and unless the >>>

[all] xdoc vs. apt

Hi, I'm looking into extending the user's guide of Commons-Math for special functions. xdoc seems to be offering only very crude formatting possibiliities, and apt seems much better. It should work out of the box, alongside with existing xdoc pages. However, I can't seem to make it work, and I was

Re: [all] xdoc vs. apt

Hi, thanks for these answers. I agree that apt does not seem much better than xdoc, but it at least offers table formatting and so on. So can anyone recommend a good format? Otherwise, I'm quite happy with xhtml. An option I'm going to look at at work is sphinx [1]. It has become widely spread in

[math] About MATH-852: Improvements to the Developer's Guide

Hi, I'd like to make a move on this issue. Does everyone agree with what's already written in this ticket (not much, I'm afraid). Does anyone want to add anything to the formatting section? This should be something we are particularly attached to, and that can't be revealed by the checkstyle report

Re: [all] xdoc vs. apt

Hi, 2012/9/18 Sébastien Brisard : > Hi, > thanks for these answers. > I agree that apt does not seem much better than xdoc, but it at least > offers table formatting and so on. > So can anyone recommend a good format? Otherwise, I'm quite happy with xhtml. > > An opti

Re: [all] xdoc vs. apt

Hi Luc, 2012/9/18 luc : > Le 2012-09-18 07:46, Sébastien Brisard a écrit : >> >> Hi, > > > Hi Sébastien, > >> >> 2012/9/18 Sébastien Brisard : >>> >>> Hi, >>> thanks for these answers. >>> I agree that apt does not seem m

Re: [all] xdoc vs. apt

Hi Gilles, > > As you both point out indirectly, the Javadoc system is not exactly suitable > to compose a scientific document. But I remind that its main goal is to > explain the API of a code, not to explain the science that supports the > implementation. > As a matter of fact, I was talking abo

Re: [all] xdoc vs. apt

Hi Phil, thanks for your thoughts! 2012/9/18 Phil Steitz : > On 9/18/12 6:47 AM, Sébastien Brisard wrote: >> Hi Gilles, >> >>> As you both point out indirectly, the Javadoc system is not exactly suitable >>> to compose a scientific document. But I remind that it

Re: [Math] About "NullArgumentException"

Hello, 2012/9/17 Gilles Sadowski : > On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote: >> OK, I give up. Lets do option 2. Just warn users in the User Guide >> somewhere that our APIs are in general not null-safe and unless the >> javadoc explicitly allows nulls, they can expect NPE w

Re: [Math] About "NullArgumentException"

Hi, 2012/9/18 Phil Steitz : > On 9/18/12 12:02 PM, Sébastien Brisard wrote: >> Hello, >> >> 2012/9/17 Gilles Sadowski : >>> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote: >>>> OK, I give up. Lets do option 2. Just warn users in the User

Re: [math] apachecon

Hi Thomas, it would have been nice to meet up face to face. Unfortunately, I won't be able to make it. I would have loved to, though. I hope you have fun, there. Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.

Re: [math] Adding some methods in Precision class (oacm.util)

Hi Yannick, > > About the default value (1e-14), I know the tolerance is case-dependant, but > some times, we don't precisely know the order of magnitude (ex : jacobians > matrices) and it's quite practical to have a default value. > In our tools, we use this value in the test classes, but also

[math] APT format for the users guide

Hello, as I previously said, I'd like to extend the user's guide for the special functions package. I am not a big fan of the xdoc format currently in use, at is not easily readable. So I thought I would give APT a go. Please find below the code corresponding to the current "Special Functions" page

Re: [math] Adding some methods in Precision class (oacm.util)

Hi, 2012/9/20 Anxionnat Julien : >> De : Tanguy Yannick [mailto:yannick.tan...@cnes.fr] >> About the default value (1e-14), I know the tolerance is case- >> dependant, but some times, we don't precisely know the order of >> magnitude (ex : jacobians matrices) and it's quite practical to have a >>

Re: [math] APT format for the users guide

Hello Gilles, 2012/9/20 Gilles Sadowski : > Hi. > >> as I previously said, I'd like to extend the user's guide for the >> special functions package. I am not a big fan of the xdoc format >> currently in use, at is not easily readable. So I thought I would give >> APT a go. Please find below the co

Re: [math] APT format for the users guide

Hi Phil, 2012/9/20 Phil Steitz : > On 9/20/12 12:01 PM, Sébastien Brisard wrote: >> Hello Gilles, >> >> 2012/9/20 Gilles Sadowski : >>> Hi. >>> >>>> as I previously said, I'd like to extend the user's guide for the >>

Re: [math] APT format for the users guide

g the same email, replacing every occurence of apt with TWiki. I'm experimenting, for the time being... Sébastien 2012/9/21 Sébastien Brisard : > Hi Phil, > > 2012/9/20 Phil Steitz : >> On 9/20/12 12:01 PM, Sébastien Brisard wrote: >>> Hello Gilles, >>> >>

[math] Documentation: xdoc, apt and twiki pros and cons

Hello, I've been playing around with these three formats. Here are my thoughts xdoc + already used by the existing doc, + possible to embed XHTML tags, - like all xml based languages, it is difficult to read, especially when it comes to tables. apt + increased readability, - not possibl

Re: [math] APT format for the users guide

Hi Gilles, 2012/9/21 Gilles Sadowski : > On Fri, Sep 21, 2012 at 04:14:37AM +0200, Sébastien Brisard wrote: >> Hello again, >> Gilles mentioned Wiki syntax, and I just realized that Doxia has >> built-in support for TWiki. I will give it a go, but the answer should >> p

Re: svn commit: r1388296 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear: AbstractRealMatrix.java Array2DRowRealMatrix.java BlockRealMatrix.java OpenMapRealMatrix.java

2012/9/21 Gilles Sadowski : > On Fri, Sep 21, 2012 at 01:53:29AM -, celes...@apache.org wrote: >> Author: celestin >> Date: Fri Sep 21 01:53:28 2012 >> New Revision: 1388296 >> >> URL: http://svn.apache.org/viewvc?rev=1388296&view=rev >> Log: >> In AbstractRealMatrix, removed empty abstract met

Re: svn commit: r1388296 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear: AbstractRealMatrix.java Array2DRowRealMatrix.java BlockRealMatrix.java OpenMapRealMatrix.java

Hi, 2012/9/21 Gilles Sadowski : > On Fri, Sep 21, 2012 at 12:04:36PM +0200, Sébastien Brisard wrote: >> 2012/9/21 Gilles Sadowski : >> > On Fri, Sep 21, 2012 at 01:53:29AM -, celes...@apache.org wrote: >> >> Author: celestin >> >> Date: Fri Sep 21

Re: svn commit: r1388296 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear: AbstractRealMatrix.java Array2DRowRealMatrix.java BlockRealMatrix.java OpenMapRealMatrix.java

2012/9/21 Sébastien Brisard : > Hi, > > 2012/9/21 Gilles Sadowski : >> On Fri, Sep 21, 2012 at 12:04:36PM +0200, Sébastien Brisard wrote: >>> 2012/9/21 Gilles Sadowski : >>> > On Fri, Sep 21, 2012 at 01:53:29AM -, celes...@apache.org wrote: >>> >

[math] Sparse vectors / matrices again

Hi, please have a look to MATH-870. As the only answer on the user@ ML was Phil's (who was +1), I'll start deprecating these highly problematic classes and interfaces. I would like to have your feeling about RealVector.sparseIterator() which I find highly confusing (with no benefit if we go throug

Re: [Math] About the API of the optimizers

Dear Gilles and Luc, Just a quick note to say I'm sorry not to take part in this interesting thread, but I'm not familiar enough with neither this package, nor generics. Having met with the same kind of problems recently with generics in personal applications, I'm eager to read what your decision w

[math] Validation of special functions

Hi, I have recently started to update the users guide on special functions, providing accuracy measurements of our implementations. To get these figures, I carried out extensive comparisons with reference values computed with Maxima, and 128 decimal digits. I also wrote a Java command-line app to a

Re: [math] multivariate cdf

Hi Phil, > > that might also force us to implement some useful multivariate > integration algorithms :) > Is there any, general purpose multidimensional integration algorithm? MC would be flexible enough, but I doubt this would be efficient enough... How would you define the domain? Would you rest

Re: [Math] "getDimensions" in MultivariateRealDistribution interface

Hi, 2012/10/19 Phil Steitz : > On 10/18/12 3:20 PM, Gilles Sadowski wrote: >> Hello. >> >> There is a "getDimensions" method in "AbstractMultivariateRealDistribution" >> that returns the number of variables. >> It would be useful to have this method declared in the interface too. > +1 > > I might

Re: [math] Validation of special functions

Hi Phil, thanks for your answer. 2012/10/19 Phil Steitz : > On 10/18/12 11:13 PM, Sébastien Brisard wrote: >> Hi, >> I have recently started to update the users guide on special >> functions, providing accuracy measurements of our implementations. >> To get these figur

Re: [math] multivariate cdf

Hi Phil, 2012/10/19 Phil Steitz : > On 10/19/12 12:20 AM, Sébastien Brisard wrote: >> Hi Phil, >> >>> that might also force us to implement some useful multivariate >>> integration algorithms :) >>> >> Is there any, general purpose multidimensiona

Re: [math] correlation analysis with NaNs

Hi, 2012/11/8 Gilles Sadowski : > On Thu, Nov 08, 2012 at 09:39:00AM +0100, Thomas Neidhart wrote: >> Hi Patrick, >> >> On 11/07/2012 04:37 PM, Patrick Meyer wrote: >> > I agree that it would be nice to have a constructor that allows you to >> > specific the ranking algorithm only. >> > >> > As fa

[math] Evaluation of the accuracy of special functions

E.txt. Please review, and let me know if that is clear enough. Best regards, Sébastien Brisard [1] http://markmail.org/thread/f7jbf5hh4vnnvagn [2] I'm not sure it's the best place for this app.

  1   2   3   4   5   6   >