To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-collections4 has an issue affecting its community integration.
Thi
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
Salut Luc!!!
I have to admit my ignorance respect the "export regulations in the
US", that's completely new to me, thanks for notifying!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Jan 2, 2011 at 8:59 PM, Luc Maisonobe wrote:
> Le 02/01/2011 20:52, Simone Tripo
Ok. That makes sense.
Sent from my iPhone
On Jan 2, 2011, at 9:26 PM, Phil Steitz wrote:
> On Sun, Jan 2, 2011 at 11:46 PM, Ted Dunning wrote:
>
>> On Sun, Jan 2, 2011 at 2:05 PM, Phil Steitz wrote:
>>
>>> We don't precisely define what we mean by the support of a distribution
>>> anywhere
On Sun, Jan 2, 2011 at 11:46 PM, Ted Dunning wrote:
> On Sun, Jan 2, 2011 at 2:05 PM, Phil Steitz wrote:
>
> > We don't precisely define what we mean by the support of a distribution
> > anywhere. I have been assuming that we mean the smallest closed set such
> > that its complement has probabi
On Sun, Jan 2, 2011 at 2:05 PM, Phil Steitz wrote:
> We don't precisely define what we mean by the support of a distribution
> anywhere. I have been assuming that we mean the smallest closed set such
> that its complement has probability 0.
Why closed?
Why not just the smallest set such that
On Sun, Jan 2, 2011 at 5:50 PM, Luc Maisonobe wrote:
> Le 02/01/2011 21:09, Luc Maisonobe a écrit :
> > Hi Phil,
> >
> > Le 02/01/2011 19:01, Phil Steitz a écrit :
> >> The clirr report run from the current MATH_2_X branch is, as expected,
> >> problematic. To get 2.2. out, we need to agree on w
Le 02/01/2011 21:09, Luc Maisonobe a écrit :
> Hi Phil,
>
> Le 02/01/2011 19:01, Phil Steitz a écrit :
>> The clirr report run from the current MATH_2_X branch is, as expected,
>> problematic. To get 2.2. out, we need to agree on what breaks we are going
>> to allow and what we are going to fix.
We don't precisely define what we mean by the support of a distribution
anywhere. I have been assuming that we mean the smallest closed set such
that its complement has probability 0. This would make, for example, the
support of the Beta distribution [0, 1] independent of the parameters. But
the
Hi Phil,
Le 02/01/2011 19:01, Phil Steitz a écrit :
> The clirr report run from the current MATH_2_X branch is, as expected,
> problematic. To get 2.2. out, we need to agree on what breaks we are going
> to allow and what we are going to fix. Here is a first cut and proposal
> for some immediat
Le 02/01/2011 20:52, Simone Tripodi a écrit :
> Hi all guys,
> I'm a big fan of how Maven manages passwords (en|de)cription[1] and
> found the algorithm implementation[2] on Sonatype's repo.
> Since the code is released under AFL2.0, what about including this
> algorithm in codec component?
> I can
Hi all guys,
I'm a big fan of how Maven manages passwords (en|de)cription[1] and
found the algorithm implementation[2] on Sonatype's repo.
Since the code is released under AFL2.0, what about including this
algorithm in codec component?
I can provide an implementation but Cipher interface is quite
d
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. functions to an interface? As far as I know, the
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. functions to an interface? As far as I know, the binaries are
> still compatibl
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
The clirr report run from the current MATH_2_X branch is, as expected,
problematic. To get 2.2. out, we need to agree on what breaks we are going
to allow and what we are going to fix. Here is a first cut and proposal
for some immediate fixes that I would appreciate feedback on.
0) The improve
Agreed. If we move to a new Doclet, it should at least support Javadoc's
standard tags. It's a non-starter otherwise IMO.
Gary
> -Original Message-
> From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of
> Simone Tripodi
> Sent: Sunday, January 02, 2011 10:35
> To
Hi Sebb,
the reason you explained are enough to justify to keep Doclava out for
the moment, I'll ping the core developers and convince them to support
standard javadoc tags :)
Thanks for the feedback!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Jan 2, 2011 at
On 2 January 2011 12:19, Simone Tripodi wrote:
> Hi all Commons developers,
> and happy new year!!! :)
>
> I recently joined the Google Doclava[1] team and helped them deploying
> it on the Maven Central repo, so I'd like to propose the adoption of
> this Doclet in the parent pom.
> For those don'
Hi all Commons developers,
and happy new year!!! :)
I recently joined the Google Doclava[1] team and helped them deploying
it on the Maven Central repo, so I'd like to propose the adoption of
this Doclet in the parent pom.
For those don't know Google Doclava, it is the Google Android doclet,
made
20 matches
Mail list logo
