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-io-test has an issue affecting its community integration.
This iss
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-scxml-test has an issue affecting its community integration.
This
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-proxy-test has an issue affecting its community integration.
This
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-javaflow has an issue affecting its community integration.
This is
On 9/17/10 3:19 PM, Luc Maisonobe wrote:
Le 17/09/2010 19:55, Ted Dunning a écrit :
There are also on-line percentile estimation methods that require only a
single pass over the data in order to get good estimates of several quantile
at the same time.
If you are interested in getting an estimat
Le 18/09/2010 16:16, Phil Steitz a écrit :
> On 9/17/10 3:19 PM, Luc Maisonobe wrote:
>> Le 17/09/2010 19:55, Ted Dunning a écrit :
>>> There are also on-line percentile estimation methods that require only a
>>> single pass over the data in order to get good estimates of several
>>> quantile
>>> a
On 9/18/10 10:24 AM, Luc Maisonobe wrote:
Le 18/09/2010 16:16, Phil Steitz a écrit :
On 9/17/10 3:19 PM, Luc Maisonobe wrote:
Le 17/09/2010 19:55, Ted Dunning a écrit :
There are also on-line percentile estimation methods that require only a
single pass over the data in order to get good estim
Le 18/09/2010 17:36, Phil Steitz a écrit :
> On 9/18/10 10:24 AM, Luc Maisonobe wrote:
>> Le 18/09/2010 16:16, Phil Steitz a écrit :
>>> On 9/17/10 3:19 PM, Luc Maisonobe wrote:
Le 17/09/2010 19:55, Ted Dunning a écrit :
> There are also on-line percentile estimation methods that require
>
Le 18/09/2010 17:39, Luc Maisonobe a écrit :
> Le 18/09/2010 17:36, Phil Steitz a écrit :
>> On 9/18/10 10:24 AM, Luc Maisonobe wrote:
>>> Le 18/09/2010 16:16, Phil Steitz a écrit :
On 9/17/10 3:19 PM, Luc Maisonobe wrote:
> Le 17/09/2010 19:55, Ted Dunning a écrit :
>> There are also
Hi list,
I've been looking at this fail method on DaemonController and it looks
like it is for giving a slightly friendlier error message back to the
console, rather than a stack trace. I was hoping I could use this to
report error messages during initialisation, but it looks like that is
not the
Hi,
If I understand correctly, the argument against the present implementation
is that if several percentiles are requested, they all require the sorting
of the array. On the other hand, the speed-up version would no longer
be mathematically correct, as a rough approximate of the pivot would be
Le 18/09/2010 20:01, Dimitri Pourbaix a écrit :
> Hi,
>
> If I understand correctly, the argument against the present implementation
> is that if several percentiles are requested, they all require the sorting
> of the array.
Yes.
> On the other hand, the speed-up version would no longer
> be ma
Luc,
On the other hand, the speed-up version would no longer
be mathematically correct, as a rough approximate of the pivot would be
adopted.
No, the exact pivot is used. Its evaluation is only delayed. It would be
correct.
Given a **general** array, I do not think one can identify the media
Le 18/09/2010 20:43, Dimitri Pourbaix a écrit :
> Luc,
>
>>> On the other hand, the speed-up version would no longer
>>> be mathematically correct, as a rough approximate of the pivot would be
>>> adopted.
>>
>> No, the exact pivot is used. Its evaluation is only delayed. It would be
>> correct.
>
O(n), not n
Expected case is n + n/2 + n/4 ... < 2n
On Sat, Sep 18, 2010 at 12:05 PM, Luc Maisonobe wrote:
> Le 18/09/2010 20:43, Dimitri Pourbaix a écrit :
> > Luc,
> >
> >>> On the other hand, the speed-up version would no longer
> >>> be mathematically correct, as a rough approximate of the p
Dear wiki user,
You have subscribed to a wiki page "Commons Wiki" for change notification.
The page FrontPage has been reverted to revision 100 by DennisLundberg.
The comment on this change is: Revert SPAM.
http://wiki.apache.org/jakarta-commons/FrontPage?action=diff&rev1=101&rev2=102
--
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
Ted,
O(n), not n
Expected case is n + n/2 + n/4 ... < 2n
Yes, that I am already more incline to buy.
Dim.
Dimitri Pourbaix *
Institut d'Astronomie et d'Astrophysique * Don't worry, be ha
18 matches
Mail list logo
