On 31 August 2012 16:51, Sébastien Brisard wrote:
> 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 Revision: 1379
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 Revision: 1379270
URL: http://svn.apache.org/viewvc?rev=1379270&view=
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 Revision: 1379270
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1379270&view=rev
>>> Log:
>>> MATH-849: changed boun
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
On 31 August 2012 13:49, Gilles Sadowski wrote:
> 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).
>>
>
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).
>
> Modified:
>
> commons/proper/math/trunk/src/main/jav
Le 24/08/2012 03:29, Becksfort, Jared a écrit :
>>> [...]
>>>
>>> Think about it from the standpoint of a new contributor. How
>>> long does it take to prepare and get a patch committed for a) the
>>> new contributor and b) the committer who ends up applying the
>>> patch. More rules means more t
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
> > [...]
>>
>> Think about it from the standpoint of a new contributor. How long
>> does it take to prepare and get a patch committed for a) the new
>> contributor and b) the committer who ends up applying the patch.
>> More rules means more time. It is that simple. Either the new
>> contributo
It's also important that the diff can be applied. The less consistent the
formatting is, the less likely that patch will succeed.
chas
On 8/23/12 4:11 PM, "Phil Steitz" wrote:
>On 8/23/12 4:02 PM, Gilles Sadowski wrote:
>> On Thu, Aug 23, 2012 at 02:15:58PM -0700, Phil Steitz wrote:
>>> On 8/2
> > [...]
>
> Think about it from the standpoint of a new contributor. How long
> does it take to prepare and get a patch committed for a) the new
> contributor and b) the committer who ends up applying the patch.
> More rules means more time. It is that simple. Either the new
> contributor ha
On 8/23/12 4:02 PM, Gilles Sadowski wrote:
> On Thu, Aug 23, 2012 at 02:15:58PM -0700, Phil Steitz wrote:
>> On 8/23/12 3:39 AM, Sébastien Brisard wrote:
>>> 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 sid
On Thu, Aug 23, 2012 at 02:15:58PM -0700, Phil Steitz wrote:
> On 8/23/12 3:39 AM, Sébastien Brisard wrote:
> > 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
On 8/23/12 3:39 AM, Sébastien Brisard wrote:
> 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
On 23 August 2012 12:52, Gilles Sadowski wrote:
> On Thu, Aug 23, 2012 at 01:25:42PM +0200, Thomas Neidhart wrote:
>> On Thu, Aug 23, 2012 at 1:16 PM, Sébastien Brisard <
>> sebastien.bris...@m4x.org> wrote:
>>
>> > Hi,
>> >
>> > >
>> > > Probably easiest to use the Wiki for this, at least initial
On Thu, Aug 23, 2012 at 01:25:42PM +0200, Thomas Neidhart wrote:
> On Thu, Aug 23, 2012 at 1:16 PM, Sébastien Brisard <
> sebastien.bris...@m4x.org> wrote:
>
> > Hi,
> >
> > >
> > > Probably easiest to use the Wiki for this, at least initially.
> > >
> > I'm not very fond of the Wiki: maybe I coul
Le 23/08/2012 13:25, Thomas Neidhart a écrit :
> On Thu, Aug 23, 2012 at 1:16 PM, Sébastien Brisard <
> sebastien.bris...@m4x.org> wrote:
>
>> 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,
On Thu, Aug 23, 2012 at 1:16 PM, Sébastien Brisard <
sebastien.bris...@m4x.org> wrote:
> 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
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
On 23 August 2012 11:39, Sébastien Brisard wrote:
> 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
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
On Thu, Nov 25, 2010 at 6:52 AM, wrote:
> On a linux computer in an UTF8 environment and using Java 5, I get the
> following messages in English and in French:
>
> Continued fraction diverged to NaN for value ∞
> Divergence de fraction continue à NaN pour la valeur ∞
>
> I don't know if it will b
On a linux computer in an UTF8 environment and using Java 5, I get the
following messages in English and in French:
Continued fraction diverged to NaN for value ∞
Divergence de fraction continue à NaN pour la valeur ∞
I don't know if it will be visible through mail, but the last component of bot
Researching MATH-414, I am seeing this stacktrace:
org.apache.commons.math.ConvergenceException: Continued fraction diverged to
NaN for value ?
at
org.apache.commons.math.util.ContinuedFraction.evaluate(ContinuedFraction.java:186)
The "?" should represent positive infinity (the actual paramet
Brent Worden a écrit :
> The getInstance() method can not return a sole instance because the
> default locale can change via java.util.Locale#setDefault
>
> The purpose of the format setters is to provide similar behavior as
> found on java.text.NumberFormat with the ability to modify formatting
>
The getInstance() method can not return a sole instance because the
default locale can change via java.util.Locale#setDefault
The purpose of the format setters is to provide similar behavior as
found on java.text.NumberFormat with the ability to modify formatting
parameters. They provide a conven
Luc Maisonobe wrote:
Hello,
I am writing a new Vector3DFormat class in the spirit of the
ComplexFormat class for input/output.
Since some parts are common (parsing one component, handling locales), I
have extracted a CompositeFormat base class from ComplexFormat and will
use it as the base clas
Partially answering to myself ...
Luc Maisonobe a écrit :
> Hello,
>
> I am writing a new Vector3DFormat class in the spirit of the
> ComplexFormat class for input/output.
>
> Since some parts are common (parsing one component, handling locales), I
> have extracted a CompositeFormat base class f
Hello,
I am writing a new Vector3DFormat class in the spirit of the
ComplexFormat class for input/output.
Since some parts are common (parsing one component, handling locales), I
have extracted a CompositeFormat base class from ComplexFormat and will
use it as the base class for Vector3D and perh
29 matches
Mail list logo
