[Gllug] OT: algorithm needed

[Andrew Farnsworth]

Peter Corlett wrote:
> On 10 Aug 2008, at 22:38, salsaman at xs4all.nl wrote:
> [...]
>   
>> That's right - I should have added that each read should read as  
>> close to
>> the max as possible (including the final read).
>>     
>
> If you think about it for a moment, all solutions which contain  
> ceil(total / max) transfers are equally-close to max.
>
> You can increase the number of blocks in a transfer to get it close to  
> max, but at the cost of reducing it elsewhere by an equal number. Each  
> transfer will still have to do an average of total / ceil (total -  
> max) blocks however you balance the individual transfers.
>
> The problem appears to be not for want of a good algorithm but the  
> lack of a good definition of the problem.
>   
Correct me if I am wrong but is not the most efficient method of doing 
these reads the scenario where you have the fewest number of partial 
reads?  In other words, if you have 100 blocks to read, and a max read 
size of 40 blocks, the most efficient is 40,40,20 or 40,20,40 or 20, 40, 
40?  This way you only get one partial read, where if you normalize your 
reads you get 3 partial buffer reads of 33,33,34 or 33, 34, 33 or 
34,33,33 and isn't each of these reads non-optimal?  Therefore reading 
in max buffer size from the beginning and let the final read be the 
optimal situation?

Andrew Farnsworth
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug