[cross-posted to: ci.stat.math]

Malcolm McLean:

> We have a continuously growing buffer, and we want the
> best strategy for reallocations as the stream of
> characters comes at us. So, given we now how many
> characters have arrived, can we predict how many will
> arrive,

Do you mean in the next bunch, or in total (till the end of
the buffer's lifetime)?

> and therefore ask for the best amount when we reallocate,
> so that we neither make too many reallocation (reallocate
> on every byte received) or ask for too much (demand
> SIZE_MAX memory when the first byte is received).?
>
> Your strategy for avoiding these extremes is exponential
> growth. You allocate a small amount for the first few
> bytes. Then you use exponential growth, with a factor of
> ether 2 or 1.5.

This strategy ensures a constant ratio between the amount of
reallocated data to the length of the buffer by making
reallocations less frequent as the buffer grows.

> And so we integrate the distribution between the point we
> are at and infinity. Then we tkae the mean. And that gives
> us a best estimate of how many bytes are to come, and
> therefore how much to grow the buffer by.

You have an apriori distribution of the buffer size (can be
tracked on-the-fly, if unknown beforehand) and a partially
filled buffer. The task is to calculate the a-posteriori
distribution of /that/ buffer's final size, and then to
allocate the predicted value based on a good percentile.

How about using a percentile instead of the mean, e.g. if
the current size corresponds to percentile p, you allocate a
capacity corresponding to percentile 1-(1-p)/k , where k>1
denotes the balance between space and time efficency. For
example, if the 60th percentile of the buffer is required
and k=2, you allocate a capacity sufficient to hold
100-(100-60)/2=80% of buffers.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev wrote:

> [cross-posted to: ci.stat.math]
>
> Malcolm McLean:
>
> > We have a continuously growing buffer, and we want the
> > best strategy for reallocations as the stream of
> > characters comes at us. So, given we now how many
> > characters have arrived, can we predict how many will
> > arrive,
>
> Do you mean in the next bunch, or in total (till the end of
> the buffer's lifetime)?
>
> > and therefore ask for the best amount when we reallocate,
> > so that we neither make too many reallocation (reallocate
> > on every byte received) or ask for too much (demand
> > SIZE_MAX memory when the first byte is received).?
> >
> > Your strategy for avoiding these extremes is exponential
> > growth. You allocate a small amount for the first few
> > bytes. Then you use exponential growth, with a factor of
> > ether 2 or 1.5.
>
> This strategy ensures a constant ratio between the amount of
> reallocated data to the length of the buffer by making
> reallocations less frequent as the buffer grows.
>
> > And so we integrate the distribution between the point we
> > are at and infinity. Then we tkae the mean. And that gives
> > us a best estimate of how many bytes are to come, and
> > therefore how much to grow the buffer by.
>
> You have an apriori distribution of the buffer size (can be
> tracked on-the-fly, if unknown beforehand) and a partially
> filled buffer. The task is to calculate the a-posteriori
> distribution of that buffer's final size, and then to
> allocate the predicted value based on a good percentile.
>
> How about using a percentile instead of the mean, e.g. if
> the current size corresponds to percentile p, you allocate a
> capacity corresponding to percentile 1-(1-p)/k , where k>1
> denotes the balance between space and time efficency. For
> example, if the 60th percentile of the buffer is required
> and k=2, you allocate a capacity sufficient to hold
> 100-(100-60)/2=80% of buffers.

Based on essentially no background to this question, not much can be
said. However, if one starts from the suggestion above to use the mean
of some distribution (or later some percentile), one notes that the
"mean" is just the minimum of a quadratic cast function ,,, so an
improvement would be to base the choice on some more realistic cost
function, chosen for the actual application. Given that the scenario
apparently involves a sequence of such decisions, the obvious extension
of the cost-based approach would be to employ some form of dynamic
programming. Of course, this might not be appealing, in which case one
might choose the theoretically-simple approach of tuning a policy based
on good stchastic simulations of the situation.

In sci.stat.math Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> [cross-posted to: ci.stat.math]
>
> Malcolm McLean:
>
>> We have a continuously growing buffer, and we want the
>> best strategy for reallocations as the stream of
>> characters comes at us. So, given we now how many
>> characters have arrived, can we predict how many will
>> arrive,
>
> Do you mean in the next bunch, or in total (till the end of
> the buffer's lifetime)?
>
Isn't this a halting problem? Aren't the more important data:
how much memory the user is allowed to allocate, the properties of
the current system's memory allocation algorithm, when your stream
will have to go to disc or other slow large volume storage, how
the stream can be compressed on the fly (the latter might well give
strong predictions for future storage requirements based on what
has been read to date).

On 19/06/2024 07:48, David Duffy wrote:
> In sci.stat.math Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
>> [cross-posted to: ci.stat.math]
>>
>> Malcolm McLean:
>>
>>> We have a continuously growing buffer, and we want the
>>> best strategy for reallocations as the stream of
>>> characters comes at us. So, given we now how many
>>> characters have arrived, can we predict how many will
>>> arrive,
>>
>> Do you mean in the next bunch, or in total (till the end of
>> the buffer's lifetime)?
>>
> Isn't this a halting problem? Aren't the more important data:
> how much memory the user is allowed to allocate, the properties of
> the current system's memory allocation algorithm, when your stream
> will have to go to disc or other slow large volume storage, how
> the stream can be compressed on the fly (the latter might well give
> strong predictions for future storage requirements based on what
> has been read to date).
>
>
No. We have to have some knowledge. And what we probaby know is that the
input is a file stored on someone's personal computer. And someone has
published on the statistical distribution of such files And they have a
log-normal distribution with a mean and a median which he gives. So with
that informaton, we can work out, given that a file is at least N
characters, what is the prbablity that an allocation of any size will
contain the whole file, and how many bytes, on average will be wasted.

Statistical analysis can't tell us what a allocation wil cost versus the
cost of hoggng memory we don't need, however. It can;t tell us what to
do. Just put us in the picture.
--
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc

Malcolm McLean writes that, given the log-normal distribution
of file sizes with known parameters,

> we can work out, given that a file is at least N
> characters, what is the prbablity that an allocation of
> any size will contain the whole file, and how many bytes,
> on average will be wasted.

This is why I thought statisticians might help him: Malcolm
wants to find the aposteriori distribution of the size of a
file, after it has been found to exceed N bytes. Am I right
that if we take the remaining (N>20) part of the density
function and re-normalise it, we shall obtain the desired
distribution?

My proposition was as follows:

1. Find quantile q0 corresponding to the buffer size
currently requested.

2. Calculate new quantile q1 = 1-(1-q0)/k, where k>1 is
an adjustable parameter, and use its corresponding
value as the new allocation size.

For example, assuming for simplicity a uniform [0,20]
distribution of file sizez and k=2, a sequence of allocation
may look like this:

requested allocated
2 20-(20- 2)/2 = 11
12 20-(20-12)/2 = 16
18 20-(20-18)/2 = 19
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> No. We have to have some knowledge. And what we probaby know is that the
> input is a file stored on someone's personal computer. And someone has
> published on the statistical distribution of such files

That's not the case that matters (to me at least). If the input is a
file, we have a much better way of "guessing" the size than guessing and
growing -- just ask for the size. Sure, we might need to make
adjustments if the file is changing, but there is always a better
measure than any statistical analysis.

To some extent this seems like a solution in search of a problem.
Growing the buffer exponentially is simple and effective.

--
Ben.

On 19/06/2024 17:36, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> No. We have to have some knowledge. And what we probaby know is that the
>> input is a file stored on someone's personal computer. And someone has
>> published on the statistical distribution of such files
>
> That's not the case that matters (to me at least). If the input is a
> file, we have a much better way of "guessing" the size than guessing and
> growing -- just ask for the size. Sure, we might need to make
> adjustments if the file is changing, but there is always a better
> measure than any statistical analysis.
>
> To some extent this seems like a solution in search of a problem.

It seems more like a solution that doesn't exist in search of a problem
with absurdly unrealistic requirements. And even if Malcolm's solution
existed, and the problem existed, it /still/ wouldn't work - knowing the
distribution of file sizes tells us nothing about the size of any given
file.

> Growing the buffer exponentially is simple and effective.
>

Yes, that's the general way to handle buffers when you don't know what
size they should be.

A better solutions for this sort of program is usually, as you say,
asking the OS for the file size (there is no standard library function
for getting the file size, but it's not hard to do for any realistic
target OS). And then for big files, prefer mmap to reading the file
into a buffer.

It's only really for unsized "files" such as piped input that you have
no way of getting the size, and then exponential growth is the way to
go. Personally, I'd start with a big size (perhaps 10 MB) that is
bigger than you are likely to need in practice, but small enough that it
is negligible on even vaguely modern computers. Then the realloc code is
unlikely to be used (but it can still be there for completeness).

David Brown <david.brown@hesbynett.no> writes:

> On 19/06/2024 17:36, Ben Bacarisse wrote:
>> Growing the buffer exponentially is simple and effective.
>
> Yes, that's the general way to handle buffers when you don't know what size
> they should be.
>
> A better solutions for this sort of program is usually, as you say, asking
> the OS for the file size (there is no standard library function for getting
> the file size, but it's not hard to do for any realistic target OS). And
> then for big files, prefer mmap to reading the file into a buffer.
>
> It's only really for unsized "files" such as piped input that you have no
> way of getting the size, and then exponential growth is the way to go.
> Personally, I'd start with a big size (perhaps 10 MB) that is bigger than
> you are likely to need in practice, but small enough that it is negligible
> on even vaguely modern computers. Then the realloc code is unlikely to be
> used (but it can still be there for completeness).

There are other uses that have nothing to do with files. I have a small
dynamic array library (just a couple of function) that I use for all
sorts of things. I can read a file or parse tokens or input a line just
by adding characters. Because of its rather general use, I don't start
with a large buffer (though the initial size can be set).

--
Ben.

Malcolm McLean:

> We have to have some knowledge. And what we probaby know
> is that the input is a file stored on someone's personal
> computer. And someone has published on the statistical
> distribution of such files And they have a log-normal
> distribution with a mean and a median which he gives. So
> with that informaton, we can work out, given that a file
> is at least N characters, what is the prbablity that an
> allocation of any size will contain the whole file, and
> how many bytes, on average will be wasted.

Observe that the standard algorithm of exponential growth is
memoryless and self-similar in that in does not depend on
context, or the history of previous reallocations. These
properties belong to (or even identify?) the exponential
distribution. We can therefore assume that exponential-
growth strategy is ideal for exponentially distributed
buffer sizes, and under that assumption determine the
relation between the CDF values (p) corresponding to
consequent re-allcoations:

p = e^x/L ,
p0 = 1-e^(L*x0) ,
p1 = 1-e^(L*x1) ,
x1 = k*x0 (by our strategy), =>
p1 = 1-(1-p0)^k .

which does not depend on the distribution and lets us
generalise this approach for any distribution:

x1 = Q( 1 - ( 1 - CDF(x0) )^k )

where:

x0 : the required size
x1 : the new recommended capacity
Q(p) : the p-Quantile of the given distribution
CDF(x): the CDF of the given distribution
k>1 : balance between speed and space efficiency

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On Mon, 17 Jun 2024 18:02:49 +0300, Anton Shepelev
<anton.txt@g{oogle}mail.com> wrote:

>[cross-posted to: ci.stat.math]
>
Anton,

The post being responded to was originally to comp.lang.c
which I don't subscribe to.

I have a question that I suppose reflects on my news source,
GigaNews, or else on my reader, Forte Agent.

Was this thread something posted 15 or 20 years ago?

I tried to call up the original post by clicking on the Message
ID when looking at headers; nothing comes up when Agent goes
online to look. The header shows multiple earlier messages;
none of them come up for me.

My clicking on Message ID works elsewhere. The logical and
simple explanation is that this is a thread old enough that
GigaNews does not have it.

I suppose that someone else might be able to tell me, if their
supplier goes back further or if GigaNews is somehow failing
to show me something that is recent.

--
Rich Ulrich

Rich Ulrich <rich.ulrich@comcast.net> writes:
> On Mon, 17 Jun 2024 18:02:49 +0300, Anton Shepelev
> <anton.txt@g{oogle}mail.com> wrote:
>
>>[cross-posted to: ci.stat.math]
>>
> Anton,
>
> The post being responded to was originally to comp.lang.c
> which I don't subscribe to.
>
> I have a question that I suppose reflects on my news source,
> GigaNews, or else on my reader, Forte Agent.
>
> Was this thread something posted 15 or 20 years ago?
>
> I tried to call up the original post by clicking on the Message
> ID when looking at headers; nothing comes up when Agent goes
> online to look. The header shows multiple earlier messages;
> none of them come up for me.
>
> My clicking on Message ID works elsewhere. The logical and
> simple explanation is that this is a thread old enough that
> GigaNews does not have it.
>
> I suppose that someone else might be able to tell me, if their
> supplier goes back further or if GigaNews is somehow failing
> to show me something that is recent.

The first article in this thread was posted to comp.lang.c by Janis
Papanagnou on 17 Jun 2024.

There were several followups on the same day. The diret parent of your
article was cross-posted to comp.lang.c and sci.stat.math by Anton
Shepelev (his was the first cross-posted article in the thread).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On 7/2/2024 12:51 AM, Rich Ulrich wrote:
> On Mon, 17 Jun 2024 18:02:49 +0300, Anton Shepelev
> <anton.txt@g{oogle}mail.com> wrote:
>
>> [cross-posted to: ci.stat.math]
>>
> Anton,
>
> The post being responded to was originally to comp.lang.c
> which I don't subscribe to.
>
> I have a question that I suppose reflects on my news source,
> GigaNews, or else on my reader, Forte Agent.
>
> Was this thread something posted 15 or 20 years ago?
>
> I tried to call up the original post by clicking on the Message
> ID when looking at headers; nothing comes up when Agent goes
> online to look. The header shows multiple earlier messages;
> none of them come up for me.
>
> My clicking on Message ID works elsewhere. The logical and
> simple explanation is that this is a thread old enough that
> GigaNews does not have it.
>
> I suppose that someone else might be able to tell me, if their
> supplier goes back further or if GigaNews is somehow failing
> to show me something that is recent.
>

MID: <v4ojs8$gvji$1@dont-email.me>

http://al.howardknight.net/

That gives this URL, as a copy of the message kicking off the thread.

http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4ojs8%24gvji%241%40dont-email.me%3E

Some USENET News clients can work from the MID directly, but Thunderbird does not.
A bare MID does not work for everyone.

Paul

On Mon, 01 Jul 2024 22:10:00 -0700, Keith Thompson
<Keith.S.Thompson+u@gmail.com> wrote:

>Rich Ulrich <rich.ulrich@comcast.net> writes:
>> On Mon, 17 Jun 2024 18:02:49 +0300, Anton Shepelev
>> <anton.txt@g{oogle}mail.com> wrote:
>>
>>>[cross-posted to: ci.stat.math]
>>>
>> Anton,
>>
>> The post being responded to was originally to comp.lang.c
>> which I don't subscribe to.
>>
>> I have a question that I suppose reflects on my news source,
>> GigaNews, or else on my reader, Forte Agent.
>>
>> Was this thread something posted 15 or 20 years ago?
>>
>> I tried to call up the original post by clicking on the Message
>> ID when looking at headers; nothing comes up when Agent goes
>> online to look. The header shows multiple earlier messages;
>> none of them come up for me.
>>
>> My clicking on Message ID works elsewhere. The logical and
>> simple explanation is that this is a thread old enough that
>> GigaNews does not have it.
>>
>> I suppose that someone else might be able to tell me, if their
>> supplier goes back further or if GigaNews is somehow failing
>> to show me something that is recent.
>
>The first article in this thread was posted to comp.lang.c by Janis
>Papanagnou on 17 Jun 2024.
>
>There were several followups on the same day. The diret parent of your
>article was cross-posted to comp.lang.c and sci.stat.math by Anton
>Shepelev (his was the first cross-posted article in the thread).

Thanks, so it looks like a failure by GigaNews to retrieve the
recent posts.

I did see a bunch of cross-posted followups. I don't know C,
and I thought there could be more context.

Looking at original, absent posts is something I've done dozens
of times over the years. Never a problem, except fora time or two
with posts from the 1990s. I've used GigaNews since my regular
ISP stopped providing Usenet access, maybe 15 years ago.

--
Rich Ulrich

On Tue, 2 Jul 2024 03:02:07 -0400, Paul <nospam@needed.invalid> wrote:

>On 7/2/2024 12:51 AM, Rich Ulrich wrote:
>> On Mon, 17 Jun 2024 18:02:49 +0300, Anton Shepelev
>> <anton.txt@g{oogle}mail.com> wrote:
>>
>>> [cross-posted to: ci.stat.math]
>>>
>> Anton,
>>
>> The post being responded to was originally to comp.lang.c
>> which I don't subscribe to.
>>
>> I have a question that I suppose reflects on my news source,
>> GigaNews, or else on my reader, Forte Agent.
>>
>> Was this thread something posted 15 or 20 years ago?
>>
>> I tried to call up the original post by clicking on the Message
>> ID when looking at headers; nothing comes up when Agent goes
>> online to look. The header shows multiple earlier messages;
>> none of them come up for me.
>>
>> My clicking on Message ID works elsewhere. The logical and
>> simple explanation is that this is a thread old enough that
>> GigaNews does not have it.
>>
>> I suppose that someone else might be able to tell me, if their
>> supplier goes back further or if GigaNews is somehow failing
>> to show me something that is recent.
>>
>
>MID: <v4ojs8$gvji$1@dont-email.me>
>
>http://al.howardknight.net/
>
>That gives this URL, as a copy of the message kicking off the thread.
>
> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4ojs8%24gvji%241%40dont-email.me%3E
>

Yes, that's the message I see when I plug the Message ID
into the program at http://al.howardknight.net/

Thanks. I'm saving that.

>Some USENET News clients can work from the MID directly, but Thunderbird does not.
>A bare MID does not work for everyone.

Forte Agent invites me to click on the MID; asks if it is a
mail or MID; asks if it should search the net. It still works
when I test it on an old message in another group.

--
Rich Ulrich

On Tue, 02 Jul 2024 11:52:56 -0400, Rich Ulrich
<rich.ulrich@comcast.net> wrote:

>
>Forte Agent invites me to click on the MID; asks if it is a
>mail or MID; asks if it should search the net. It still works
>when I test it on an old message in another group.
>

Now it occurs to me -- It actually does make sense,
economically, if what is searched online is limited the
groups I subscribe to, or (even) only the group that
is currently active.

--
Rich Ulrich

On 7/2/2024 11:58 AM, Rich Ulrich wrote:
> On Tue, 02 Jul 2024 11:52:56 -0400, Rich Ulrich
> <rich.ulrich@comcast.net> wrote:
>
>>
>> Forte Agent invites me to click on the MID; asks if it is a
>> mail or MID; asks if it should search the net. It still works
>> when I test it on an old message in another group.
>>
>
> Now it occurs to me -- It actually does make sense,
> economically, if what is searched online is limited the
> groups I subscribe to, or (even) only the group that
> is currently active.
>

Every device has "retention", but retention is limited.

Whether it's a search site, or a USENET server (even Forte had
their own news server, at one time), you need retention for
older articles to be search-able either as body text, or as
a <mid>.

Now that Google Groups is no longer connected to USENET,
that's one fewer places with a decent-sized archive. Google closed
their service, after the ThaiSpam incident. The Eternal-September
server, changed from one server to a two-server setup. The
Transit Server had Spam Assassin loaded on it, removing THaiSpam,
and the second server continued to offer normal ("filtered") service.

The comp.lang.c group was one of the groups under attack. Since
Google was letting the spam in, now that Google is disconnected,
the spam is gone, and the readership on CLC has gone up.

Paul

On 7/2/24 15:09, Paul wrote:
....
> Now that Google Groups is no longer connected to USENET,

I just checked, and as I had expected, Google is still connected.

> that's one fewer places with a decent-sized archive. Google closed
> their service, after the ThaiSpam incident.

They didn't close their service. They just stopped adding new messages
to their archives. The messages that were stored prior to the closing
are still available for searching.

On 7/2/24 15:09, Paul wrote:
....
> Now that Google Groups is no longer connected to USENET,
....
> that's one fewer places with a decent-sized archive. Google closed
> their service, after the ThaiSpam incident.

While they no longer store new messages, they still have one of the
largest archives of old messages, and it's still available for searching.

I had plumb forgot about this solution of mine:

> p0 = 1-e^(L*x0) ,
> p1 = 1-e^(L*x1) ,
> x1 = k*x0 (by our strategy), =>
> p1 = 1-(1-p0)^k .
>
> which does not depend on the distribution and lets us
> generalise this approach for any distribution:
>
> x1 = Q( 1 - ( 1 - CDF(x0) )^k )
> where:
>
> x0 : the required size
> x1 : the new recommended capacity
> Q(p) : the p-Quantile of the given distribution
> CDF(x): the CDF of the given distribution
> k>1 : balance between speed and space efficiency

Let us test it with the exponential distribution, for which:

Q (p) = -Ln( 1 - p )/L
CDF(x) = 1 - e^(-Lx)

Substituting these into the equation for x1:

x1 = Q ( 1 - ( 1 - ( 1 - e^(-Lx0) ) )^k ) =
Q ( 1 - ( e^(-Lx0) )^k ) =
Q ( 1 - e^(-kLx0) ) =
-Ln( e^(-kLx0) )/L = k*x0 (QED)

That is, my solution is a/the generalisation of the
exponential growth strategy.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Rich Ulrich:

> Thanks, so it looks like a failure by GigaNews to retrieve
> the recent posts.
>
> I did see a bunch of cross-posted followups. I don't know
> C, and I thought there could be more context.

Characters are being read in (say, from a file) sequentially
and stored in computer memory (RAM) in an "array" -- a
linear data structure storing elements (our characters) in a
sequential order, one ofter the other at addresses with
increasing indexes -- somewhat like a mathematical vector.

In order to store a character in an array, sufficient memory
has to be "allocated" for it, but while reading we do not
know beforehand the size of the file (or the total length of
the sequence), and therefore increase the allocated aray
size prospectively once the previous allocation is filled.
This operaion is called `realloc' and frequently involves
the tedious copying of the entire array onto a new location
in memory, taking a time in proportion to the number
elemennts so far allocated.

The question is to develop an optimal allcation strategy for
a given distribution of file sizes. The fasted solution is
to allocate a gigantic array beforehand, but it is a
terrible waste of memory. The slowet solution is to
reallcoate for each single character read it, but is a
terrible waste of CPU time. As I understand the problem, a
strategy is needed that manifests some compromise between
the extremes.

> Looking at original, absent posts is something I've done
> dozens of times over the years. Never a problem, except
> fora time or two with posts from the 1990s. I've used
> GigaNews since my regular ISP stopped providing Usenet
> access, maybe 15 years ago.

Just in case, there are many totally free Usenet servers,
e.g.:
http://www.eternal-september.org/
https://www.i2pn2.org/

and even a web interface:

https://www.novabbs.com

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On Mon, 8 Jul 2024 20:01:21 +0300, Anton Shepelev
<anton.txt@g{oogle}mail.com> wrote:

>Rich Ulrich:
>
>> Thanks, so it looks like a failure by GigaNews to retrieve
>> the recent posts.
>>
>> I did see a bunch of cross-posted followups. I don't know
>> C, and I thought there could be more context.

<snip. Thanks for the details.>

Okay, today I discovered that there was no failure by Giganews
or by Forte Agent -- Instead, there was BEHAVIOR by Agent
that I was not aware of.

Today, was looking at All Desks (Agent terminology) to see what
was in Sent, and I noticed there were messages in Inbox -- Those
were the messages that I thought Agent had failed to retrieve.
(Nice discussion there.)

I guess - every other time I've clicked on Message-ID, the old
message was in the group where I was reading and the old one
showed up where I was reading. I've read the Agent group for
ages, and I don't remember this feature ever being mentioned.

Live and learn.

--
Rich Ulrich

Rich Ulrich:

> Today, was looking at All Desks (Agent terminology) to see
> what was in Sent, and I noticed there were messages in
> Inbox -- Those were the messages that I thought Agent had
> failed to retrieve. (Nice discussion there.)

Looking forward to your take on the problem. Mine is rather
simplisitc, but can be easily tested with several
distributions. This is like extrapolation: we know the
optimal solution for the given distribution (exponential)
and want to devise a general method to get the optimal
solution for any given distribution.

Malcolm, if you are still interested, can you provide a test
program that measures some statiscits for various allocation
strategies on various distributions, inclusing the
exponential?

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments