Dynamically resizing a buffer

**cr88192** · Aug 23 '07, 03:25 PM

Re: Dynamically resizing a buffer

"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:ck60q4x2tf .ln2@news.flash-gordon.me.uk...

cr88192 wrote, On 23/08/07 11:12:

<snip>

>>
>not optimizations. shifts are how one typically does these things...

>
Not if one is being sensible.
>

>it is much the same as why we call int variables i, j, and k I think, or
>many other common practices. after enough years, and enough code, one
>largely forgets any such reasoning, all rote response really...

>
I have spent years programming in assembler where I would use shifts and
years spent programming in high level languages where I would not.
>

yeah, I also use assembler...

otherwise:

I always used shifts, never thought much of it.
I use shifts where I think shifts, I had never thought to think divides...

if I were thinking of a divide, than i/3 is an obvious difference from i/2.
if I was not, it is not.
it is a non-obvious jump from 'i>>1' to 'i/3', unless one first thinks that
'i>>1' is actually 'i/2'...

>actually, had I been thinking of compiler behavior much at all, I would
>have realized that 'i/3' actually becomes a fixed point multiply by a
>reciprocal. no such reasoning was used in this case.
>>
>this was a trivial and obvious mistake is all.

>
A trivial mistake that does not get made if you code what you want to
express instead of trying to use tricks. That is part of the point.
>

'want to express'?...

this implies certain things, ie, that what I would want to express is
different from the code I would write to express it.

do you ask me, if my grammar is unusual, if it is because I am not writing
what I am meaning to express?...

it is a similar question IMO...

Whatever the reason for you learning to use such tricks it is well past
time you learned not to use them excpet where it is proved that you need
to.
>

'tricks'?...

shifts are a basic operator, I don't see why they would be viewed as any
kind of trick...

do we call pointers and casts tricks as well?... typical code is riddled
with the things, nothing sinister there...

now, does one think in terms of arithmetic ops or in terms of bitwise
ops?...
does one do their everyday arithmetic (internally) in decimal or in hex?...

if we read something do we see the text, hear words, or see imagery?...

this kind of issue has not come up in any time in recent memory...

so, one thinks in hex and writes in decimal, or vice versa, not usually that
important.
and, if one happens to be thinking in hex right, then a shift is more
intuitive than a divide.

does one think of the money in their wallet as 300 or 0x12C?...
does one think in british or metric units?...

or does one use whatever system happens to seem more natural at that
instant?...

up to them really. it only matters that when someone asks that they give the
right number, and when they read that they don't get confused...

one typically doesn't know the magic going on even in ones' own head...

>>
>4/3 is a natural growth curve. something around this ratio should
>presumably work good as a general mean case.

>
Exponential is also a natural growth curve, if you don't believe me check
how populations grow in nature, for at least some it is exponential until
a crash.
>

when applied recursively, this is exponential...

The best growth curve depends on the situation. For some thing I know that
in the foreseeable future I need space for 10 foos and if it grows beyond
that it will be unlikely to be by much, so I start with 10 and use a small
linear growth (saves having to revisit the code unless something very
strange happens). For other things that would be completely stupid.

yeah...

--
Flash Gordon

**Richard Heathfield** · Aug 23 '07, 04:35 PM

Re: Dynamically resizing a buffer

Philip Potter said:

Richard Heathfield wrote:

<snip>

>>
>I have just conducted a search of my development archives, and found
>a few calls to exit() in ancient code, so I can't claim I never use
>it. But without looking it up, I can't recall the last time I used
>it, at least not in "real" code.

>
So do you prefer to handle errors by returning an error code, which
main() can deal with as it pleases?

Yes.

I guess that makes sense, but it
seems like a more effortful design style than I really need for this
project.

I thought someone might come up with that example. But it could be
argued that q is a different pointer from p, because although it may
have the same value, it serves a different purpose.

Indeed it could be argued that the second pointer is a different value
that just happens to look remarkably similar to the first. I was, of
course, merely cranking up the pedantry. :-)

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

**Philip Potter** · Aug 23 '07, 04:45 PM

Re: Dynamically resizing a buffer

Richard Heathfield wrote:

Philip Potter said:

>I thought someone might come up with that example. But it could be
>argued that q is a different pointer from p, because although it may
>have the same value, it serves a different purpose.

>
Indeed it could be argued that the second pointer is a different value
that just happens to look remarkably similar to the first. I was, of
course, merely cranking up the pedantry. :-)

I think you cranked it up a long time ago; the wind changed and it got
stuck...

--
Philip Potter pgp <atdoc.ic.ac. uk

**Flash Gordon** · Aug 23 '07, 06:45 PM

Re: Dynamically resizing a buffer

cr88192 wrote, On 23/08/07 16:09:

"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:ck60q4x2tf .ln2@news.flash-gordon.me.uk...

>cr88192 wrote, On 23/08/07 11:12:

>
<snip>
>

>>not optimizations. shifts are how one typically does these things...

>Not if one is being sensible.
>>

>>it is much the same as why we call int variables i, j, and k I think, or
>>many other common practices. after enough years, and enough code, one
>>largely forgets any such reasoning, all rote response really...

>I have spent years programming in assembler where I would use shifts and
>years spent programming in high level languages where I would not.

>
yeah, I also use assembler...
>
otherwise:
>
I always used shifts, never thought much of it.
I use shifts where I think shifts, I had never thought to think divides...
>
if I were thinking of a divide, than i/3 is an obvious difference from i/2.
if I was not, it is not.
it is a non-obvious jump from 'i>>1' to 'i/3', unless one first thinks that
'i>>1' is actually 'i/2'...

You are trying to reduce a number by a factor not trying to move bits.
They are conceptually different things. Try using a shit to halve a
floating point number as see how far it gets you.

>>actually, had I been thinking of compiler behavior much at all, I would
>>have realized that 'i/3' actually becomes a fixed point multiply by a
>>reciprocal. no such reasoning was used in this case.
>>>
>>this was a trivial and obvious mistake is all.

>A trivial mistake that does not get made if you code what you want to
>express instead of trying to use tricks. That is part of the point.

>
'want to express'?...
>
this implies certain things, ie, that what I would want to express is
different from the code I would write to express it.

