[g...@vmgump]: Project commons-digester (in module apache-commons) failed

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-digester has an issue affecting its community integration. This is

[g...@vmgump]: Project commons-io-test (in module apache-commons) failed

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

[g...@vmgump]: Project commons-scxml-test (in module apache-commons) failed

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

[g...@vmgump]: Project commons-proxy-test (in module apache-commons) failed

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

[g...@vmgump]: Project commons-javaflow (in module commons-sandbox) failed

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

Re: [infra] site deploying

On 26 September 2010 06:30, Rahul Akolkar wrote: > On Sat, Sep 25, 2010 at 12:59 PM, Simone Tripodi > wrote: >> Thanks both Antonio and Phil :) >> >> @Phil: absolutely right, but that concerns the main site, what I was >> worried about is the 2.1 specific release site. I already deployed the >> 2

Re: [math] speeding up percentile based statistics

Le 23/09/2010 20:57, Luc Maisonobe a écrit : > Hi, > > Resuming this thread, as I will be soon able to work on this (I hope). > I propose to start by solving > using a simple > partition-based selection algorithm and preserving pivot information. >

Re: [math] speeding up percentile based statistics

Hi, Why not simply make 3) the default, but also supply a *IMSureWhatIMDoing-method only implementing 2) (it is so cheap that we might as well do it instead of not doing any check at all). This means that users who read the documentation can gain something when they explicitly ask for it, while us

Re: [math] speeding up percentile based statistics

I was about to write this suggestion down. Instead, I will simply concur. +1 The safe version can do the checksum or make a copy. Either is safe and the costs are similar (O(n) on every call and no memory or O(1) on every call after the first, O(n) memory). I would tend toward the copy option.

Re: [math] speeding up percentile based statistics

Le 26/09/2010 18:21, Ted Dunning a écrit : > I was about to write this suggestion down. > > Instead, I will simply concur. > > +1 > > The safe version can do the checksum or make a copy. Either is safe and the > costs are similar (O(n) on every call and no memory or O(1) on every call > after t

Re: [math] speeding up percentile based statistics

I don't see any season for computing hash value if pointers don't match. Den 2010 9 26 18:52 skrev "Luc Maisonobe" : > Le 26/09/2010 18:21, Ted Dunning a écrit : >> I was about to write this suggestion down. >> >> Instead, I will simply concur. >> >> +1 >> >> The safe version can do the checksum or

Re: [math] speeding up percentile based statistics

Le 26/09/2010 18:55, Mikkel Meyer Andersen a écrit : > I don't see any season for computing hash value if pointers don't match. If pointers don't match, the two arrays are obviously different, but wen still need to compute the hash to cache it for the check on next call. Luc > Den 2010 9 26 18:5

Re: [math] speeding up percentile based statistics

> [...] > > 1) do nothing to check the array is the same between calls and blindly > assumes it IS the same. Users would really need to call clearCache > when they provide a new array > pros: very simple > cons: error-prone for the user as it relies only on reading and > under

Re: [math] speeding up percentile based statistics

2010/9/26 Gilles Sadowski : >> [...] >> >>  1) do nothing to check the array is the same between calls and blindly >>     assumes it IS the same. Users would really need to call clearCache >>     when they provide a new array >>     pros: very simple >>     cons: error-prone for the user as it reli

Re: [math] speeding up percentile based statistics

On 9/26/10 12:51 PM, Luc Maisonobe wrote: Le 26/09/2010 18:21, Ted Dunning a écrit : I was about to write this suggestion down. Instead, I will simply concur. +1 The safe version can do the checksum or make a copy. Either is safe and the costs are similar (O(n) on every call and no memory or

Re: [math] speeding up percentile based statistics

Le 26/09/2010 19:27, Mikkel Meyer Andersen a écrit : > 2010/9/26 Gilles Sadowski : >>> [...] >>> >>> 1) do nothing to check the array is the same between calls and blindly >>> assumes it IS the same. Users would really need to call clearCache >>> when they provide a new array >>> pros:

Re: [math] speeding up percentile based statistics

On 9/26/10 1:27 PM, Mikkel Meyer Andersen wrote: 2010/9/26 Gilles Sadowski: [...] 1) do nothing to check the array is the same between calls and blindly assumes it IS the same. Users would really need to call clearCache when they provide a new array pros: very simple cons:

Re: [math] speeding up percentile based statistics

Le 26/09/2010 20:24, Phil Steitz a écrit : > On 9/26/10 12:51 PM, Luc Maisonobe wrote: >> Le 26/09/2010 18:21, Ted Dunning a écrit : >>> I was about to write this suggestion down. >>> >>> Instead, I will simply concur. >>> >>> +1 >>> >>> The safe version can do the checksum or make a copy. Either

Re: [math] speeding up percentile based statistics

On 9/26/10 2:30 PM, Luc Maisonobe wrote: Le 26/09/2010 19:27, Mikkel Meyer Andersen a écrit : 2010/9/26 Gilles Sadowski: [...] 1) do nothing to check the array is the same between calls and blindly assumes it IS the same. Users would really need to call clearCache when they provide

Re: [math] speeding up percentile based statistics

Le 26/09/2010 21:05, Phil Steitz a écrit : > On 9/26/10 2:30 PM, Luc Maisonobe wrote: >> Le 26/09/2010 19:27, Mikkel Meyer Andersen a écrit : >>> 2010/9/26 Gilles Sadowski: > [...] > > 1) do nothing to check the array is the same between calls and > blindly > assumes it I

Re: [math] speeding up percentile based statistics

> [...] > >> > >> ---CUT--- > >>double[] a = new double[] {1, 2, 3}; > >>double[] b = new double[] {1, 2, 3, 4, 5}; > >>Percentile pA = new Percentile(a); > >>Percentile pB = new Percentile(b); > >> > >>double r; > >>r = pA.evaluate(50); > >>r = pB.evaluate(50); > >>

Re: [infra] site deploying

On Sun, Sep 26, 2010 at 7:54 AM, sebb wrote: > On 26 September 2010 06:30, Rahul Akolkar wrote: >> On Sat, Sep 25, 2010 at 12:59 PM, Simone Tripodi >> wrote: >>> Thanks both Antonio and Phil :) >>> >>> @Phil: absolutely right, but that concerns the main site, what I was >>> worried about is the