Large does not necessarily mean sparse. And please note that iterative
linear solvers was I think a big step towards large scale problems.
Of course, you are very welcome to contribute a robust implementation for
sparse matrices. The reason why we dropped it (momentarily, hopefully) was
that the c
Hello,
2013/2/6 Konstantin Berlin
> >
> > As for efficiency (or faster execution, if you want), I don't see the
> > point in doubting that tasks like global search (e.g. in a genetic
> > algorithm) will complete in less time when run in parallel...
>
>
> Just a quick note. This statement is inc
Hello,
2013/2/1 Thomas Neidhart
> Hi Guys,
>
> thanks for your feedback, much appreciated!
>
> Thomas
>
> On Thu, Jan 31, 2013 at 9:17 PM, Thomas Neidhart
> wrote:
>
> > Hi,
> >
> > Gilles and myself will give a presentation on CM at FOSDEM this weekend
> > and we would like to have a few more
Hi Konstantin,
2013/1/1 Konstantin Berlin
> Here are my 2 cents:
>
> The rationale for redesign of the RealMatrix hierarchy is because a large
> amount of numerical packages depend (or should depend) on a linear algebra
> package for efficient implementation. However, as it currently stands, it
Hi Gilles,
2013/1/1 Gilles Sadowski
> Hi.
>
> > > If we stick to
> > >
> > > 0) algebraic objects are immutable
> > > 1) algorithms defined using algebraic concepts should be implemented
> > > using algebraic objects
> > >
> > > ...
> > > 0) Start, with Konstantin's help, by fleshing out the I
Hello,
2012/12/31 Phil Steitz
> If we stick to
>
> 0) algebraic objects are immutable
> 1) algorithms defined using algebraic concepts should be implemented
> using algebraic objects
>
> we end up having to create lots of algebraic objects and copy lots
> of data, which creates memory and perfor
Hello,
Using the visitor pattern as a way to implement in-place basic linear
algebra operations was only a suggestion, I am not sure it's the best
option, even if I do think it's a simple and elegant option. However...
I think we might have a misunderstanding. What I am discussing is not the
> g
Hi Mark,
2012/12/29 Mark Struberg
> or just move it to a profile?
> In our project we have this enabled via
>
> $> mvn clean instal -Pcoverage
>
> LieGrue,
> strub
>
> We've been trying to do that unsuccessfully in Commons Math. What project
are you talking about? We could look at the pom.
Than
Hello,
2012/12/28 Konstantin Berlin
> >
> > That's what I was going to write. At the moment, the current
> implementation
> > for sparse matrices and vector is deprecated, for lack of convincing
> fixes
> > for the bugs which have been found. These bugs are mainly related to the
> > fact that z
Hi,
2012/12/29 Gilles Sadowski
> Hi.
>
> > [...]
>
> > > third is just bug-fix. Does the fix for the issue that started this
> > > thread change the API? If so, we would need to cut 3.2 in any case.
>
> The current fix does change the usage (one needs to call optimize with an
> argument of a
Hello,
2012/12/28 Luc Maisonobe
> Le 28/12/2012 17:51, Konstantin Berlin a écrit :
> > Hi,
> >
> > I can understand Dimitri's frustration, it seems the optimization
> > framework gets worse with every iteration. However, we should
> > probably look forward and think about how to design it prope
2012/12/20 Gilles Sadowski
> Hi.
>
> Please have a look at the next candidate (RC5), and vote for the release
> of Commons Math 3.1.
>
> --
> Tag:
> https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC5/
>
> Site:
> http://people.apache.org/builds/commons/math/3.1/RC5
Hi,
2012/12/21 Olivier Lamy
> -Dcobertura.skip=true ?
> or in pom.properties
> true
>
> I agree with Phil, both options lead to strange error messages (see my
post above). Should it be considered as a bug of the cobertura plugin?
Sébastien
2012/12/21 Phil Steitz :
> > On 12/20/12 1:25 PM, Ol
Hi Luc,
2012/12/20 luc
> Le 2012-12-20 15:01, Phil Steitz a écrit :
>
> On 12/19/12 6:19 PM, Gilles Sadowski wrote:
>>
>>> Hello.
>>>
>>
> Hi all,
>
>
>
>>> The situation with "Cobertura" is fairly annoying, perhaps particularly
>>> so
>>> for Commons Math because of the size of the code base
Hi
2012/12/20 Gilles Sadowski
> On Thu, Dec 20, 2012 at 08:26:54AM +0100, Sébastien Brisard wrote:
> > Hi Gilles,
> >
> > I cannot reproduce these failures either. Here is my config
> > Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> > Java version:
Hi Gilles,
2012/12/20 Gilles Sadowski
> Hello.
>
> The situation with "Cobertura" is fairly annoying, perhaps particularly so
> for Commons Math because of the size of the code base (and thus the fairly
> large number of unit tests).
>
> As it just happened, a few minor problems have now delaye
Hi Gilles,
I cannot reproduce these failures either. Here is my config
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.7.0_05
Java home: /usr/java/jdk1.7.0_05/jre
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux" version: "3.6.9-2.fc17.x86_64" arch: "amd64" Fa
Hi,
2012/12/2 sebb
> On 2 December 2012 09:58, Sébastien Brisard
> wrote:
> > Hi
> >
> >
> > 2012/12/1 Gilles Sadowski
> >
> >> On Sat, Dec 01, 2012 at 09:39:04PM +, sebb wrote:
> >> > On 30 November 2012 11:43, Luc Maisonobe
Hi,
2012/12/2 Ted Dunning
> Google has a nice @ExposedForTesting annotation that they use for this.
>
> There are numerous instances in guava where otherwise private methods are
> exposed to the test suite for testing. It makes a lot of sense, and there
> are no questions to anybody looking at
Hi
2012/12/1 Gilles Sadowski
> On Sat, Dec 01, 2012 at 09:39:04PM +, sebb wrote:
> > On 30 November 2012 11:43, Luc Maisonobe wrote:
> > > Le 30/11/2012 09:19, Thomas Neidhart a écrit :
> > >> On Fri, Nov 30, 2012 at 8:06 AM, Sébastien Brisard <
> &
Hi,
2012/12/1 Konstantin Berlin
> Hi,
>
> Now that I have some time, let me try to make my case clearly. First I
> want to say that this is not some attack on the automatic-differentation
> package. I love automatic-differentation and symbolic packages. I
> personally cannot compute a derivativ
Hi,
I've already posted the same question in another thread [1], but I thought
having a dedicated thread would increase its visibility.
Here is my problem. The new implementation of Beta.logBeta(double, double)
I'm currently working on relies on several private methods through a rather
complex bra
Hi,
2012/11/27 Gilles Sadowski
> Hello.
>
> > > [...]
> > Actually, I would like the methods to be tested, so they cannot be
> > private. That's the reason why I made them package private.
>
> You can indirectly test them by passing appropriate arguments to the public
> methods that use them. P
Hi,
2012/11/28 Gilles Sadowski
> Hi.
>
> >
> > > I thought that you were almost finished with the "Beta" function.
> > > How much time would you need to resolve the issue?
> > >
> > > I thought so too. The code is written, but I've noticed that a few
> changes
> > must be done. And I have to de
Hi Gilles,
> I thought that you were almost finished with the "Beta" function.
> How much time would you need to resolve the issue?
>
> I thought so too. The code is written, but I've noticed that a few changes
must be done. And I have to decide what is the best place for all these
auxiliary f
Hello,
2012/11/28 Sébastien Brisard
> Hi,
>
>
> 2012/11/28 Phil Steitz
>
>> On 11/27/12 3:43 PM, er...@apache.org wrote:
>> > Author: erans
>> > Date: Tue Nov 27 23:43:06 2012
>> > New Revision: 1414470
>> >
>> > URL: http://
Hi,
2012/11/28 Phil Steitz
> On 11/27/12 3:43 PM, er...@apache.org wrote:
> > Author: erans
> > Date: Tue Nov 27 23:43:06 2012
> > New Revision: 1414470
> >
> > URL: http://svn.apache.org/viewvc?rev=1414470&view=rev
> > Log:
> > Contents for the release notes.
> >
> > Modified:
> > commons/
Hello,
2012/11/28 Phil Steitz
> On 11/27/12 1:24 PM, Thomas Neidhart wrote:
> > On 11/27/2012 04:30 PM, Gilles Sadowski wrote:
> >> Hello.
> >>
> >> Quoting from the previous thread about this subject:
> >>> As far as I am concerned, 3.1 could be released anytime now.
> >> [Luc Maisonobe, Septe
Hi Gilles,
2012/11/27 Gilles Sadowski
> Hi.
>
> > > [...]
> > > >
> > > > Is "ebeDivide" a (mathematical) "vector" operation?
> > > > IMHO, it's an operation on 2 lists of values.
> > > >
> > >
> > I agree, but it's still useful to have it on vectors... But I'm happy
> with
> > map.
>
> Sorry,
Hi Gilles,
2012/11/27 Sébastien Brisard
> Hi Gilles,
>
>
>
> 2012/11/27 Gilles Sadowski
>
>> On Tue, Nov 27, 2012 at 12:33:40PM +0100, Gilles Sadowski wrote:
>> > On Tue, Nov 27, 2012 at 04:44:27AM +0100, Sébastien Brisard wrote:
>> > > Hi,
&g
Hi Gilles,
2012/11/27 Gilles Sadowski
> On Tue, Nov 27, 2012 at 12:33:40PM +0100, Gilles Sadowski wrote:
> > On Tue, Nov 27, 2012 at 04:44:27AM +0100, Sébastien Brisard wrote:
> > > Hi,
> > >
> > >
> > > 2012/11/27 Gilles Sadowski
> > >
&
Hi,
2012/11/27 Gilles Sadowski
> On Tue, Nov 27, 2012 at 07:22:26AM -0800, Phil Steitz wrote:
> > On 11/27/12 6:42 AM, Gilles Sadowski wrote:
> > > On Tue, Nov 27, 2012 at 06:24:26AM -0800, Ted Dunning wrote:
> > >> Actually, I would still recommend checks. You may know what the code
> does
>
Hi,
2012/11/27 Gilles Sadowski
> Hello.
>
> > > > in MATH-803 [1] it was decided to deprecate
> > > RealVector.ebeMultiply/Divide,
> > > > because these methods were difficult to support with sparse vectors.
> > > > However, in MATH-870, we decided to deprecate sparse vectors
> altogether.
> >
Hi,
2012/11/26 Gilles Sadowski
> Hi.
>
> > in classes Gamma and Beta, some functions are package private:
> > - logGammaSum
> > - logGammaMinusLogGammaSum (for lack of a better name)
> > - bcorr
> > These functions are meant to be used by other functions,
>
> None of these functions seem
Hi,
in classes Gamma and Beta, some functions are package private:
- logGammaSum
- logGammaMinusLogGammaSum (for lack of a better name)
- bcorr
These functions are meant to be used by other functions, like logBeta. Each
of these functions have their own domain, and in logBeta, we make sure no
Hi,
2012/11/26 Gilles Sadowski
> On Sun, Nov 25, 2012 at 06:00:06PM +0100, Sébastien Brisard wrote:
> > Hi,
> > in MATH-803 [1] it was decided to deprecate
> RealVector.ebeMultiply/Divide,
> > because these methods were difficult to support with sparse vectors.
>
Hi,
2012/11/26 Gilles Sadowski
> Hi.
>
> > [...]
> > + * This library is "approved for public release", and the
> > + * http://www.dtic.mil/dtic/pdf/announcements/CopyrightGuidance.pdf";>Copyright
> guidance
> > + * indicates that unless otherwise stated in the code, all FORTRAN
> functions in
Hi,
in MATH-803 [1] it was decided to deprecate RealVector.ebeMultiply/Divide,
because these methods were difficult to support with sparse vectors.
However, in MATH-870, we decided to deprecate sparse vectors altogether.
I'm therefore having second thoughts on MATH-803. Since the problematic
imple
Phil,
if you can reproduce MATH-907 on your machine, can you check the fix I
proposed?
Many thanks!
Sébastien
2012/11/23 Phil Steitz
> On 11/23/12 9:51 AM, Gilles Sadowski wrote:
> > Hi.
> >
> > Issue MATH-907 seems to imply that the "build.xml" needed to compile
> Commons
> > Math with "ant" i
Hi,
2012/11/19 Phil Steitz
> On 11/18/12 11:20 PM, Sébastien Brisard wrote:
> > Hi,
> > someone (I think it was sebb) wrote some months ago about defining custom
> > profiles in the pom.xml to allow for faster compilation (cobertura being
> > the culprit).
> >
Hi,
2012/11/19 Gilles Sadowski
> On Mon, Nov 19, 2012 at 10:38:27AM +0100, Thomas Neidhart wrote:
> > On Mon, Nov 19, 2012 at 8:20 AM, Sébastien Brisard <
> > sebastien.bris...@m4x.org> wrote:
> >
> > > Hi,
> > > someone (I think it was sebb)
Hi,
someone (I think it was sebb) wrote some months ago about defining custom
profiles in the pom.xml to allow for faster compilation (cobertura being
the culprit).
I've done that locally, and I'm probably not the only one. So I was
wondering whether we could commit one or two custom profiles which
Hi,
2012/11/18 Gilles Sadowski
> On Sun, Nov 18, 2012 at 11:19:14AM +0100, Luc Maisonobe wrote:
> > Le 18/11/2012 10:53, Sébastien Brisard a écrit :
> > > Hi,
> >
> > Hi all,
> >
> > >
> > >
> > > 2012/11/17 Gilles Sadowski
>
Hi,
2012/11/17 Gilles Sadowski
> On Sat, Nov 17, 2012 at 12:34:30PM -0800, Phil Steitz wrote:
> > I think MATH-902 makes a reasonable request, but I don't think the
> > exception is the right place to communicate last iteration data.
> > When iterative algorithms fail to converge and TooManyEva
Hi Gilles,
2012/11/17 Gilles Sadowski
> On Fri, Nov 16, 2012 at 08:09:13PM +0100, Sébastien Brisard wrote:
> > Hi,
> >
> > 2012/11/16 Gilles Sadowski
> >
> > > Hi.
> > >
> > > > I think I've spotted the reason why the j
Hi Gilles,
2012/11/16 Gilles Sadowski
> On Fri, Nov 16, 2012 at 05:27:19PM +0100, Sébastien Brisard wrote:
> > Hello,
> > As expected on such hot issues, it's difficult to arrive at a consensus
> > among committers. However, I think that this ticket might be usefu
Hi,
2012/11/16 Gilles Sadowski
> Hi.
>
> > I think I've spotted the reason why the javadoc does not come out right
> > with UTF-8 characters.
> > Our pom.xml defines the following properties
> > UTF-8
> >
> >
> UTF-8
> > which should produce the correct result if the default configuration of
Copy/paste of a previous message missing the [math] tag.
Hello,
I think I've spotted the reason why the javadoc does not come out right
with UTF-8 characters.
Our pom.xml defines the following properties
UTF-8
UTF-8
which should produce the correct result if the default configuration of the
Hello,
As expected on such hot issues, it's difficult to arrive at a consensus
among committers. However, I think that this ticket might be useful for
contributors (or even committers, I would be first!).
So the question is: what do we do about this ticket? Are there some more
"rules" we would like
Hello,
I think I've spotted the reason why the javadoc does not come out right
with UTF-8 characters.
Our pom.xml defines the following properties
UTF-8
UTF-8
which should produce the correct result if the default configuration of the
javadoc plugin is used [1].
However, the parent pom.xml do
HI Ted,
2012/11/14 Ted Dunning
> On Wed, Nov 14, 2012 at 12:11 AM, Sébastien Brisard <
> sebastien.bris...@m4x.org> wrote:
>
> > > There is no problem with the current setup of our website (at least,
> the
> >> website generated locally has no problem).
>
coding} which are both set to UTF-8 in our pom.
I must be missing something...
Sébastien
[1]
http://maven.apache.org/plugins/maven-javadoc-plugin/faq.html#What_are_the_values_of_encoding_docencoding_and_charset_parameters
Gary
>
> On Nov 14, 2012, at 3:31, "Sébastien Brisa
Hi again,
Correction
>
> There is no problem with the current setup of our website (at least, the
> website generated locally has no problem).
>
> I was sure of the contrary, but it turns out that the generated Javadoc
does not display UTF-8 characters correctly, although the following
propertie
Hello Luc,
2012/11/14 Luc Maisonobe
> Le 14/11/2012 07:53, Sébastien Brisard a écrit :
> > Hi,
>
> Hi Sébastien,
>
> > since the pom specifies the encoding of our source files as well as the
> > generated HTML files of the Javadoc, it occured to me that it is possib
Hi,
since the pom specifies the encoding of our source files as well as the
generated HTML files of the Javadoc, it occured to me that it is possible
to use UTF-8 characters in the Javadoc comments.
I think using Γ instead of Γ, or ≤ instead of ≤ increases
readability of the source files. However,
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.
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
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
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
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
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
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
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
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
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:
>>> >
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
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
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
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
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,
>>>
>>
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
>>
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
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
>>
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
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
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.
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
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
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
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
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
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
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
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
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
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
>>>
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
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
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
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
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
>
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
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 [..
> [...]
> 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
>> >> } catch (final MathArithmeticException e) {
>> >> -throw new
>> >> MathArithmeticException(LocalizedFormats.ENTRY, i);
>> >> +throw new
>> >> MathArithmeticException(LocalizedFormats.INDEX, i);
>> >> }
>> >> }
>> >
>> > Do w
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,
>> >>
>
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
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?
&
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
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
>>
1 - 100 of 574 matches
Mail list logo