Shift is for moving bits, divide is for scaling. Otherwise shift would
work on floating point and would have behaviour defined by the C
standard for negative numbers (it leaves it for the implementation to
define the result of right shifting a negative number).

do you ask me, if my grammar is unusual, if it is because I am not writing
what I am meaning to express?...
>
it is a similar question IMO...

No, it is a question of using the wrong word. One that in some
situations happens to be similar, but in many situations means something
completely different.

>Whatever the reason for you learning to use such tricks it is well past
>time you learned not to use them excpet where it is proved that you need
>to.
>>

>
'tricks'?...

Yes, it is a trick.

shifts are a basic operator, I don't see why they would be viewed as any
kind of trick...

The shift operator is a basic operator for moving bits, using it to
divide is a trick and one that does not work in all situations.

do we call pointers and casts tricks as well?... typical code is riddled
with the things, nothing sinister there...

Code riddled with casts probably is bad.

Code using a lot of shifts for shifting bits, NOT for division, could be
good.

now, does one think in terms of arithmetic ops or in terms of bitwise
ops?...

No. However a shift works in terms of bits, not in terms of arithmetic.

does one do their everyday arithmetic (internally) in decimal or in hex?...
>
if we read something do we see the text, hear words, or see imagery?...

Several of the things above are reasons for using divide rather than shift.

this kind of issue has not come up in any time in recent memory...

The issue of you making a mistake that you would not have done had you
stuck to doing simple integer division is a good reason for using
integer division.

so, one thinks in hex and writes in decimal, or vice versa, not usually that
important.
and, if one happens to be thinking in hex right, then a shift is more
intuitive than a divide.

What do you get if you right shift -1? On some machines it will be 32767
on others it will be -1. Does that sound like division to you?

does one think of the money in their wallet as 300 or 0x12C?...
does one think in british or metric units?...
>
or does one use whatever system happens to seem more natural at that
instant?...

Not relevant since a shift is not a different representation for
division, it is a different operation.

up to them really. it only matters that when someone asks that they give the
right number, and when they read that they don't get confused...
>
one typically doesn't know the magic going on even in ones' own head...

Code is written for other people, not just the original author or the
compiler.

>>4/3 is a natural growth curve. something around this ratio should
>>presumably work good as a general mean case.

>Exponential is also a natural growth curve, if you don't believe me check
>how populations grow in nature, for at least some it is exponential until
>a crash.

>
when applied recursively, this is exponential...

Linear is another natural growth curve.

>The best growth curve depends on the situation. For some thing I know that
>in the foreseeable future I need space for 10 foos and if it grows beyond
>that it will be unlikely to be by much, so I start with 10 and use a small
>linear growth (saves having to revisit the code unless something very
>strange happens). For other things that would be completely stupid.

>
yeah...

Ah, so you realise now that suggesting a 4/3 curve makes less sense than
suggesting using a curve that will give good performance. My example
above was extreme, but there are plenty of less extreme examples.
--
Flash Gordon

**santosh** · Aug 23 '07, 08:45 PM

Re: Dynamically resizing a buffer

cr88192 wrote:

"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:ck60q4x2tf .ln2@news.flash-gordon.me.uk...

>cr88192 wrote, On 23/08/07 11:12:

>
<snip>
>

>>not optimizations. shifts are how one typically does these things...

>>
>Not if one is being sensible.

[ ... ]

>I have spent years programming in assembler where I would use shifts and
>years spent programming in high level languages where I would not.
>>

>
yeah, I also use assembler...
>
otherwise:
>
I always used shifts, never thought much of it.
I use shifts where I think shifts, I had never thought to think divides...

<snip>

>Whatever the reason for you learning to use such tricks it is well past
>time you learned not to use them excpet where it is proved that you need
>to.
>>

'tricks'?...
>
shifts are a basic operator, I don't see why they would be viewed as any
kind of trick...

The point, I think, is that using right shift for achieving the effect of
division is not completely portable. It used to be a viable alternative at
a time when optimisation was primitive, but it's useless and flaky
nowadays, since almost any compiler is going to optimise a division into
shifts, if it can.

do we call pointers and casts tricks as well?

Not the devices themselves, but their uses in specific cases, eg., type
punning, casts that discard data etc.

... typical code is riddled
with the things, nothing sinister there...

now, does one think in terms of arithmetic ops or in terms of bitwise
ops?...

No, in terms of their effect according to the rules of arithmetics. Numbers
may be represented as bits under computers, but that is no reason to think
of every arithmetic operation in terms of their effect at the bit
representation level, except when it _is_ required.

does one do their everyday arithmetic (internally) in decimal or in
hex?...
>
if we read something do we see the text, hear words, or see imagery?...

Personally, an amalgamation of all three, plus imagination of other types of
sensory inputs, as appropriate.

<snip>

**cr88192** · Aug 24 '07, 01:55 AM

Re: Dynamically resizing a buffer

"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:1ru0q4xk0o .ln2@news.flash-gordon.me.uk...

cr88192 wrote, On 23/08/07 16:09:

>"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
>news:ck60q4x2t f.ln2@news.flas h-gordon.me.uk...

>>cr88192 wrote, On 23/08/07 11:12:

>>
><snip>
>>

>>>not optimizations. shifts are how one typically does these things...
>>Not if one is being sensible.
>>>
>>>it is much the same as why we call int variables i, j, and k I think,
>>>or many other common practices. after enough years, and enough code,
>>>one largely forgets any such reasoning, all rote response really...
>>I have spent years programming in assembler where I would use shifts and
>>years spent programming in high level languages where I would not.

>>
>yeah, I also use assembler...
>>
>otherwise:
>>
>I always used shifts, never thought much of it.
>I use shifts where I think shifts, I had never thought to think
>divides...
>>
>if I were thinking of a divide, than i/3 is an obvious difference from
>i/2. if I was not, it is not.
>it is a non-obvious jump from 'i>>1' to 'i/3', unless one first thinks
>that 'i>>1' is actually 'i/2'...

>
You are trying to reduce a number by a factor not trying to move bits.
They are conceptually different things. Try using a shit to halve a
floating point number as see how far it gets you.
>

but, a float and an integer are different concepts though...

not sure of why one would consider using a shift on a float...

