set double array to 0.0

Hi ,

Is there a very efficient way to set a double array to 0 ?
(I have tried memset, but the result doesn't look correct.)

Carson

re: set double array to 0.0

Carson wrote:
[color=blue]
> Hi ,
>
> Is there a very efficient way to set a double array to 0 ?
> (I have tried memset, but the result doesn't look correct.)[/color]

Um try something along these lines

double myarray[SIZE], tmp;

tmp = 0.0;
memcpy(myarray, &tmp, sizeof(double));
memcpy(myarray+1, &tmp, sizeof(double));
memcpy(myarray+2, myarray, sizeof(double)*2);
memcpy(myarray+4, myarray, sizeof(double)*4);
memcpy(myarray+8, myarray, sizeof(double)*8);
memcpy(myarray+16, myarray, sizeof(double)*16);
.... until you cover SIZE

Tom

re: set double array to 0.0

In article <GwRTc.655$SR4.140@newssvr14.news.prodigy.com>,
"Carson" <carson@ieee.org> wrote:
[color=blue]
> Hi ,
>
> Is there a very efficient way to set a double array to 0 ?
> (I have tried memset, but the result doesn't look correct.)[/color]

Use a "for" loop. Works every time.

re: set double array to 0.0

Carson wrote:
[color=blue]
> Hi ,
>
> Is there a very efficient way to set a double array to 0 ?
> (I have tried memset, but the result doesn't look correct.)
>
> Carson[/color]
In my computer that's correct!

re: set double array to 0.0

"Carson" <carson@ieee.org> wrote:
# Hi ,
#
# Is there a very efficient way to set a double array to 0 ?
# (I have tried memset, but the result doesn't look correct.)

Most CPUs nowadays allow all zero bits as a real zero. Did you give memset
the right length?
double r[N];
memset(r,0,N*sizeof(double));

There's a trick you can play with some implementations of memcpy.

Otherwise you have to set with some kind loop.


--
SM Ryan http://www.rawbw.com/~wyrmwif/
A bunch of savages in this town.

re: set double array to 0.0

Carson wrote:[color=blue]
>
> Is there a very efficient way to set a double array to 0 ?
> (I have tried memset, but the result doesn't look correct.)[/color]

No, not and have the results meet the standards. Tou need
something like:

for (i = 0; i < size; i++) array[i] = 0.0;

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

re: set double array to 0.0

On Sun, 15 Aug 2004 22:33:10 GMT, "Carson" <carson@ieee.org> wrote in
comp.lang.c:
[color=blue]
> Hi ,
>
> Is there a very efficient way to set a double array to 0 ?
> (I have tried memset, but the result doesn't look correct.)
>
> Carson[/color]

If you are defining the array, you can merely do this:

double d [SIZE] = { 0 };

....and this will initialize each and every member to 0.0.

On the other hand, if you have a malloc'ed array, or you have an array
that has unknown data in it that needs to be cleared to 0.0, a for
loop is probably best if the array is small. If it is very large,
this might be faster:

d [0] = 0; /* or 0.0, if you prefer */
memmove(d + 1, d, sizeof(double) * (SIZE - 1));

Using memmove() instead of memcpy() guarantees defined behavior even
though the source and destination areas overlap.

You would need to run timing tests on your particular
compiler/hardware combination to find out at what array size, if any,
the memmove() version becomes faster and by how much.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

re: set double array to 0.0

"Carson" <carson@ieee.org> writes:[color=blue]
> Is there a very efficient way to set a double array to 0 ?
> (I have tried memset, but the result doesn't look correct.)[/color]

If you called memset with the right arguments, I would expect you to
see 0.0 in all entries on almost all systems. (Did you remember to
multiply the length by sizeof(double)?) But the standard doesn't
guarantee that 0.0 is represented as all-bits-zero, so using memset
isn't strictly portable.

Probably the best solution is the simplest:

for (i = 0; i < LEN; i ++) {
arr[i] = 0.0;
}

See whether that's fast enough before you try something more
complicated.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

re: set double array to 0.0

Jack Klein <jackklein@spamcop.net> wrote:
[color=blue]
> d [0] = 0; /* or 0.0, if you prefer */
> memmove(d + 1, d, sizeof(double) * (SIZE - 1));[/color]

IMHO it won't work, unless I'm missing something very obvious.
(Values d[1], d[2]... are undetermined, and are copied
into positions d+2, d+3...)

--
Stan Tobias
sed 's/[A-Z]//g' to email

re: set double array to 0.0

Tom St Denis wrote:
[color=blue]
> Carson wrote:
>
>[color=green]
>>Hi ,
>>
>> Is there a very efficient way to set a double array to 0 ?
>> (I have tried memset, but the result doesn't look correct.)[/color]
>
>
> Um try something along these lines
>
> double myarray[SIZE], tmp;
>
> tmp = 0.0;
> memcpy(myarray, &tmp, sizeof(double));
> memcpy(myarray+1, &tmp, sizeof(double));
> memcpy(myarray+2, myarray, sizeof(double)*2);
> memcpy(myarray+4, myarray, sizeof(double)*4);
> memcpy(myarray+8, myarray, sizeof(double)*8);
> memcpy(myarray+16, myarray, sizeof(double)*16);
> ... until you cover SIZE
>
> Tom[/color]

I believe that a simple "for" loop would be much
easier to understand and probably more efficient
{since the function call overhead is removed).

unsigned int i;
for (i = 0; i < SIZE; ++i)
{
myarray[i] = 0.0;
}


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

re: set double array to 0.0

On 16 Aug 2004 10:05:33 GMT, "S.Tobias" <sNOiSPAMt@amu.edu.pl> wrote
in comp.lang.c:
[color=blue]
> Jack Klein <jackklein@spamcop.net> wrote:
>[color=green]
> > d [0] = 0; /* or 0.0, if you prefer */
> > memmove(d + 1, d, sizeof(double) * (SIZE - 1));[/color]
>
> IMHO it won't work, unless I'm missing something very obvious.
> (Values d[1], d[2]... are undetermined, and are copied
> into positions d+2, d+3...)[/color]

But they are not undetermined. memmove(), as opposed to memcpy(), is
specified to copy properly when the source and destination areas
overlap, as in this case. If they overlap, it is guaranteed to read
and copy the old value of each byte before overwriting the byte with
its new value.

So the first byte of d [1] will have the value of the first byte of d
[0] before it is copied into the first byte of d [2], and so on. This
is perfectly legal and has a completely defined result.

On the other hand, memcpy() has undefined behavior if the source and
destination areas overlap. There is no guarantee that the first byte
of d [0] is copied into the first byte of d [1] before that byte in
turn is copied into the first byte of d [2].

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

re: set double array to 0.0

On Mon, 16 Aug 2004 21:25:09 -0500, Jack Klein <jackklein@spamcop.net>
wrote:
[color=blue]
>On 16 Aug 2004 10:05:33 GMT, "S.Tobias" <sNOiSPAMt@amu.edu.pl> wrote
>in comp.lang.c:
>[color=green]
>> Jack Klein <jackklein@spamcop.net> wrote:
>>[color=darkred]
>> > d [0] = 0; /* or 0.0, if you prefer */
>> > memmove(d + 1, d, sizeof(double) * (SIZE - 1));[/color]
>>
>> IMHO it won't work, unless I'm missing something very obvious.
>> (Values d[1], d[2]... are undetermined, and are copied
>> into positions d+2, d+3...)[/color]
>
>But they are not undetermined. memmove(), as opposed to memcpy(), is
>specified to copy properly when the source and destination areas
>overlap, as in this case. If they overlap, it is guaranteed to read
>and copy the old value of each byte before overwriting the byte with
>its new value.[/color]

It is true that memmove supports overlapping operands.
[color=blue]
>
>So the first byte of d [1] will have the value of the first byte of d
>[0] before it is copied into the first byte of d [2], and so on. This
>is perfectly legal and has a completely defined result.[/color]

Unless something changed from n869, this conclusion is wrong. From
7.21.2.2-2: "Copying takes place as if the n characters from the
object pointed to by s2 are first copied into a temporary array of n
characters that does not overlap the objects pointed to by s1 and s2,
and then the n characters from the temporary array are copied into the
object pointed to by s1."

Since memmove acts as if the source bytes are copied first, they will
have undetermined values. Since they are not being evaluated, I don't
know if the behavior is undefined.


<<Remove the del for email>>

re: set double array to 0.0

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnekm74rwn.fsf@nuthaus.mib.org...[color=blue]
> "Carson" <carson@ieee.org> writes:[color=green]
> > Is there a very efficient way to set a double array to 0 ?
> > (I have tried memset, but the result doesn't look correct.)[/color]
>
> If you called memset with the right arguments, I would expect you to
> see 0.0 in all entries on almost all systems. (Did you remember to
> multiply the length by sizeof(double)?) But the standard doesn't
> guarantee that 0.0 is represented as all-bits-zero, so using memset
> isn't strictly portable.
>
> Probably the best solution is the simplest:
>
> for (i = 0; i < LEN; i ++) {
> arr[i] = 0.0;
> }
>
> See whether that's fast enough before you try something more
> complicated.[/color]

I agree. I just tested this code with VC7 and the loop was reduced to a 'REP
STOSD' instruction, which clearly is faster than calling memset. In debug
mode the generated code was terrible, but that's OK.

Dag
[color=blue]
>
> --
> Keith Thompson (The_Other_Keith) kst-u@mib.org[/color]
<http://www.ghoti.net/~kst>[color=blue]
> San Diego Supercomputer Center <*>[/color]
<http://users.sdsc.edu/~kst>[color=blue]
> We must do something. This is something. Therefore, we must do this.[/color]

re: set double array to 0.0

Dag Viken wrote:
[color=blue]
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnekm74rwn.fsf@nuthaus.mib.org...[color=green]
>> "Carson" <carson@ieee.org> writes:[color=darkred]
>> > Is there a very efficient way to set a double array to 0 ?
>> > (I have tried memset, but the result doesn't look correct.)[/color]
>>
>> If you called memset with the right arguments, I would expect you to
>> see 0.0 in all entries on almost all systems. (Did you remember to
>> multiply the length by sizeof(double)?) But the standard doesn't
>> guarantee that 0.0 is represented as all-bits-zero, so using memset
>> isn't strictly portable.
>>
>> Probably the best solution is the simplest:
>>
>> for (i = 0; i < LEN; i ++) {
>> arr[i] = 0.0;
>> }
>>
>> See whether that's fast enough before you try something more
>> complicated.[/color]
>
> I agree. I just tested this code with VC7 and the loop was reduced to a
> 'REP STOSD' instruction, which clearly is faster than calling memset. In
> debug mode the generated code was terrible, but that's OK.[/color]

OT but...

GCC will do a fairly awesome job with memcpy/memset functions. When the
goal is speed it will usually unroll/inline the function call. The GCC
3.4.1 tree is even smart enough to rotate free regs e.g.

movl (%esi),%eax
movl %eax,(%edi)
movl 4(%esi),%ebx
movl %ebx,4(%edi)
movl 8(%esi),%ecx
movl %ecx,8(%edi)
// etc...

Tom

re: set double array to 0.0

In article <9mq2i0hj8o57io8r8s88f8lhdk8m5j1hie@4ax.com>,
Jack Klein <jackklein@spamcop.net> wrote:
[color=blue]
> On 16 Aug 2004 10:05:33 GMT, "S.Tobias" <sNOiSPAMt@amu.edu.pl> wrote
> in comp.lang.c:
>[color=green]
> > Jack Klein <jackklein@spamcop.net> wrote:
> >[color=darkred]
> > > d [0] = 0; /* or 0.0, if you prefer */
> > > memmove(d + 1, d, sizeof(double) * (SIZE - 1));[/color]
> >
> > IMHO it won't work, unless I'm missing something very obvious.
> > (Values d[1], d[2]... are undetermined, and are copied
> > into positions d+2, d+3...)[/color]
>
> But they are not undetermined. memmove(), as opposed to memcpy(), is
> specified to copy properly when the source and destination areas
> overlap, as in this case. If they overlap, it is guaranteed to read
> and copy the old value of each byte before overwriting the byte with
> its new value.[/color]

memmove () behaves exactly as if you malloc'ed a block of memory that is
big enough, memcpy from src to that buffer and then memcpy back from
that buffer to dst, then free'ing the block.

If memmove worked as you describe it then I would pray that it is
removed from the C Standard Library.

re: set double array to 0.0

Jack Klein <jackklein@spamcop.net> writes:[color=blue]
> On 16 Aug 2004 10:05:33 GMT, "S.Tobias" <sNOiSPAMt@amu.edu.pl> wrote
> in comp.lang.c:
>[color=green]
> > Jack Klein <jackklein@spamcop.net> wrote:
> >[color=darkred]
> > > d [0] = 0; /* or 0.0, if you prefer */
> > > memmove(d + 1, d, sizeof(double) * (SIZE - 1));[/color]
> >
> > IMHO it won't work, unless I'm missing something very obvious.
> > (Values d[1], d[2]... are undetermined, and are copied
> > into positions d+2, d+3...)[/color]
>
> But they are not undetermined. memmove(), as opposed to memcpy(), is
> specified to copy properly when the source and destination areas
> overlap, as in this case. If they overlap, it is guaranteed to read
> and copy the old value of each byte before overwriting the byte with
> its new value.[/color]

Um, no. I don't think "properly" means what you think it means in
this context.

I've seen Unix man pages that say something like:

The memmove() function copies n bytes from memory areas s2
to s1. Copying between objects that overlap will take place
correctly. It returns s1.

without defining what "correctly" means. If you're depending on a
description like that, I can see why you might think it copies
byte-by-byte.

Here's what the standard says (C99 7.21.2.2):

The memmove function copies n characters from the object pointed
to by s2 into the object pointed to by s1. Copying takes place as
if the n characters from the object pointed to by s2 are first
copied into a temporary array of n characters that does not
overlap the objects pointed to by s1 and s2, and then the n
characters from the temporary array are copied into the object
pointed to by s1.

I've seen a trick similar to what you suggest, but using memcpy() or a
similar function -- but it works only if copying is done from low to
high addresses, something not guaranteed by the standard.

(In real life, memmove() is likely to check whether the source and
destination overlap, choosing an order that avoids problems. There's
no portable way to do that without invoking undefined behavior, but
the memmove() implementation is free to use non-portable tricks.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

re: set double array to 0.0

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnoelaumx1.fsf@nuthaus.mib.org...
[color=blue]
> (In real life, memmove() is likely to check whether the source and
> destination overlap, choosing an order that avoids problems. There's
> no portable way to do that without invoking undefined behavior, but
> the memmove() implementation is free to use non-portable tricks.)[/color]

In any case, you are better off knowing your own data, and doing the
appropriate copying.

Has anyone done speed checks for mallocing a new chunk and copying the
correct data versus a memmove?

Who even does memmove? It sounds like sloppy programming to me. I mean does
the memory overlap or not?! If you don't know, why are you copying into it?

--
Mabden

re: set double array to 0.0

Hiho,

[color=blue][color=green]
>>(In real life, memmove() is likely to check whether the source and
>>destination overlap, choosing an order that avoids problems. There's
>>no portable way to do that without invoking undefined behavior, but
>>the memmove() implementation is free to use non-portable tricks.)[/color]
>
>
> In any case, you are better off knowing your own data, and doing the
> appropriate copying.
>
> Has anyone done speed checks for mallocing a new chunk and copying the
> correct data versus a memmove?
>
> Who even does memmove? It sounds like sloppy programming to me. I mean does
> the memory overlap or not?! If you don't know, why are you copying into it?[/color]

Hmmm, memmove() might be more efficient than everything you can come up
with. A naive way of implementing it is to calculate the overlap and
memcopy() just the highest non-critical number of bytes -- which might
lead to memcopy()ing all in one go. However, the system you are working
with might be in favor of a different way of doing it, say getting the
bytes to be copied up or down to a multiple of a certain number or even
more weird things, incorporating special tricks memcopy() does not
employ because they cost a couple of cycles too much but are exactly
the right thing here, etc.
So, memmove() probably is faster than repeated calls to memcopy().

Why someone might want to use it? Imagine having an array of structures.
You are quite happy with that array, need it to be an array because
a linked list or even an index array for a linked list is too slow for
your purposes. Then comes up one small nasty case where you have to
insert something into your array instead of appending it. You know there
will be only this one case, so you decide to stay with the array data
structure.
I, for one, would just memmove() the back end of the used data structure
to make room for my new entry -- provided the array is big enough, of
course. And I would not die regretting that as a programming sin.


Cheers,
Michael

re: set double array to 0.0

"Michael Mair" <mairRemove_for_mailinG@ians.uni-stuttgart.de> wrote in
message news:cfspk3$9i1$1@infosun2.rus.uni-stuttgart.de...[color=blue]
>[color=green][color=darkred]
> >>(In real life, memmove() is likely to check whether the source and
> >>destination overlap, choosing an order that avoids problems. There's
> >>no portable way to do that without invoking undefined behavior, but
> >>the memmove() implementation is free to use non-portable tricks.)[/color]
> >
> > In any case, you are better off knowing your own data, and doing the
> > appropriate copying.
> >
> > Has anyone done speed checks for mallocing a new chunk and copying the
> > correct data versus a memmove?
> >
> > Who even does memmove? It sounds like sloppy programming to me. I mean[/color][/color]
does[color=blue][color=green]
> > the memory overlap or not?! If you don't know, why are you copying into[/color][/color]
it?[color=blue]
>
> Hmmm, memmove() might be more efficient than everything you can come up
> with. A naive way of implementing it is to calculate the overlap and
> memcopy() just the highest non-critical number of bytes -- which might
> lead to memcopy()ing all in one go. However, the system you are working
> with might be in favor of a different way of doing it, say getting the
> bytes to be copied up or down to a multiple of a certain number or even
> more weird things, incorporating special tricks memcopy() does not
> employ because they cost a couple of cycles too much but are exactly
> the right thing here, etc.
> So, memmove() probably is faster than repeated calls to memcopy().[/color]

But why am I overlapping my data copies?
[color=blue]
> Why someone might want to use it? Imagine having an array of structures.
> You are quite happy with that array, need it to be an array because
> a linked list or even an index array for a linked list is too slow for
> your purposes. Then comes up one small nasty case where you have to
> insert something into your array instead of appending it. You know there
> will be only this one case, so you decide to stay with the array data
> structure.
> I, for one, would just memmove() the back end of the used data structure
> to make room for my new entry -- provided the array is big enough, of
> course. And I would not die regretting that as a programming sin.[/color]

Well, I see where you are coming from now, but I find it hard to believe an
index array can be very time consuming on modren computers. I suppose if you
had thousands of pointers, but then you would want a linked-list, wouldn't
you? And by then, you'd want an ISAM structure or something.

My point was, if it's small and known, you might be better off using a for
loop or two memcopy's, and if it's big enough then a memmove() is
inappropriate because you should be using something better.

Either way the programmer should control what happens. However, I have been
mistaken before.

--
Mabden
p.s. "modren" is my word for something quite modern that will be quickly
replaced by something better.

re: set double array to 0.0

On Tue, 17 Aug 2004 10:29:33 GMT
"Mabden" <mabden@sbc_global.net> wrote:
[color=blue]
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnoelaumx1.fsf@nuthaus.mib.org...
>[color=green]
> > (In real life, memmove() is likely to check whether the source and
> > destination overlap, choosing an order that avoids problems.
> > There's no portable way to do that without invoking undefined
> > behavior, but the memmove() implementation is free to use
> > non-portable tricks.)[/color]
>
> In any case, you are better off knowing your own data, and doing the
> appropriate copying.[/color]

If you know the regions overlap them using memmove IS doing the
appropriate copying.
[color=blue]
> Has anyone done speed checks for mallocing a new chunk and copying the
> correct data versus a memmove?[/color]

I doubt it.
[color=blue]
> Who even does memmove? It sounds like sloppy programming to me. I mean
> does the memory overlap or not?! If you don't know, why are you
> copying into it?[/color]

You use memmove when you KNOW the regions overlap, not just when it is
possible they overlap. One instances when you want to use memmove is
deleting from the middle of an array my shifting all the data back.

I do use memmove in some of my code because I do copying between regions
I know overlap.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

re: set double array to 0.0

On Tue, 17 Aug 2004 11:41:44 GMT
"Mabden" <mabden@sbc_global.net> wrote:
[color=blue]
> "Michael Mair" <mairRemove_for_mailinG@ians.uni-stuttgart.de> wrote in
> message news:cfspk3$9i1$1@infosun2.rus.uni-stuttgart.de...[color=green]
> >[color=darkred]
> > >>(In real life, memmove() is likely to check whether the source and
> > >>destination overlap, choosing an order that avoids problems.
> > >There's>no portable way to do that without invoking undefined
> > >behavior, but>the memmove() implementation is free to use
> > >non-portable tricks.)
> > >
> > > In any case, you are better off knowing your own data, and doing
> > > the appropriate copying.
> > >
> > > Has anyone done speed checks for mallocing a new chunk and copying
> > > the correct data versus a memmove?
> > >
> > > Who even does memmove? It sounds like sloppy programming to me. I
> > > mean[/color][/color]
> does[color=green][color=darkred]
> > > the memory overlap or not?! If you don't know, why are you copying
> > > into[/color][/color]
> it?[color=green]
> >
> > Hmmm, memmove() might be more efficient than everything you can come
> > up with. A naive way of implementing it is to calculate the overlap
> > and memcopy() just the highest non-critical number of bytes -- which
> > might lead to memcopy()ing all in one go. However, the system you
> > are working with might be in favor of a different way of doing it,
> > say getting the bytes to be copied up or down to a multiple of a
> > certain number or even more weird things, incorporating special
> > tricks memcopy() does not employ because they cost a couple of
> > cycles too much but are exactly the right thing here, etc.
> > So, memmove() probably is faster than repeated calls to memcopy().[/color]
>
> But why am I overlapping my data copies?[/color]

One reason was given just below this question. What is wrong with the
given reason?
[color=blue][color=green]
> > Why someone might want to use it? Imagine having an array of
> > structures. You are quite happy with that array, need it to be an
> > array because a linked list or even an index array for a linked list
> > is too slow for your purposes. Then comes up one small nasty case
> > where you have to insert something into your array instead of
> > appending it. You know there will be only this one case, so you
> > decide to stay with the array data structure.
> > I, for one, would just memmove() the back end of the used data
> > structure to make room for my new entry -- provided the array is big
> > enough, of course. And I would not die regretting that as a
> > programming sin.[/color]
>
> Well, I see where you are coming from now, but I find it hard to
> believe an index array can be very time consuming on modren computers.[/color]

Why would you want to write a for loop and use indexing when you can
make a single library call?

Anyway, if a simple for loop is the most efficient method then the
library is likely to use that method.
[color=blue]
> I suppose if you had thousands of pointers, but then you would want a
> linked-list, wouldn't you? And by then, you'd want an ISAM structure
> or something.[/color]

When doing a text editor will you have a linked list of characters so
you can insert and delete characters? I think not. You might have a
linked list of blocks of of text, but you will still have to insert in
to and delete from the middle of a block, and the simple way to do that
is with memmove.
[color=blue]
> My point was, if it's small and known, you might be better off using a
> for loop or two memcopy's, and if it's big enough then a memmove() is
> inappropriate because you should be using something better.[/color]

Why write a loop or do a malloc/memcpy/memcpy/free (you can't use a
static buffer if the amount of data is variable) when a single memmove
will do the job correctly?
[color=blue]
> Either way the programmer should control what happens. However, I have
> been mistaken before.[/color]

When you call memmove you ARE in control. It is well defined what will
happen and you call it because that is the right thing to do.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

re: set double array to 0.0

"Mabden" <mabden@sbc_global.net> wrote in message
news:Y9mUc.4187$QJ3.3787@newssvr21.news.prodigy.co m...[color=blue]
> "Michael Mair" <mairRemove_for_mailinG@ians.uni-stuttgart.de> wrote in
> message news:cfspk3$9i1$1@infosun2.rus.uni-stuttgart.de...[color=green]
> >[color=darkred]
> > >>(In real life, memmove() is likely to check whether the source and
> > >>destination overlap, choosing an order that avoids problems. There's
> > >>no portable way to do that without invoking undefined behavior, but
> > >>the memmove() implementation is free to use non-portable tricks.)
> > >
> > > In any case, you are better off knowing your own data, and doing the
> > > appropriate copying.
> > >
> > > Has anyone done speed checks for mallocing a new chunk and copying the
> > > correct data versus a memmove?
> > >
> > > Who even does memmove? It sounds like sloppy programming to me. I mean[/color][/color]
> does[color=green][color=darkred]
> > > the memory overlap or not?! If you don't know, why are you copying[/color][/color][/color]
into[color=blue]
> it?[color=green]
> >
> > Hmmm, memmove() might be more efficient than everything you can come up
> > with. A naive way of implementing it is to calculate the overlap and
> > memcopy() just the highest non-critical number of bytes -- which might
> > lead to memcopy()ing all in one go. However, the system you are working
> > with might be in favor of a different way of doing it, say getting the
> > bytes to be copied up or down to a multiple of a certain number or even
> > more weird things, incorporating special tricks memcopy() does not
> > employ because they cost a couple of cycles too much but are exactly
> > the right thing here, etc.
> > So, memmove() probably is faster than repeated calls to memcopy().[/color]
>
> But why am I overlapping my data copies?
>[color=green]
> > Why someone might want to use it? Imagine having an array of structures.
> > You are quite happy with that array, need it to be an array because
> > a linked list or even an index array for a linked list is too slow for
> > your purposes. Then comes up one small nasty case where you have to
> > insert something into your array instead of appending it. You know there
> > will be only this one case, so you decide to stay with the array data
> > structure.
> > I, for one, would just memmove() the back end of the used data structure
> > to make room for my new entry -- provided the array is big enough, of
> > course. And I would not die regretting that as a programming sin.[/color]
>
> Well, I see where you are coming from now, but I find it hard to believe[/color]
an[color=blue]
> index array can be very time consuming on modren computers. I suppose if[/color]
you[color=blue]
> had thousands of pointers, but then you would want a linked-list, wouldn't
> you? And by then, you'd want an ISAM structure or something.
>
> My point was, if it's small and known, you might be better off using a for
> loop or two memcopy's, and if it's big enough then a memmove() is
> inappropriate because you should be using something better.
>
> Either way the programmer should control what happens. However, I have[/color]
been[color=blue]
> mistaken before.[/color]

The functions memmove() and memcpy() both copy data from the source buffer
to the destination buffer; the difference is that only memmove() is
guaranteed to copy overlapping buffers correctly. To do so memmove() just
needs to determine if data should be copied from low addresses to high
addresses or from high to low addresses. The test for that is fairly simple
as shown in this generic (non-optimized) routine from VC runtime library
source:

void * memmove(void * dst, const void * src, size_t count)
{
void * ret = dst;
if (dst <= src || (char *)dst >= ((char *)src + count)) {
/*
* Non-Overlapping Buffers or Overlapping with dst <= src
* copy from lower addresses to higher addresses
*/
while (count--) {
*(char *)dst = *(char *)src;
dst = (char *)dst + 1;
src = (char *)src + 1;
}
}
else {
/*
* Overlapping Buffers with dst > src
* copy from higher addresses to lower addresses
*/
dst = (char *)dst + count - 1;
src = (char *)src + count - 1;

while (count--) {
*(char *)dst = *(char *)src;
dst = (char *)dst - 1;
src = (char *)src - 1;
}
}
return(ret);
}

The generic memcpy() routine is just a subset of memmove():

void * memcpy (void * dst, const void * src, size_t count )
{
void * ret = dst;
/*
* copy from lower addresses to higher addresses
*/
while (count--) {
*(char *)dst = *(char *)src;
dst = (char *)dst + 1;
src = (char *)src + 1;
}
return(ret);
}

The preceding functions should be portable but ineffective. Out of curiosity
I had a look at the optimized assembler source code in the VC runtime
library and surprise, surprise! memcpy() and memmove() are using the exact
same source code! This means that both functions perform memmove(). There is
no pure memcpy() available and frankly that is OK by me. memmove() must
handle overlap, and if memcpy() also does so, I do not think it conflicts
with the C standard, and the overhead is minimal. Of course this is system
dependent behavior.

My point is that memmove() can be used wherever memcpy() can be used but not
vice versa, unless the code relies on memcpy() behaving in a certain way.

Dag

re: set double array to 0.0

Dag Viken wrote:
[color=blue]
> "Mabden" <mabden@sbc_global.net> wrote in message
> news:Y9mUc.4187$QJ3.3787@newssvr21.news.prodigy.co m...
>[color=green]
>>"Michael Mair" <mairRemove_for_mailinG@ians.uni-stuttgart.de> wrote in
>>message news:cfspk3$9i1$1@infosun2.rus.uni-stuttgart.de...
>>[color=darkred]
>>>>>(In real life, memmove() is likely to check whether the source and
>>>>>destination overlap, choosing an order that avoids problems. There's
>>>>>no portable way to do that without invoking undefined behavior, but
>>>>>the memmove() implementation is free to use non-portable tricks.)
>>>>
>>>>In any case, you are better off knowing your own data, and doing the
>>>>appropriate copying.
>>>>
>>>>Has anyone done speed checks for mallocing a new chunk and copying the
>>>>correct data versus a memmove?
>>>>
>>>>Who even does memmove? It sounds like sloppy programming to me. I mean[/color]
>>
>>does
>>[color=darkred]
>>>>the memory overlap or not?! If you don't know, why are you copying[/color][/color]
>
> into
>[color=green]
>>it?
>>[color=darkred]
>>>Hmmm, memmove() might be more efficient than everything you can come up
>>>with. A naive way of implementing it is to calculate the overlap and
>>>memcopy() just the highest non-critical number of bytes -- which might
>>>lead to memcopy()ing all in one go. However, the system you are working
>>>with might be in favor of a different way of doing it, say getting the
>>>bytes to be copied up or down to a multiple of a certain number or even
>>>more weird things, incorporating special tricks memcopy() does not
>>>employ because they cost a couple of cycles too much but are exactly
>>>the right thing here, etc.
>>>So, memmove() probably is faster than repeated calls to memcopy().[/color]
>>
>>But why am I overlapping my data copies?
>>
>>[color=darkred]
>>>Why someone might want to use it? Imagine having an array of structures.
>>>You are quite happy with that array, need it to be an array because
>>>a linked list or even an index array for a linked list is too slow for
>>>your purposes. Then comes up one small nasty case where you have to
>>>insert something into your array instead of appending it. You know there
>>>will be only this one case, so you decide to stay with the array data
>>>structure.
>>>I, for one, would just memmove() the back end of the used data structure
>>>to make room for my new entry -- provided the array is big enough, of
>>>course. And I would not die regretting that as a programming sin.[/color]
>>
>>Well, I see where you are coming from now, but I find it hard to believe[/color]
>
> an
>[color=green]
>>index array can be very time consuming on modren computers. I suppose if[/color]
>
> you
>[color=green]
>>had thousands of pointers, but then you would want a linked-list, wouldn't
>>you? And by then, you'd want an ISAM structure or something.
>>
>>My point was, if it's small and known, you might be better off using a for
>>loop or two memcopy's, and if it's big enough then a memmove() is
>>inappropriate because you should be using something better.
>>
>>Either way the programmer should control what happens. However, I have[/color]
>
> been
>[color=green]
>>mistaken before.[/color]
>
>
> The functions memmove() and memcpy() both copy data from the source buffer
> to the destination buffer; the difference is that only memmove() is
> guaranteed to copy overlapping buffers correctly. To do so memmove() just
> needs to determine if data should be copied from low addresses to high
> addresses or from high to low addresses. The test for that is fairly simple
> as shown in this generic (non-optimized) routine from VC runtime library
> source:
>
> void * memmove(void * dst, const void * src, size_t count)
> {
> void * ret = dst;
> if (dst <= src || (char *)dst >= ((char *)src + count)) {
> /*
> * Non-Overlapping Buffers or Overlapping with dst <= src
> * copy from lower addresses to higher addresses
> */
> while (count--) {
> *(char *)dst = *(char *)src;
> dst = (char *)dst + 1;
> src = (char *)src + 1;
> }
> }
> else {
> /*
> * Overlapping Buffers with dst > src
> * copy from higher addresses to lower addresses
> */
> dst = (char *)dst + count - 1;
> src = (char *)src + count - 1;
>
> while (count--) {
> *(char *)dst = *(char *)src;
> dst = (char *)dst - 1;
> src = (char *)src - 1;
> }
> }
> return(ret);
> }
>
> The generic memcpy() routine is just a subset of memmove():
>
> void * memcpy (void * dst, const void * src, size_t count )
> {
> void * ret = dst;
> /*
> * copy from lower addresses to higher addresses
> */
> while (count--) {
> *(char *)dst = *(char *)src;
> dst = (char *)dst + 1;
> src = (char *)src + 1;
> }
> return(ret);
> }
>
> The preceding functions should be portable but ineffective. Out of curiosity
> I had a look at the optimized assembler source code in the VC runtime
> library and surprise, surprise! memcpy() and memmove() are using the exact
> same source code! This means that both functions perform memmove(). There is
> no pure memcpy() available and frankly that is OK by me. memmove() must
> handle overlap, and if memcpy() also does so, I do not think it conflicts
> with the C standard, and the overhead is minimal. Of course this is system
> dependent behavior.
>
> My point is that memmove() can be used wherever memcpy() can be used but not
> vice versa, unless the code relies on memcpy() behaving in a certain way.[/color]

<OT>
VC supports a pragma named intrinsic, which you can use to tell VC to
inline some commonly used functions. memcpy() is one of those functions,
memmove() is not(VC 6.0). This means that using memcpy() instead of
memmove() *may* result in a faster/smaller executable.
</OT>

boa@home

[color=blue]
>
> Dag
>
>[/color]

re: set double array to 0.0

"Dag Viken" <dag.viken@earthlink.net> writes:
[color=blue]
> memmove() must handle overlap, and if memcpy() also does so, I
> do not think it conflicts with the C standard, and the overhead
> is minimal. Of course this is system dependent behavior.[/color]

My favorite behavior for this kind of thing is for memcpy() to
check whether the regions overlap and give a big fat warning at
runtime if so (but only if I compile in "debug mode"). It would
then be preferable for it to do the right thing (e.g. act like
memmove()).

Note that there is no efficient (O(1)) and portable way for
memcpy() to detect whether the regions passed in overlap.
--
Ben Pfaff
email: blp@cs.stanford.edu
web: http://benpfaff.org

re: set double array to 0.0

In article <lnoelaumx1.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:
[color=blue]
> (In real life, memmove() is likely to check whether the source and
> destination overlap, choosing an order that avoids problems. There's
> no portable way to do that without invoking undefined behavior, but
> the memmove() implementation is free to use non-portable tricks.)[/color]

There is a portable way, but it takes n pointer comparisons :-( (You'd
have to compare src, src+1, src+2 etc to dst and dst, dst+1, dst+2 etc.
to src).

re: set double array to 0.0

In article <h6lUc.5159$Ov2.1532@newssvr27.news.prodigy.com> ,
"Mabden" <mabden@sbc_global.net> wrote:
[color=blue]
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnoelaumx1.fsf@nuthaus.mib.org...
>[color=green]
> > (In real life, memmove() is likely to check whether the source and
> > destination overlap, choosing an order that avoids problems. There's
> > no portable way to do that without invoking undefined behavior, but
> > the memmove() implementation is free to use non-portable tricks.)[/color]
>
> In any case, you are better off knowing your own data, and doing the
> appropriate copying.
>
> Has anyone done speed checks for mallocing a new chunk and copying the
> correct data versus a memmove?
>
> Who even does memmove? It sounds like sloppy programming to me. I mean does
> the memory overlap or not?! If you don't know, why are you copying into it?[/color]

You use memmove for example to insert data into an array. For example,
if n elements of an array are used, and you want to insert an element at
index i, then you call

memmove (&a [i+1], &a [i], (n - i) * sizeof (a [0]));

re: set double array to 0.0

"Mabden" <mabden@sbc_global.net> writes:
[color=blue]
> Who even does memmove? It sounds like sloppy programming to me. I mean does
> the memory overlap or not?! If you don't know, why are you copying into it?[/color]

I used memmove() a few days ago to implement scrolling in a
framebuffer. In that case, I knew that the memory overlapped,
which meant that memmove() was the appropriate function to use.
--
Ben Pfaff
email: blp@cs.stanford.edu
web: http://benpfaff.org

re: set double array to 0.0

Dag Viken wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> The functions memmove() and memcpy() both copy data from the
> source buffer to the destination buffer; the difference is that
> only memmove() is guaranteed to copy overlapping buffers
> correctly. To do so memmove() just needs to determine if data
> should be copied from low addresses to high addresses or from
> high to low addresses. The test for that is fairly simple as
> shown in this generic (non-optimized) routine from VC runtime
> library source:
>
> void * memmove(void * dst, const void * src, size_t count)
> {
> void * ret = dst;
> if (dst <= src || (char *)dst >= ((char *)src + count)) {
> /*
> * Non-Overlapping Buffers or Overlapping with dst <= src
> * copy from lower addresses to higher addresses
> */
> while (count--) {
> *(char *)dst = *(char *)src;
> dst = (char *)dst + 1;
> src = (char *)src + 1;
> }
> }
> else {
> /*
> * Overlapping Buffers with dst > src
> * copy from higher addresses to lower addresses
> */
> dst = (char *)dst + count - 1;
> src = (char *)src + count - 1;
>
> while (count--) {
> *(char *)dst = *(char *)src;
> dst = (char *)dst - 1;
> src = (char *)src - 1;
> }
> }
> return(ret);
> }[/color]

The code you show is intrinsically invalid. You cannot compare
void * pointers for anything but equality. The initial portion
could read (but is still wrong):

void *memmove(void * dest, const void * sorc, size_t count)
{
unsigned char *dst = dest;
unsigned char *src = sorc;

after which you have no need for the 'ret' variable. Having done
the above you have a chance if the system has a flat memory, but
that is not guaranteed (you cannot compare pointers for other than
equality unless they are pointers within the same object). So the
whole setup process becomes system dependant, and is why this
function is supplied by the system. The implementors know how to
detect overlap safely in their system.

Moral: Use the system provided routines.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

re: set double array to 0.0

CBFalconer <cbfalconer@yahoo.com> writes:
[...][color=blue]
> The code you show is intrinsically invalid. You cannot compare
> void * pointers for anything but equality.[/color]

Actually, I believe you can. For example, I believe the following
program:

#include <stdio.h>

int main(void)
{
char arr[100];
void *p0 = arr;
void *p1 = arr + 1;

if (p0 < p1) {
printf("ok\n");
}
else {
printf("Oops!\n");
}
return 0;
}

is portable and should print "ok".

That still leaves the problem of comparing pointers to different
objects, which of course can't be done portably (unless you're foolish
enough to do N equality comparisons).

But a particular implementation of memmove() is free to take advantage
of whatever system-specific tricks it can get away with, including
applying relational operators to pointers to different objects.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

re: set double array to 0.0

"Thomas Matthews" <Thomas_MatthewsSpitsOnSpamBots@sbcglobal.net> wrote in
message news:Qo3Uc.1576$GD7.3@newssvr32.news.prodigy.com.. .[color=blue]
> Tom St Denis wrote:
>[color=green]
> > Carson wrote:
> >
> >[color=darkred]
> >>Hi ,
> >>
> >> Is there a very efficient way to set a double array to 0 ?
> >> (I have tried memset, but the result doesn't look correct.)[/color]
> >
> >
> > Um try something along these lines
> >
> > double myarray[SIZE], tmp;
> >
> > tmp = 0.0;
> > memcpy(myarray, &tmp, sizeof(double));
> > memcpy(myarray+1, &tmp, sizeof(double));
> > memcpy(myarray+2, myarray, sizeof(double)*2);
> > memcpy(myarray+4, myarray, sizeof(double)*4);
> > memcpy(myarray+8, myarray, sizeof(double)*8);
> > memcpy(myarray+16, myarray, sizeof(double)*16);
> > ... until you cover SIZE
> >
> > Tom[/color]
>
> I believe that a simple "for" loop would be much
> easier to understand and probably more efficient
> {since the function call overhead is removed).
>
> unsigned int i;
> for (i = 0; i < SIZE; ++i)
> {
> myarray[i] = 0.0;
> }
>
>[/color]
As this NG is about C, not about specific implementations, this has to be
the best answer. If your compiler chooses to translate that into memset(),
knowing your target machine, fine. Your compiler may choose to translate
into parallel store instructions, should those be appropriate.

re: set double array to 0.0

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:412274CB.E189EFB1@yahoo.com...[color=blue]
>
> The code you show is intrinsically invalid. You cannot compare
> void * pointers for anything but equality. The initial portion
> could read (but is still wrong):
>
> void *memmove(void * dest, const void * sorc, size_t count)
> {
> unsigned char *dst = dest;
> unsigned char *src = sorc;
>
> after which you have no need for the 'ret' variable. Having done
> the above you have a chance if the system has a flat memory, but
> that is not guaranteed (you cannot compare pointers for other than
> equality unless they are pointers within the same object). So the
> whole setup process becomes system dependant, and is why this
> function is supplied by the system. The implementors know how to
> detect overlap safely in their system.
>
> Moral: Use the system provided routines.[/color]

Why not compare void* pointers? Is that in the C Standard? And what do you
mean by 'object' in the expression 'pointers within the same object'? Are
you thinking of segmented architectures? If so, yes, I assume a flat memory
model so in that sense the code is system dependant. Without flat memory I
think memcpy() would be faster than memmove(). Another assumption is that
memory is byte-addressable.

Note that the code was just meant as an example of how easily
memmove()/memcpy() could be implemented (assuming byte-addressable flat
memory). The code was found in the library source code provided with MS VC7.
The actual MS runtime library is using optimized assembler code, basically
doing the same as the example code, but employing optimizations such as
memory aligned copying and loop unrolling.

Finally, yes I do use the system routines.

Dag

re: set double array to 0.0

On Wed, 18 Aug 2004 09:10:23 GMT, "Dag Viken"
<dag.viken@earthlink.net> wrote:
[color=blue]
>"CBFalconer" <cbfalconer@yahoo.com> wrote in message
>news:412274CB.E189EFB1@yahoo.com...[color=green]
>>
>> The code you show is intrinsically invalid. You cannot compare
>> void * pointers for anything but equality. The initial portion
>> could read (but is still wrong):
>>
>> void *memmove(void * dest, const void * sorc, size_t count)
>> {
>> unsigned char *dst = dest;
>> unsigned char *src = sorc;
>>
>> after which you have no need for the 'ret' variable. Having done
>> the above you have a chance if the system has a flat memory, but
>> that is not guaranteed (you cannot compare pointers for other than
>> equality unless they are pointers within the same object). So the
>> whole setup process becomes system dependant, and is why this
>> function is supplied by the system. The implementors know how to
>> detect overlap safely in their system.
>>
>> Moral: Use the system provided routines.[/color]
>
>Why not compare void* pointers? Is that in the C Standard?[/color]

Yes. Other than == and !=, you cannot compare two pointers unless
they both point within the same object. Since void pointers do not
point to any object, they cannot meet the condition.
[color=blue]
>And what do you
>mean by 'object' in the expression 'pointers within the same object'? Are[/color]

If you have an array and the pointers point to elements or one byte
past the last element, then the pointers are pointing within the same
object. If you have a scalar object, such as an int, it can be
considered as an array of 1 element for the above discussion. If you
have a struct with the pointers pointing to members of the struct or
one byte beyond the end of the struct, then these pointers also point
within the same object. The obvious extension applies to arrays of
struct.
[color=blue]
>you thinking of segmented architectures? If so, yes, I assume a flat memory
>model so in that sense the code is system dependant. Without flat memory I[/color]

The C standard does not discuss memory models.
[color=blue]
>think memcpy() would be faster than memmove(). Another assumption is that[/color]

I think so also but the standard does not address this issue and it is
possible for a library to have a very good implementation for memmove
and a very poor one for memcpy.
[color=blue]
>memory is byte-addressable.[/color]

In C, memory is always byte addressable because sizeof(char) is always
1, regardless of how many bits a char contains.



<<Remove the del for email>>

re: set double array to 0.0

Barry Schwarz <schwarzb@deloz.net> writes:[color=blue]
> On Wed, 18 Aug 2004 09:10:23 GMT, "Dag Viken"
> <dag.viken@earthlink.net> wrote:[/color]
[...][color=blue][color=green]
> >Why not compare void* pointers? Is that in the C Standard?[/color]
>
> Yes. Other than == and !=, you cannot compare two pointers unless
> they both point within the same object. Since void pointers do not
> point to any object, they cannot meet the condition.[/color]

That's not quite right. void pointers can point to objects, and you
can do "<", ">", "<=", and ">=" comparions on two void pointers as
long as they both point to or within the same object (or just past the
end). C99 6.5.8, "Relational operators" specifically talks about
pointers to incomplete types (void is an incomplete type).

For example, after

void *ptr = malloc(42);

ptr points to an object (which doesn't happen to have an inherent
type).

But for purposes of implementing memmove(), you can't safely compare
the s1 and s2 arguments (other than for equality or inequality)
because you have no way of knowing whether they point into the same
object.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.