Hackie: > Here I avoid losing precision by multiplying the sum instead, while > lowering bsize. > So bsize goes down and is not fixed anymore. And at the end of the loop > it is always equal to the lowest bsize of all branches. > > I think this is the way to go. No array to allocate, flexible bsize, > always the same precision as our branches.
Ok, I will take it. But I'd ask you to do correct a few things about the coding style before applying your patch. - read Documentation/CodingStyle and SubmittingPatches. - check by scripts/checkpatch.pl. It may not be necessary to fix all warning produced by checkpatch.pl because it doesn't parse the C program as compiler. But about an easy level warnings such like indentation, spacing, comment-style, parenthesis, etc, I'd ask you to fix it. And about the code itself, - the variable name 'f' stands for "factor"? Then I'd ask you to name it "factor" or something. - if we initialize 'bsize' as ULLONG_MAX, then the test "bsize == 0 || bsize > buf->f_bsize" in the loop can be replaced by "bsize > buf->f_bsize". > And AFAIK divisions are slower than multiplications (especially 64bit > ones), so the whole thing is also faster... Maybe you are right. In the worst case, you multiply twice while I divide once. But still you may be faster. J. R. Okajima ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