>>>actually, had I been thinking of compiler behavior much at all, I would
>>>have realized that 'i/3' actually becomes a fixed point multiply by a
>>>reciprocal . no such reasoning was used in this case.
>>>>
>>>this was a trivial and obvious mistake is all.
>>A trivial mistake that does not get made if you code what you want to
>>express instead of trying to use tricks. That is part of the point.

>>
>'want to express'?...
>>
>this implies certain things, ie, that what I would want to express is
>different from the code I would write to express it.

>
Shift is for moving bits, divide is for scaling. Otherwise shift would
work on floating point and would have behaviour defined by the C standard
for negative numbers (it leaves it for the implementation to define the
result of right shifting a negative number).
>

ok, makes sense.

>do you ask me, if my grammar is unusual, if it is because I am not
>writing what I am meaning to express?...
>>
>it is a similar question IMO...

>
No, it is a question of using the wrong word. One that in some situations
happens to be similar, but in many situations means something completely
different.
>

the situations are different though.
as noted above, an integer and a float are conceptually different.

if I am speaking to someone do I count in floats? no, I count in integers...

>>Whatever the reason for you learning to use such tricks it is well past
>>time you learned not to use them excpet where it is proved that you need
>>to.
>>>

>>
>'tricks'?...

>
Yes, it is a trick.
>

>shifts are a basic operator, I don't see why they would be viewed as any
>kind of trick...

>
The shift operator is a basic operator for moving bits, using it to divide
is a trick and one that does not work in all situations.
>

it works on integers, integers are the context and the situation.
sizes are generally not negative either.

there is no problem as I see it.

>do we call pointers and casts tricks as well?... typical code is riddled
>with the things, nothing sinister there...

>
Code riddled with casts probably is bad.
>
Code using a lot of shifts for shifting bits, NOT for division, could be
good.
>

ok, but then one has to differentiate: when is the concept shifting bits and
when is it division?...
this is a subjective matter.

>now, does one think in terms of arithmetic ops or in terms of bitwise
>ops?...

>
No. However a shift works in terms of bits, not in terms of arithmetic.
>

but on integers, bit ops are arithmetic...

makes nearly as much sense in conversation as it would in C.
we ask someone 'what is 12 and 7?' they say '8'...

>does one do their everyday arithmetic (internally) in decimal or in
>hex?...
>>
>if we read something do we see the text, hear words, or see imagery?...

>
Several of the things above are reasons for using divide rather than
shift.
>

if one is confused as to whether not they are dealing with an integer...

what if I meant to grab an apple but instead grabbed a potatoe and proceeded
to eat it as said apple. people would look oddly, and then maybe ones'
stomach gets irritated from the raw potatoe...

so, casually eating an object raw is valid for an apple but not for said
potatoe.
likewise, we put potatoes in soup but not apples.

same difference really...

or a bigger mystery (OT, but as an example):
when someone can claim adherence to a certain religion and do things which
are condemned within the doctrine of said religion, meanwhile knowing the
doctrine, and then believe that their actions are moral (presumably within
the bounds of said religion).

this has happened recently, and after several months I still haven't figured
it out.

do they deny their actions? no.
do they deny the doctrine or the existence (or interpretation) of the
indicated statements? no.
do they admit that their actions are immoral? no.

this makes little sense really...

like some kind of bizarre paradox as to their reasoning...
(throwing philosophy at the problem still does not resolve it...).

>this kind of issue has not come up in any time in recent memory...

>
The issue of you making a mistake that you would not have done had you
stuck to doing simple integer division is a good reason for using integer
division.
>

potentially, but this makes an assumption about ones' thought process.
if one always types shifts, one thinks shifts, one does not think division
unless one were first thinking of division, which I assert that I was not
(which is why I think I missed such an obvious answer).

>so, one thinks in hex and writes in decimal, or vice versa, not usually
>that important.
>and, if one happens to be thinking in hex right, then a shift is more
>intuitive than a divide.

>
What do you get if you right shift -1? On some machines it will be 32767
on others it will be -1. Does that sound like division to you?
>

different context.

one machine is probably an x86 in real mode with an int being 16 bits and
using shr.
the other is probably using sar.

>does one think of the money in their wallet as 300 or 0x12C?...
>does one think in british or metric units?...
>>
>or does one use whatever system happens to seem more natural at that
>instant?...

>
Not relevant since a shift is not a different representation for division,
it is a different operation.
>

it is an operation relevant to a situation, that situation being positive
integers...
I was not claiming it was also sane for floats or for negatives.

>up to them really. it only matters that when someone asks that they give
>the right number, and when they read that they don't get confused...
>>
>one typically doesn't know the magic going on even in ones' own head...

>
Code is written for other people, not just the original author or the
compiler.
>

maybe.
if other people ever actually read said code.

>>>4/3 is a natural growth curve. something around this ratio should
>>>presumably work good as a general mean case.
>>Exponential is also a natural growth curve, if you don't believe me
>>check how populations grow in nature, for at least some it is
>>exponential until a crash.

>>
>when applied recursively, this is exponential...

>
Linear is another natural growth curve.
>

except that linear is not a curve...

>>The best growth curve depends on the situation. For some thing I know
>>that in the foreseeable future I need space for 10 foos and if it grows
>>beyond that it will be unlikely to be by much, so I start with 10 and
>>use a small linear growth (saves having to revisit the code unless
>>something very strange happens). For other things that would be
>>completely stupid.

>>
>yeah...

>
Ah, so you realise now that suggesting a 4/3 curve makes less sense than
suggesting using a curve that will give good performance. My example above
was extreme, but there are plenty of less extreme examples.

the question is then what curve gives the best performance, which may depend
on the situation.
it is a tradeoff really between number of reallocations and wasted space.

4/3 is more conservative with space than 3/2, which is still more
conservative than the golden ratio.

so the question is then of rate of growth and likelyhood of continued
growth.

and, for the previous topic:
it is by some odd convention that when we see a division by undivisible
integers that we realize that it has a non-integer output.

I guess it is also by similar convention that we realize that negative even
roots are imaginary and that non-integral exponents of negative bases are
complex...

--
Flash Gordon

**Peter J. Holzer** · Aug 24 '07, 02:05 PM

Re: Dynamically resizing a buffer

On 2007-08-22 11:29, Mark Bluemel <mark_bluemel@p obox.comwrote:

Philip Potter wrote:

>>
>struct mybuffer_t {
> unsigned char *data;
> size_t size; /* size of buffer allocated */
> size_t index; /* index of first unwritten member of data */
>};
>>

[...]

int resizeBuffer(My Buffer *buf) {
size_t inc = buf->size;
unsigned char *tmp = NULL;
while(inc>0 &&
(tmp = realloc(buf->data, buf->size + inc)) == NULL) {

You can change this test slightly to catch size_t overflow at the same
time:

while((size_t)( buf->size + inc) buf->size &&
(tmp = realloc(buf->data, buf->size + inc)) == NULL) {

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

**Peter J. Holzer** · Aug 24 '07, 02:05 PM

Re: Dynamically resizing a buffer

On 2007-08-23 11:11, Flash Gordon <spam@flash-gordon.me.ukwro te:

cr88192 wrote, On 23/08/07 11:12:

>>
>4/3 is a natural growth curve. something around this ratio should
>presumably work good as a general mean case.

>
Exponential is also a natural growth curve,

**Peter J. Holzer** · Aug 24 '07, 02:15 PM

Re: Dynamically resizing a buffer

On 2007-08-24 02:01, cr88192 <cr88192@hotmai l.comwrote:

>
"santosh" <santosh.k83@gm ail.comwrote in message
news:fakral$m2e $1@aioe.org...

>No, in terms of their effect according to the rules of arithmetics.
>Numbers may be represented as bits under computers, but that is no
>reason to think of every arithmetic operation in terms of their
>effect at the bit representation level, except when it _is_ required.
>>

>
ok. people then thinking in decimal rather than bits

**Peter J. Holzer** · Aug 24 '07, 02:25 PM

Re: Dynamically resizing a buffer

On 2007-08-23 15:09, cr88192 <cr88192@hotmai l.comwrote:

I always used shifts, never thought much of it.
I use shifts where I think shifts, I had never thought to think divides...
>
>
if I were thinking of a divide, than i/3 is an obvious difference from i/2.
if I was not, it is not.
it is a non-obvious jump from 'i>>1' to 'i/3', unless one first thinks that
'i>>1' is actually 'i/2'...

But you were thinking of divides - you explicitely stated that you
wanted an increase of 50% (1/2), 33% (ca. 1/3) or 25% (1/4). Since 1/2,
1/3 and 1/4 is a nice progression, I find it much more likely that you
derived ((i>>2) + (i>>4) + (i>>6)) as an approximation of 1/3 than
the other way around. If you had been thinking of shifts, you would
probably have chosen ((i>>2) + (i>>3)) as the middle point between
(i>>1) and (i>>2).

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

**cr88192** · Aug 24 '07, 02:25 PM

Re: Dynamically resizing a buffer

"Peter J. Holzer" <hjp-usenet2@hjp.atw rote in message
news:slrnfctp2m .vvs.hjp-usenet2@zeno.hj p.at...

On 2007-08-24 02:01, cr88192 <cr88192@hotmai l.comwrote:

>>
>"santosh" <santosh.k83@gm ail.comwrote in message
>news:fakral$m2 e$1@aioe.org...

>>No, in terms of their effect according to the rules of arithmetics.
>>Numbers may be represented as bits under computers, but that is no
>>reason to think of every arithmetic operation in terms of their
>>effect at the bit representation level, except when it _is_ required.
>>>

>>
>ok. people then thinking in decimal rather than bits

>
Or just in terms of numbers regardless of any specific representation.
>

however this would work I guess...

actually, I think if I think of a specific-sized integer, I see a fixed
square with hex-digits inside.
if I think of other numbers, I see them as a decimal version. floats are
decimal but associated with a square (the number is fit inside the square).

I think they may also be overlayed with a name and other information.

I think idle thinking results in a good deal of visual "shadowing" . I think
about something, and stuff goes on in some kind of semi-diagramic head-UI.

things in said head-UI, look different than in traditional UIs, mostly light
on dark rather than dark on light (as is typical in windows...).

or something...

**Peter J. Holzer** · Aug 24 '07, 02:35 PM

Re: Dynamically resizing a buffer

On 2007-08-22 13:13, Richard Tobin <richard@cogsci .ed.ac.ukwrote:

Of course that's what the original proposal did: increase by 100% of
the current size. If you start from one, this means you only allocate
power-of-two sized blocks.
>
A problem with any approach is that it might interact badly with the
malloc() implementation. Imagine an implementation that always
allocates powers of two but uses sizeof(void *) bytes of it to record
the size - if you always allocated powers of two you would end up
allocating nearly four times as much as you need.

I actually ran into this problem when I tested my dynamic buffer
implementation on several systems in the early 1990's. I found that
increasing by a factor of 1.5 worked well across all the implementations
I tested at that time, but of course that's no guarantee that it works
as well for all possible implementations (or even most implementations
today).

I recommend separating out the increment algorithm so that it can
easily be changed if it proves to be bad on some platform.

Yup. Did that, too, at the time:

/* Macro: DA_GROW
* Purpose: Return the new size of an array which had size |a| and must
* include index |b|.
* This macro may be changed by the application, but the default is
* expected to be useful for many applications.
*
* Algorithm: It is assumed that most arrays will grow linearly,
* that is, |b| will equal |a|. To avoid calling realloc for every
* element added, the size is multiplied by a constant factor.
* The factor is 1.5 because a factor of 2 has produced extreme
* fragmentation with some allocators.
* For the case where this expansion is not sufficient to reach
* index |b| we do not guess about the future growth of the array
* and make it just large enough.
* This algorithm is good enough to start at zero, but the
* steps will be very small at first (0, 1, 2, 3, 4, 6, 9, 13, ...)
* so it might be a good idea to start with some moderate index.
*/
#ifndef DA_GROW
#define DA_GROW(a,b) MAX((a) * 3 / 2, (b) + 1)
#endif

(the whole thing was entirely implemented as macros, not as functions)

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

**Flash Gordon** · Aug 24 '07, 07:35 PM

Re: Dynamically resizing a buffer

cr88192 wrote, On 24/08/07 02:46:

"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:1ru0q4xk0o .ln2@news.flash-gordon.me.uk...

>cr88192 wrote, On 23/08/07 16:09:

>>"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
>>news:ck60q4x2 tf.ln2@news.fla sh-gordon.me.uk...
>>>cr88192 wrote, On 23/08/07 11:12:
>><snip>
>>>
>>>>not optimizations. shifts are how one typically does these things...
>>>Not if one is being sensible.
>>>>
>>>>it is much the same as why we call int variables i, j, and k I think,
>>>>or many other common practices. after enough years, and enough code,
>>>>one largely forgets any such reasoning, all rote response really...
>>>I have spent years programming in assembler where I would use shifts and
>>>years spent programming in high level languages where I would not.
>>yeah, I also use assembler...
>>>
>>otherwise:
>>>
>>I always used shifts, never thought much of it.
>>I use shifts where I think shifts, I had never thought to think
>>divides...
>>>
>>if I were thinking of a divide, than i/3 is an obvious difference from
>>i/2. if I was not, it is not.
>>it is a non-obvious jump from 'i>>1' to 'i/3', unless one first thinks
>>that 'i>>1' is actually 'i/2'...

>You are trying to reduce a number by a factor not trying to move bits.
>They are conceptually different things. Try using a shit to halve a
>floating point number as see how far it gets you.
>>

>
but, a float and an integer are different concepts though...
not sure of why one would consider using a shift on a float...

Because you consider shift an appropriate method of halving a number.

>>>>actually, had I been thinking of compiler behavior much at all, I would
>>>>have realized that 'i/3' actually becomes a fixed point multiply by a
>>>>reciproca l. no such reasoning was used in this case.
>>>>>
>>>>this was a trivial and obvious mistake is all.
>>>A trivial mistake that does not get made if you code what you want to
>>>express instead of trying to use tricks. That is part of the point.
>>'want to express'?...
>>>
>>this implies certain things, ie, that what I would want to express is
>>different from the code I would write to express it.

>Shift is for moving bits, divide is for scaling. Otherwise shift would
>work on floating point and would have behaviour defined by the C standard
>for negative numbers (it leaves it for the implementation to define the
>result of right shifting a negative number).

>
ok, makes sense.

So will you move to the less error prone system then?

>>do you ask me, if my grammar is unusual, if it is because I am not
>>writing what I am meaning to express?...
>>>
>>it is a similar question IMO...

>No, it is a question of using the wrong word. One that in some situations
>happens to be similar, but in many situations means something completely
>different.

>
the situations are different though.
as noted above, an integer and a float are conceptually different.
if I am speaking to someone do I count in floats? no, I count in integers...

I measure sizes in all sorts of different systems not all of which are
integers.

>>>Whatever the reason for you learning to use such tricks it is well past
>>>time you learned not to use them excpet where it is proved that you need
>>>to.
>>>>
>>'tricks'?.. .

>Yes, it is a trick.
>>

>>shifts are a basic operator, I don't see why they would be viewed as any
>>kind of trick...

>The shift operator is a basic operator for moving bits, using it to divide
>is a trick and one that does not work in all situations.

>
it works on integers, integers are the context and the situation.
sizes are generally not negative either.

They are sometimes.
If a spec says a number is in bits 3 to 7 then getting it to the correct
place is shifting.

there is no problem as I see it.

I thought you admitted to an error that would not be made if using
simple division. For one value you certainly suggested something more
complex than simple division.

>>do we call pointers and casts tricks as well?... typical code is riddled
>>with the things, nothing sinister there...

>Code riddled with casts probably is bad.
>>
>Code using a lot of shifts for shifting bits, NOT for division, could be
>good.

>
ok, but then one has to differentiate: when is the concept shifting bits and
when is it division?...
this is a subjective matter.

I honestly cannot conceive of why one would consider shifting to be the
natural way of scaling a value. Would you convert from inches to
centimetres by shifting? Would you talk about doubling your salary or
shifting it one bit to the left? Would you tell someone that they you
have doubled the storage capacity of a disk array or shifted it one bit
to the left? Or that the free space has been shifted one bit to the
right instead of halved?

Changing the size of a buffer is NOT linked to the representation of the
size, shifting is.

>>now, does one think in terms of arithmetic ops or in terms of bitwise
>>ops?...

>No. However a shift works in terms of bits, not in terms of arithmetic.

>
but on integers, bit ops are arithmetic...

Nope. Right shift is a logical shift on some processors *not*
arithmetic. If anyone ever builds a trinary machine then the shift
operation procided by the processor will *not* be multiply/divide by 2.
On a machine using BCD it isn't either, and BCD has been used for
representing integer values.

makes nearly as much sense in conversation as it would in C.
we ask someone 'what is 12 and 7?' they say '8'...

I can't see what point you are trying to make, unless it is why you
should *not* use a shift for scaling.

>>does one do their everyday arithmetic (internally) in decimal or in
>>hex?...
>>>
>>if we read something do we see the text, hear words, or see imagery?...

>Several of the things above are reasons for using divide rather than
>shift.

>
if one is confused as to whether not they are dealing with an integer...

You still keep forgetting that it only works for half the integer types
C provides, a sure sign in my opinion that you should stay well away
from the shift operator in C.

You are confused about values and specific representations . Binary is
not the only representation for numbers, it just happens to be the
current vogue in computing.

what if I meant to grab an apple but instead grabbed a potatoe and proceeded
to eat it as said apple. people would look oddly, and then maybe ones'
stomach gets irritated from the raw potatoe...
>
so, casually eating an object raw is valid for an apple but not for said
potatoe.
likewise, we put potatoes in soup but not apples.
>
same difference really...

All valid analogies for why you should be using division for scaling not
shifting.

<snip philosophy ramblings that seem to have no bearing on the matter at
hand>

>>this kind of issue has not come up in any time in recent memory...

>The issue of you making a mistake that you would not have done had you
>stuck to doing simple integer division is a good reason for using integer
>division.

>
potentially, but this makes an assumption about ones' thought process.
if one always types shifts, one thinks shifts, one does not think division
unless one were first thinking of division, which I assert that I was not
(which is why I think I missed such an obvious answer).

So if someone tells you to increase a buffer by 81% you would think in
terms of shifts?

>>so, one thinks in hex and writes in decimal, or vice versa, not usually
>>that important.
>>and, if one happens to be thinking in hex right, then a shift is more
>>intuitive than a divide.

>What do you get if you right shift -1? On some machines it will be 32767
>on others it will be -1. Does that sound like division to you?

>
different context.
>
one machine is probably an x86 in real mode with an int being 16 bits and
using shr.
the other is probably using sar.

Nope, one machine is not an x86 and does not have an arithmetic shift at
all.

>>does one think of the money in their wallet as 300 or 0x12C?...
>>does one think in british or metric units?...
>>>
>>or does one use whatever system happens to seem more natural at that
>>instant?...

>Not relevant since a shift is not a different representation for division,
>it is a different operation.

>
it is an operation relevant to a situation, that situation being positive
integers...

So when you have spent half your money do you think that you have
shifted your resources one bit to the right?

I was not claiming it was also sane for floats or for negatives.

Why? They are just numbers. In any case, you keep referring to integers
rather than unsigned integers, so either you are repeatedly making a
mistake and therefore showing why you should not be using shift you you
are being sloppy in a way that leads to mistakes thus showing why using
shift is inadvisable.

>>up to them really. it only matters that when someone asks that they give
>>the right number, and when they read that they don't get confused...
>>>
>>one typically doesn't know the magic going on even in ones' own head...

>Code is written for other people, not just the original author or the
>compiler.

>
maybe.
if other people ever actually read said code.

You were advising on how someone else should do things, therefore
someone other than you *will* see the code.

>>>>4/3 is a natural growth curve. something around this ratio should
>>>>presumabl y work good as a general mean case.
>>>Exponentia l is also a natural growth curve, if you don't believe me
>>>check how populations grow in nature, for at least some it is
>>>exponentia l until a crash.
>>when applied recursively, this is exponential...

>Linear is another natural growth curve.

>
except that linear is not a curve...

Check the definition of a curve in maths and you will find that it *is*
a curve. You will also find plenty of other growth curves in nature if
you look.

>>>The best growth curve depends on the situation. For some thing I know
>>>that in the foreseeable future I need space for 10 foos and if it grows
>>>beyond that it will be unlikely to be by much, so I start with 10 and
>>>use a small linear growth (saves having to revisit the code unless
>>>something very strange happens). For other things that would be
>>>completely stupid.
>>yeah...

>Ah, so you realise now that suggesting a 4/3 curve makes less sense than
>suggesting using a curve that will give good performance. My example above
>was extreme, but there are plenty of less extreme examples.

>
the question is then what curve gives the best performance, which may depend
on the situation.
it is a tradeoff really between number of reallocations and wasted space.
>
4/3 is more conservative with space than 3/2, which is still more
conservative than the golden ratio.
>
so the question is then of rate of growth and likelyhood of continued
growth.

Not only the likelihood of continued growth, but how much it is likely
to grow if it does grow. All of which was one of my points. Why when
someone says you need to select the best growth curve would you
"correct" that to saying they should use some specific growth curve when
you don't know the details of what the input is?

and, for the previous topic:
it is by some odd convention that when we see a division by undivisible
integers that we realize that it has a non-integer output.

Not if you know C you don't. Or Pascal. Or Modula 2. Or assembler. If
you see integer division you expect an integer result because you know
that when working in integers you are working in integers.

I guess it is also by similar convention that we realize that negative even
roots are imaginary and that non-integral exponents of negative bases are
complex...

All completely irrelevant to the point. Why use something dependant on
*representation * when there is a more natural operator for scaling, i.e.
something that does not depend on representation.

>--
>Flash Gordon

Please don't quote signatures, the bit typically after a "-- ", unless
you are commenting on them.
--
Flash Gordon

**cr88192** · Aug 25 '07, 04:15 AM

Re: Dynamically resizing a buffer

"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:egn3q4x16e .ln2@news.flash-gordon.me.uk...

cr88192 wrote, On 24/08/07 02:46:

>"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
>news:1ru0q4xk0 o.ln2@news.flas h-gordon.me.uk...

>>cr88192 wrote, On 23/08/07 16:09:
>>>"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
>>>news:ck60q4x 2tf.ln2@news.fl ash-gordon.me.uk...
>>>>cr88192 wrote, On 23/08/07 11:12:
>>><snip>
>>>>
>>>>>not optimizations. shifts are how one typically does these things...
>>>>Not if one is being sensible.
>>>>>
>>>>>it is much the same as why we call int variables i, j, and k I think,
>>>>>or many other common practices. after enough years, and enough code,
>>>>>one largely forgets any such reasoning, all rote response really...
>>>>I have spent years programming in assembler where I would use shifts
>>>>and years spent programming in high level languages where I would not.
>>>yeah, I also use assembler...
>>>>
>>>otherwise:
>>>>
>>>I always used shifts, never thought much of it.
>>>I use shifts where I think shifts, I had never thought to think
>>>divides...
>>>>
>>>if I were thinking of a divide, than i/3 is an obvious difference from
>>>i/2. if I was not, it is not.
>>>it is a non-obvious jump from 'i>>1' to 'i/3', unless one first thinks
>>>that 'i>>1' is actually 'i/2'...
>>You are trying to reduce a number by a factor not trying to move bits.
>>They are conceptually different things. Try using a shit to halve a
>>floating point number as see how far it gets you.
>>>

>>
>but, a float and an integer are different concepts though...
>not sure of why one would consider using a shift on a float...

>
Because you consider shift an appropriate method of halving a number.
>

as noted, if that number is an integer.

I personally regard integers and non-integers as different concepts, with
different behaviors, semantics, and rules.

after all, with integers, 3/4==0, but with non-integers or reals, the answer
is 0.75...

likewise I consider reals and complexes to be different concepts.

>>>>>actually , had I been thinking of compiler behavior much at all, I
>>>>>would have realized that 'i/3' actually becomes a fixed point
>>>>>multiply by a reciprocal. no such reasoning was used in this case.
>>>>>>
>>>>>this was a trivial and obvious mistake is all.
>>>>A trivial mistake that does not get made if you code what you want to
>>>>express instead of trying to use tricks. That is part of the point.
>>>'want to express'?...
>>>>
>>>this implies certain things, ie, that what I would want to express is
>>>different from the code I would write to express it.
>>Shift is for moving bits, divide is for scaling. Otherwise shift would
>>work on floating point and would have behaviour defined by the C
>>standard for negative numbers (it leaves it for the implementation to
>>define the result of right shifting a negative number).

>>
>ok, makes sense.

>
So will you move to the less error prone system then?
>

I write whatever I write really.
in the past, I have never really seen any major problem with it.

if there were some problem, as I percieve it, then I probably would have
changed it long ago (before writing many hundreds of kloc using these kind
of conventions).

>>>do you ask me, if my grammar is unusual, if it is because I am not
>>>writing what I am meaning to express?...
>>>>
>>>it is a similar question IMO...
>>No, it is a question of using the wrong word. One that in some
>>situations happens to be similar, but in many situations means something
>>completely different.

>>
>the situations are different though.
>as noted above, an integer and a float are conceptually different.
>if I am speaking to someone do I count in floats? no, I count in
>integers...

>
I measure sizes in all sorts of different systems not all of which are
integers.
>

lengths are reals, often.

sizes of arrays are not.
counting is not.

we don't say '3.85 apples' because one of them is small, or '4.25' because
one is large...
the count is 4 apples.

>>>>Whatever the reason for you learning to use such tricks it is well
>>>>past time you learned not to use them excpet where it is proved that
>>>>you need to.
>>>>>
>>>'tricks'?. ..
>>Yes, it is a trick.
>>>
>>>shifts are a basic operator, I don't see why they would be viewed as
>>>any kind of trick...
>>The shift operator is a basic operator for moving bits, using it to
>>divide is a trick and one that does not work in all situations.

>>
>it works on integers, integers are the context and the situation.
>sizes are generally not negative either.

>
They are sometimes.
If a spec says a number is in bits 3 to 7 then getting it to the correct
place is shifting.
>

I do this often as well.
for example, I have a good deal of packed-integer based types which I modify
via masks and shifts...

>there is no problem as I see it.

>
I thought you admitted to an error that would not be made if using simple
division. For one value you certainly suggested something more complex
than simple division.
>

yes, this was a faulty thought, something I would have likely noticed and
fixed later for looking stupid...

I think it was because I was thinking of percentages, and this is the
typical way I manipulate things via percentages.

'17% of i' ='(i*17)/100'.

"i's percentage of j" '((i*100)/j)'.

>>>do we call pointers and casts tricks as well?... typical code is
>>>riddled with the things, nothing sinister there...
>>Code riddled with casts probably is bad.
>>>
>>Code using a lot of shifts for shifting bits, NOT for division, could be
>>good.

>>
>ok, but then one has to differentiate: when is the concept shifting bits
>and when is it division?...
>this is a subjective matter.

>
I honestly cannot conceive of why one would consider shifting to be the
natural way of scaling a value. Would you convert from inches to
centimetres by shifting? Would you talk about doubling your salary or
shifting it one bit to the left? Would you tell someone that they you have
doubled the storage capacity of a disk array or shifted it one bit to the
left? Or that the free space has been shifted one bit to the right instead
of halved?
>

would probably not say it as such, but mentally I often use shifting in
performing calculations, as I find it easier than multiplication or
division.

Changing the size of a buffer is NOT linked to the representation of the
size, shifting is.
>

a buffer's size, however, is naturally constrained to being a positive
integer.

>>>now, does one think in terms of arithmetic ops or in terms of bitwise
>>>ops?...
>>No. However a shift works in terms of bits, not in terms of arithmetic.

>>
>but on integers, bit ops are arithmetic...

>
Nope. Right shift is a logical shift on some processors *not* arithmetic.
If anyone ever builds a trinary machine then the shift operation procided
by the processor will *not* be multiply/divide by 2. On a machine using
BCD it isn't either, and BCD has been used for representing integer
values.
>

maybe...

however, I reason, almost none of my crap is ever likely to be run on
something non-x86-based, much less something so far reachingly different,
which I would unlikely even consider coding for, assuming I ever even
encountered such a beast...

>makes nearly as much sense in conversation as it would in C.
>we ask someone 'what is 12 and 7?' they say '8'...

>
I can't see what point you are trying to make, unless it is why you should
*not* use a shift for scaling.
>

the operations make sense to humans as well, if they know them...

>>>does one do their everyday arithmetic (internally) in decimal or in
>>>hex?...
>>>>
>>>if we read something do we see the text, hear words, or see imagery?...
>>Several of the things above are reasons for using divide rather than
>>shift.

>>
>if one is confused as to whether not they are dealing with an integer...

>
You still keep forgetting that it only works for half the integer types C
provides, a sure sign in my opinion that you should stay well away from
the shift operator in C.
>

was never saying it provably worked on negative integers.
however, it does work in what compilers I am fammiliar with.

You are confused about values and specific representations . Binary is not
the only representation for numbers, it just happens to be the current
vogue in computing.
>

theoretical argument, maybe, but IMO of little practical concern. I don't
think binary will go away anytime soon, as doing so would break much of the
software in existence at this point, and assuming such a change occures, it
will not matter since the mass of software would have been being
rewritten/replaced anyways.

I say though, not only is it valid for computers, but also humans...

>what if I meant to grab an apple but instead grabbed a potatoe and
>proceeded to eat it as said apple. people would look oddly, and then
>maybe ones' stomach gets irritated from the raw potatoe...
>>
>so, casually eating an object raw is valid for an apple but not for said
>potatoe.
>likewise, we put potatoes in soup but not apples.
>>
>same difference really...

>
All valid analogies for why you should be using division for scaling not
shifting.
>
<snip philosophy ramblings that seem to have no bearing on the matter at
hand>
>

>>>this kind of issue has not come up in any time in recent memory...
>>The issue of you making a mistake that you would not have done had you
>>stuck to doing simple integer division is a good reason for using
>>integer division.

>>
>potentially, but this makes an assumption about ones' thought process.
>if one always types shifts, one thinks shifts, one does not think
>division unless one were first thinking of division, which I assert that
>I was not (which is why I think I missed such an obvious answer).

>
So if someone tells you to increase a buffer by 81% you would think in
terms of shifts?
>

naturally, I wouild have thought in one of the options I originally provided
'((i*81)/100)'.
why: because this value, as it so happens, does not have an integer
reciprocal.

>>>so, one thinks in hex and writes in decimal, or vice versa, not usually
>>>that important.
>>>and, if one happens to be thinking in hex right, then a shift is more
>>>intuitive than a divide.
>>What do you get if you right shift -1? On some machines it will be 32767
>>on others it will be -1. Does that sound like division to you?

>>
>different context.
>>
>one machine is probably an x86 in real mode with an int being 16 bits and
>using shr.
>the other is probably using sar.

>
Nope, one machine is not an x86 and does not have an arithmetic shift at
all.
>

ok, abstraction failing, it uses a 16 bit int.

>>>does one think of the money in their wallet as 300 or 0x12C?...
>>>does one think in british or metric units?...
>>>>
>>>or does one use whatever system happens to seem more natural at that
>>>instant?.. .
>>Not relevant since a shift is not a different representation for
>>division, it is a different operation.

>>
>it is an operation relevant to a situation, that situation being positive
>integers...

>
So when you have spent half your money do you think that you have shifted
your resources one bit to the right?
>

very often, this is how I reason about some things.

>I was not claiming it was also sane for floats or for negatives.

>
Why? They are just numbers. In any case, you keep referring to integers
rather than unsigned integers, so either you are repeatedly making a
mistake and therefore showing why you should not be using shift you you
are being sloppy in a way that leads to mistakes thus showing why using
shift is inadvisable.
>

'unsigned integer' is longer to type, however in context I repeatedly
indicate that the numbers are positive, an indication that, whether the
storage is an integer or unsigned integer, the value is constrained to be
positive.

'23>>1' is '11' regardless of it being an int or uint.

>>>up to them really. it only matters that when someone asks that they
>>>give the right number, and when they read that they don't get
>>>confused.. .
>>>>
>>>one typically doesn't know the magic going on even in ones' own head...
>>Code is written for other people, not just the original author or the
>>compiler.

>>
>maybe.
>if other people ever actually read said code.

>
You were advising on how someone else should do things, therefore someone
other than you *will* see the code.
>

well, this is usenet, not ones' codebase.

>>>>>4/3 is a natural growth curve. something around this ratio should
>>>>>presumab ly work good as a general mean case.
>>>>Exponenti al is also a natural growth curve, if you don't believe me
>>>>check how populations grow in nature, for at least some it is
>>>>exponenti al until a crash.
>>>when applied recursively, this is exponential...
>>Linear is another natural growth curve.

>>
>except that linear is not a curve...

>
Check the definition of a curve in maths and you will find that it *is* a
curve. You will also find plenty of other growth curves in nature if you
look.
>

x^2 is a curve.
2^x is a curve.
x^0.5 is a curve.

x is not, it is linear, and thus not a curve.

>>>>The best growth curve depends on the situation. For some thing I know
>>>>that in the foreseeable future I need space for 10 foos and if it
>>>>grows beyond that it will be unlikely to be by much, so I start with
>>>>10 and use a small linear growth (saves having to revisit the code
>>>>unless something very strange happens). For other things that would be
>>>>completel y stupid.
>>>yeah...
>>Ah, so you realise now that suggesting a 4/3 curve makes less sense than
>>suggesting using a curve that will give good performance. My example
>>above was extreme, but there are plenty of less extreme examples.

>>
>the question is then what curve gives the best performance, which may
>depend on the situation.
>it is a tradeoff really between number of reallocations and wasted space.
>>
>4/3 is more conservative with space than 3/2, which is still more
>conservative than the golden ratio.
>>
>so the question is then of rate of growth and likelyhood of continued
>growth.

>
Not only the likelihood of continued growth, but how much it is likely to
grow if it does grow. All of which was one of my points. Why when someone
says you need to select the best growth curve would you "correct" that to
saying they should use some specific growth curve when you don't know the
details of what the input is?
>

>and, for the previous topic:
>it is by some odd convention that when we see a division by undivisible
>integers that we realize that it has a non-integer output.

>
Not if you know C you don't. Or Pascal. Or Modula 2. Or assembler. If you
see integer division you expect an integer result because you know that
when working in integers you are working in integers.
>

I was talking about fractions or rationals here.

humans have a convention that division of 2 integers leads to a non-integer
rather than an integer, and that computers do not is a difference. it shows
that integers are not numbers in a strictly traditional sense, because the
behavior is different.

>I guess it is also by similar convention that we realize that negative
>even roots are imaginary and that non-integral exponents of negative
>bases are complex...

>
All completely irrelevant to the point. Why use something dependant on
*representation * when there is a more natural operator for scaling, i.e.
something that does not depend on representation.
>

representation is value, and implementation is definition...

>>--
>>Flash Gordon

>
Please don't quote signatures, the bit typically after a "-- ", unless you
are commenting on them.
--
Flash Gordon

**cr88192** · Aug 25 '07, 04:15 AM

Re: Dynamically resizing a buffer

"Peter J. Holzer" <hjp-usenet2@hjp.atw rote in message
news:slrnfctpph .vvs.hjp-usenet2@zeno.hj p.at...

On 2007-08-23 15:09, cr88192 <cr88192@hotmai l.comwrote:

>I always used shifts, never thought much of it.
>I use shifts where I think shifts, I had never thought to think
>divides...
>>
>>
>if I were thinking of a divide, than i/3 is an obvious difference from
>i/2.
>if I was not, it is not.
>it is a non-obvious jump from 'i>>1' to 'i/3', unless one first thinks
>that
>'i>>1' is actually 'i/2'...

>
But you were thinking of divides - you explicitely stated that you
wanted an increase of 50% (1/2), 33% (ca. 1/3) or 25% (1/4). Since 1/2,
1/3 and 1/4 is a nice progression, I find it much more likely that you
derived ((i>>2) + (i>>4) + (i>>6)) as an approximation of 1/3 than
the other way around. If you had been thinking of shifts, you would
probably have chosen ((i>>2) + (i>>3)) as the middle point between
(i>>1) and (i>>2).
>

odd assertion, however I am not sure how that chain of thought would work,
so was not likely employed in my case.

in any case, my memory has faded out now, I no longer remember.

Dynamically resizing a buffer

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment