Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15021 > unrolled thread

rms from rosettacode

Back to article view | Back to comp.lang.c

Contents

  rms from rosettacode superpollo <superpollo@tznvy.pbz> - 2011-12-27 11:25 +0100
    Re: rms from rosettacode James Kuyper <jameskuyper@verizon.net> - 2011-12-27 06:48 -0500
      Re: rms from rosettacode superpollo <superpollo@tznvy.pbz> - 2011-12-27 13:01 +0100
        Re: rms from rosettacode James Kuyper <jameskuyper@verizon.net> - 2011-12-27 07:10 -0500
          Re: rms from rosettacode superpollo <superpollo@tznvy.pbz> - 2011-12-27 13:36 +0100
            Re: rms from rosettacode James Kuyper <jameskuyper@verizon.net> - 2011-12-27 10:04 -0500
      Re: rms from rosettacode Keith Thompson <kst-u@mib.org> - 2011-12-27 14:42 -0800
        Re: rms from rosettacode James Kuyper <jameskuyper@verizon.net> - 2011-12-27 18:46 -0500
    Re: rms from rosettacode 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-27 09:49 -0800
    Re: rms from rosettacode "BartC" <bc@freeuk.com> - 2011-12-27 18:14 +0000
      Re: rms from rosettacode superpollo <superpollo@tznvy.pbz> - 2011-12-27 19:33 +0100
        Re: rms from rosettacode jt@toerring.de (Jens Thoms Toerring) - 2011-12-27 19:04 +0000
          Re: rms from rosettacode Keith Thompson <kst-u@mib.org> - 2011-12-27 14:45 -0800
          Re: rms from rosettacode blp@cs.stanford.edu (Ben Pfaff) - 2011-12-27 14:57 -0800
        Re: rms from rosettacode "BartC" <bc@freeuk.com> - 2011-12-27 19:06 +0000
          Re: rms from rosettacode Bull in a China Blue Shop <chine.bleu@yahoo.com> - 2011-12-27 16:16 -0800
        Re: rms from rosettacode James Kuyper <jameskuyper@verizon.net> - 2011-12-27 14:11 -0500
        Re: rms from rosettacode Seebs <usenet-nospam@seebs.net> - 2011-12-27 20:13 +0000
        Re: rms from rosettacode Johann Klammer <klammerr@NOSPAM.aon.at> - 2011-12-28 00:23 +0100
        Re: rms from rosettacode 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-27 15:54 -0800
          Re: rms from rosettacode Keith Thompson <kst-u@mib.org> - 2011-12-27 22:53 -0800
            Re: rms from rosettacode Seebs <usenet-nospam@seebs.net> - 2011-12-28 06:29 +0000
            Re: rms from rosettacode 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-28 02:45 -0800
    Re: rms from rosettacode Kaz Kylheku <kaz@kylheku.com> - 2011-12-27 19:53 +0000
      Re: rms from rosettacode Seebs <usenet-nospam@seebs.net> - 2011-12-27 20:13 +0000
      Re: rms from rosettacode superpollo <superpollo@tznvy.pbz> - 2011-12-27 21:31 +0100
        Re: rms from rosettacode Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-27 20:49 -0500
          Re: rms from rosettacode superpollo <superpollo@tznvy.pbz> - 2011-12-28 11:42 +0100
            Re: rms from rosettacode Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-29 08:18 -0800
          Re: rms from rosettacode superpollo <superpollo@tznvy.pbz> - 2011-12-28 11:54 +0100
            Re: rms from rosettacode Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-12-29 04:12 +0200
              Re: rms from rosettacode superpollo <superpollo@tznvy.pbz> - 2011-12-29 14:38 +0100
          Re: rms from rosettacode Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 02:26 -0800
            Re: rms from rosettacode Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-28 21:35 -0500
              Re: rms from rosettacode superpollo <superpollo@tznvy.pbz> - 2011-12-29 14:10 +0100
          Re: rms from rosettacode James Kuyper <jameskuyper@verizon.net> - 2011-12-28 08:03 -0500
            Re: rms from rosettacode "BartC" <bc@freeuk.com> - 2011-12-28 13:32 +0000
              Re: rms from rosettacode Dr Nick <3-nospam@temporary-address.org.uk> - 2011-12-28 13:41 +0000
              Re: rms from rosettacode Kaz Kylheku <kaz@kylheku.com> - 2011-12-28 19:29 +0000
              Re: rms from rosettacode Keith Thompson <kst-u@mib.org> - 2011-12-28 13:47 -0800
              Re: rms from rosettacode Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-12-29 04:19 +0200
        Re: rms from rosettacode Kaz Kylheku <kaz@kylheku.com> - 2011-12-28 19:11 +0000

Page 1 of 3  [1] 2 3  Next page →

#15021 — rms from rosettacode

http://rosettacode.org/wiki/Averages/Root_mean_square#C


...
[~/superpollo]$ cat rms_rc.c
#include <stdio.h>
#include <math.h>

double rms(double *v, int n)
{
     int i;
     double sum = 0.0;
     for (i = 0; i < n; i++)
         sum += v[i] * v[i];
     return sqrt(sum / n);
}

int main()
{
     double v[] = { 1., 2., 3., 4., 5., 6., 7., 8., 9., 10. };
     printf("%f\n", rms(v, sizeof(v) / sizeof(double)));

     return 0;
}
[~/superpollo]$ cc -lm rms_rc.c && ./a.out
6.204837
...

that works fine, but i am quite unhappy with having to say to the rms 
function how big the array is... after all, i guess, shouldn't the 
function be able to figure it out herself? to i tried:

...
[~/superpollo]$ cat rms.c
#include <stdio.h>
#include <math.h>

double rms(double *v)
{
     const int n = sizeof(v) / sizeof(double);
     int i;
     double sum = 0.0;
     for (i = 0; i < n; i++)
         sum += v[i] * v[i];
     return sqrt(sum / n);
}

int main()
{
     double v[] = { 1., 2., 3., 4., 5., 6., 7., 8., 9., 10. };
     printf("%f\n", rms(v));

     return 0;
}
[~/superpollo]$ cc -lm rms.c && ./a.out
nan
[~/superpollo]$
...


what gives?

bye

-- 
- La verdad amigo, es que en tu sangre, tienes mierda!
- Es posible, pero la mierda viva es mejor que la mierda muerta...
- Amigo... la mierda, siempre mierda es!!

[toc] | [next] | [standalone]

#15023

On 12/27/2011 05:25 AM, superpollo wrote:
> http://rosettacode.org/wiki/Averages/Root_mean_square#C
> 
> 
> ...
> [~/superpollo]$ cat rms_rc.c
> #include <stdio.h>
> #include <math.h>
> 
> double rms(double *v, int n)
> {
>      int i;
>      double sum = 0.0;
>      for (i = 0; i < n; i++)
>          sum += v[i] * v[i];
>      return sqrt(sum / n);
> }
> 
> int main()
> {
>      double v[] = { 1., 2., 3., 4., 5., 6., 7., 8., 9., 10. };
>      printf("%f\n", rms(v, sizeof(v) / sizeof(double)));
> 
>      return 0;
> }
> [~/superpollo]$ cc -lm rms_rc.c && ./a.out
> 6.204837
> ...
> 
> that works fine, but i am quite unhappy with having to say to the rms 
> function how big the array is... after all, i guess, shouldn't the 
> function be able to figure it out herself?

How? The method you use below doesn't work. The only alternative I can
think of to passing in the length of the array is to put a sentinel
value at the end of the array like the null character at the end of a
string. For floating point values, nan() is a reasonable value to use,
in which case you can test for the end of the array using isnan(v[i]).

> ... to i tried:
> 
> ...
> [~/superpollo]$ cat rms.c
> #include <stdio.h>
> #include <math.h>
> 
> double rms(double *v)
> {
>      const int n = sizeof(v) / sizeof(double);

v is  pointer to double. sizeof(v) is therefore the same as
sizeof(double*). 'n' is therefore a fixed value:
sizeof(double*)/sizeof(double). It's value has nothing to do with how
long the array whose first member 'v' points at. On many systems, it
will have a value of 0.

>      int i;
>      double sum = 0.0;
>      for (i = 0; i < n; i++)
>          sum += v[i] * v[i];
>      return sqrt(sum / n);

If 'n' does have a value of zero, that division means that your program
has undefined behavior. Whether or not 'n' is 0 can be determined at
compile time, so a sufficiently smart compiler could even refuse to
compile your code.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#15024

James Kuyper ha scritto:
> On 12/27/2011 05:25 AM, superpollo wrote:
>> http://rosettacode.org/wiki/Averages/Root_mean_square#C
>>
>>
>> ...
>> [~/superpollo]$ cat rms_rc.c
>> #include <stdio.h>
>> #include <math.h>
>>
>> double rms(double *v, int n)
>> {
>>      int i;
>>      double sum = 0.0;
>>      for (i = 0; i < n; i++)
>>          sum += v[i] * v[i];
>>      return sqrt(sum / n);
>> }
>>
>> int main()
>> {
>>      double v[] = { 1., 2., 3., 4., 5., 6., 7., 8., 9., 10. };
>>      printf("%f\n", rms(v, sizeof(v) / sizeof(double)));
>>
>>      return 0;
>> }
>> [~/superpollo]$ cc -lm rms_rc.c && ./a.out
>> 6.204837
>> ...
>>
>> that works fine, but i am quite unhappy with having to say to the rms 
>> function how big the array is... after all, i guess, shouldn't the 
>> function be able to figure it out herself?
> 
> How?

just in the same way as "main" does. no?

bye

-- 
- La verdad amigo, es que en tu sangre, tienes mierda!
- Es posible, pero la mierda viva es mejor que la mierda muerta...
- Amigo... la mierda, siempre mierda es!!

[toc] | [prev] | [next] | [standalone]

#15025

On 12/27/2011 07:01 AM, superpollo wrote:
> James Kuyper ha scritto:
>> On 12/27/2011 05:25 AM, superpollo wrote:
>>> http://rosettacode.org/wiki/Averages/Root_mean_square#C
>>>
>>>
>>> ...
>>> [~/superpollo]$ cat rms_rc.c
>>> #include <stdio.h>
>>> #include <math.h>
>>>
>>> double rms(double *v, int n)
>>> {
>>>      int i;
>>>      double sum = 0.0;
>>>      for (i = 0; i < n; i++)
>>>          sum += v[i] * v[i];
>>>      return sqrt(sum / n);
>>> }
>>>
>>> int main()
>>> {
>>>      double v[] = { 1., 2., 3., 4., 5., 6., 7., 8., 9., 10. };
>>>      printf("%f\n", rms(v, sizeof(v) / sizeof(double)));
>>>
>>>      return 0;
>>> }
>>> [~/superpollo]$ cc -lm rms_rc.c && ./a.out
>>> 6.204837
>>> ...
>>>
>>> that works fine, but i am quite unhappy with having to say to the rms 
>>> function how big the array is... after all, i guess, shouldn't the 
>>> function be able to figure it out herself?
>>
>> How?
> 
> just in the same way as "main" does. no?

main() doesn't figure out the length itself; it's told the length by the
routine that calls main, by two different mechanisms: argc contains the
count of the arguments; since you're objecting to having to pass 'n' to
rms(), you should object, on the same ground, to the fact that the
implementation has to pass argc to main(). main() also uses the sentinel
value method I mentioned in the part of my message which you snipped:
argv[argc] is required to be a null pointer.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#15026

James Kuyper ha scritto:
> On 12/27/2011 07:01 AM, superpollo wrote:
>> James Kuyper ha scritto:
>>> On 12/27/2011 05:25 AM, superpollo wrote:
>>>> http://rosettacode.org/wiki/Averages/Root_mean_square#C
>>>>
>>>>
>>>> ...
>>>> [~/superpollo]$ cat rms_rc.c
>>>> #include <stdio.h>
>>>> #include <math.h>
>>>>
>>>> double rms(double *v, int n)
>>>> {
>>>>      int i;
>>>>      double sum = 0.0;
>>>>      for (i = 0; i < n; i++)
>>>>          sum += v[i] * v[i];
>>>>      return sqrt(sum / n);
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>      double v[] = { 1., 2., 3., 4., 5., 6., 7., 8., 9., 10. };
>>>>      printf("%f\n", rms(v, sizeof(v) / sizeof(double)));
>>>>
>>>>      return 0;
>>>> }
>>>> [~/superpollo]$ cc -lm rms_rc.c && ./a.out
>>>> 6.204837
>>>> ...
>>>>
>>>> that works fine, but i am quite unhappy with having to say to the rms 
>>>> function how big the array is... after all, i guess, shouldn't the 
>>>> function be able to figure it out herself?
>>> How?
>> just in the same way as "main" does. no?
> 
> main() doesn't figure out the length itself; it's told the length by the
> routine that calls main, by two different mechanisms: argc contains the
> count of the arguments; since you're objecting to having to pass 'n' to
> rms(), you should object, on the same ground, to the fact that the
> implementation has to pass argc to main(). main() also uses the sentinel
> value method I mentioned in the part of my message which you snipped:
> argv[argc] is required to be a null pointer.

i really cannot se how the "main()" arguments are related to the 
question, since "v[]" is declared INSIDE "main()".

on a related note: how can "sizeof" figure out the size of "v[]"? is 
there some sentinel implicitly at the end? if yes, why not passing it 
around to "rms()", so ther the finction can figure out the size herself? 
it does not seem to create such a big overhead, for instance.

bye

-- 
- La verdad amigo, es que en tu sangre, tienes mierda!
- Es posible, pero la mierda viva es mejor que la mierda muerta...
- Amigo... la mierda, siempre mierda es!!

[toc] | [prev] | [next] | [standalone]

#15027

On 12/27/2011 07:36 AM, superpollo wrote:
> James Kuyper ha scritto:
>> On 12/27/2011 07:01 AM, superpollo wrote:
>>> James Kuyper ha scritto:
>>>> On 12/27/2011 05:25 AM, superpollo wrote:
>>>>> http://rosettacode.org/wiki/Averages/Root_mean_square#C
>>>>>
>>>>>
>>>>> ...
>>>>> [~/superpollo]$ cat rms_rc.c
>>>>> #include <stdio.h>
>>>>> #include <math.h>
>>>>>
>>>>> double rms(double *v, int n)
>>>>> {
>>>>>      int i;
>>>>>      double sum = 0.0;
>>>>>      for (i = 0; i < n; i++)
>>>>>          sum += v[i] * v[i];
>>>>>      return sqrt(sum / n);
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>      double v[] = { 1., 2., 3., 4., 5., 6., 7., 8., 9., 10. };
>>>>>      printf("%f\n", rms(v, sizeof(v) / sizeof(double)));
>>>>>
>>>>>      return 0;
>>>>> }
>>>>> [~/superpollo]$ cc -lm rms_rc.c && ./a.out
>>>>> 6.204837
>>>>> ...
>>>>>
>>>>> that works fine, but i am quite unhappy with having to say to the rms 
>>>>> function how big the array is... after all, i guess, shouldn't the 
>>>>> function be able to figure it out herself?
>>>> How?
>>> just in the same way as "main" does. no?
>>
>> main() doesn't figure out the length itself; it's told the length by the
>> routine that calls main, by two different mechanisms: argc contains the
>> count of the arguments; since you're objecting to having to pass 'n' to
>> rms(), you should object, on the same ground, to the fact that the
>> implementation has to pass argc to main(). main() also uses the sentinel
>> value method I mentioned in the part of my message which you snipped:
>> argv[argc] is required to be a null pointer.
> 
> i really cannot se how the "main()" arguments are related to the 
> question, since "v[]" is declared INSIDE "main()".

I assumed that you were comparing the 'v' argument of rms() to the argv
argument often (but not necessarily) passed to main(). That would be a
valid comparison, and argument 'n' of rms() corresponds to the argc
argument of main(). I didn't realize that you're referring to the 'v'
defined inside of main(), because that v is irrelevant to your original
question - the fact that you think it's relevant is a symptom of your
misunderstanding of what's going on in this program.

The 'v' identifier in main() has block scope - it can only be referred
to inside the body of main(). The 'v' identifier in rms() has block
scope too; it can only be referred to in the parameter list or body of
rms(). Despite the fact that they have the same name, they identify
different objects, of different types. The 'v' in main() identifies an
array of 10 doubles. The 'v' in rms() identifies a pointer to double. I
general, those will have two very different sizes.

> on a related note: how can "sizeof" figure out the size of "v[]"?

When you use sizeof(v) inside of main, it gives you the size of the
array of 10 doubles named v. The compiler knows how big a double is, and
it knows that v[] contains 10 of them, so sizeof(v) just gives
10*sizeof(double), on many implementations, sizeof(double) is 8 - on
such implementations, sizeof(v) in main() would therefore be 80.

When you use sizeof(v) inside of rms, it will give you the size of the
pointer to double named 'v'. On many implementations, pointers are
generally 32-bit, and bytes are 8 bit, in which case sizeof(v) in rms()
would be 4.

> is 
> there some sentinel implicitly at the end? if yes, why not passing it 
> around to "rms()", so ther the finction can figure out the size herself? 
> it does not seem to create such a big overhead, for instance.

The C language leaves such details under your control; "sizeof
expression" only gives you the size of the object referred to by the
expression; if that object is a pointer to the first element of an
array, that will be the size of the pointer; in general, it won't be the
size of the array, and in the unlikely event that it is also the size of
the array, that's just a coincidence.


In a part of my message that you chose not to quote, I talked about n
having a value of sizeof(v)/sizeof(double), which corresponds to
sizeof(double*)/sizeof(double), an expression that has a value of 0 on
many systems. I must not have been fully awake yet when I wrote that.
sizeof(v) gives sizeof(double*) only in rms(); the only place where your
code divides sizeof() values is in main(). Please ignore that part of my
comments.

[toc] | [prev] | [next] | [standalone]

#15049

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> How? The method you use below doesn't work. The only alternative I can
> think of to passing in the length of the array is to put a sentinel
> value at the end of the array like the null character at the end of a
> string. For floating point values, nan() is a reasonable value to use,
> in which case you can test for the end of the array using isnan(v[i]).
[...]

Implementations aren't required to support NaNs.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15060

On 12/27/2011 05:42 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> How? The method you use below doesn't work. The only alternative I can
>> think of to passing in the length of the array is to put a sentinel
>> value at the end of the array like the null character at the end of a
>> string. For floating point values, nan() is a reasonable value to use,
>> in which case you can test for the end of the array using isnan(v[i]).
> [...]
> 
> Implementations aren't required to support NaNs.

True; my statement applies only to those that do.

In my own work, we can't assume support for NaNs, or even for C99
itself. We use different values in different contexts; for instance, we
use -999.0 as a fill value for floating point values representing angles
in the range -180.0 <= theta < 180.0.

[toc] | [prev] | [next] | [standalone]

#15028

superpollo於 2011年12月27日星期二UTC+8下午6時25分55秒寫道：
> http://rosettacode.org/wiki/Averages/Root_mean_square#C
> 
> 
> ...
> [~/superpollo]$ cat rms_rc.c
> #include <stdio.h>
> #include <math.h>
> 
> double rms(double *v, int n)
> {
>      int i;
>      double sum = 0.0;
>      for (i = 0; i < n; i++)
>          sum += v[i] * v[i];
>      return sqrt(sum / n);
> }
> 

caller responsible for n>0 and double *v allocation

> int main()
> {
>      double v[] = { 1., 2., 3., 4., 5., 6., 7., 8., 9., 10. };
>      printf("%f\n", rms(v, sizeof(v) / sizeof(double)));

check the stack allocation of v[ ]
> 
>      return 0;
> }
> [~/superpollo]$ cc -lm rms_rc.c && ./a.out
> 6.204837
> ...
> 
> that works fine, but i am quite unhappy with having to say to the rms 
> function how big the array is... after all, i guess, shouldn't the 
> function be able to figure it out herself? to i tried:
> 
> ...
> [~/superpollo]$ cat rms.c
> #include <stdio.h>
> #include <math.h>
> 
> double rms(double *v)
> {
>      const int n = sizeof(v) / sizeof(double);
>      int i;
>      double sum = 0.0;
>      for (i = 0; i < n; i++)
>          sum += v[i] * v[i];
>      return sqrt(sum / n);
> }

callee responsible for n to be right, but if it is wrong, then 
how does that callee throw???


 

 
> int main()
> {
>      double v[] = { 1., 2., 3., 4., 5., 6., 7., 8., 9., 10. };
>      printf("%f\n", rms(v));
> 
>      return 0;
> }

No need to free for v[ ] on the stack!

> [~/superpollo]$ cc -lm rms.c && ./a.out
> nan
> [~/superpollo]$
> ...

Merging all  control sanity checks in the caller is obvious.

[toc] | [prev] | [next] | [standalone]

#15029

"superpollo" <superpollo@tznvy.pbz> wrote in message 
news:4ef99d34$0$1379$4fafbaef@reader2.news.tin.it...
> http://rosettacode.org/wiki/Averages/Root_mean_square#C

> #include <stdio.h>
> #include <math.h>
>
> double rms(double *v)
> {
>     const int n = sizeof(v) / sizeof(double);
>     int i;
>     double sum = 0.0;
>     for (i = 0; i < n; i++)
>         sum += v[i] * v[i];
>     return sqrt(sum / n);
> }

> [~/superpollo]$ cc -lm rms.c && ./a.out
> nan

> what gives?

Try printing the value of n. You'll probably find it's zero. Your for-loop 
while keep going for quite a while, since it starts at i=0, and won't stop 
until i<0, perhaps two billion iterations later, by which time you will have 
long since breached the array bounds.

(BTW size(v) is just the number of bytes in a pointer. The array size must 
be made known explicity. Or you can use rand() to just guess the size; it 
will probably get it right more often than your code!)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#15030

BartC ha scritto:
> "superpollo" <superpollo@tznvy.pbz> wrote in message 
> news:4ef99d34$0$1379$4fafbaef@reader2.news.tin.it...
>> http://rosettacode.org/wiki/Averages/Root_mean_square#C
> 
>> #include <stdio.h>
>> #include <math.h>
>>
>> double rms(double *v)
>> {
>>     const int n = sizeof(v) / sizeof(double);
>>     int i;
>>     double sum = 0.0;
>>     for (i = 0; i < n; i++)
>>         sum += v[i] * v[i];
>>     return sqrt(sum / n);
>> }
> 
>> [~/superpollo]$ cc -lm rms.c && ./a.out
>> nan
> 
>> what gives?
> 
> Try printing the value of n. You'll probably find it's zero. Your 
> for-loop while keep going for quite a while, since it starts at i=0, and 
> won't stop until i<0, perhaps two billion iterations later, by which 
> time you will have long since breached the array bounds.
> 
> (BTW size(v) is just the number of bytes in a pointer. The array size 
> must be made known explicity. Or you can use rand() to just guess the 
> size; it will probably get it right more often than your code!)

so, to summarize: it is not possible for a function that gets an array 
passed to figure by herself the size, right? so the *idiomatic* way to 
give that info to the funtion should be that of the original rosettacode 
code, or is there another way?

bye

-- 
Chissa' perche' in un triangolo (5*5)/2=12.5
ci stanno 125 triangolini ???

[toc] | [prev] | [next] | [standalone]

#15033

superpollo <superpollo@tznvy.pbz> wrote:
> so, to summarize: it is not possible for a function that gets an array 
> passed to figure by herself the size, right?

Correct. And that's because you can't pass an array to a function,
that's simply not possible in C. All you can pass to a function is
a pointer to an element (typically the first) of an array (when you
call a function with an array as an argument the array is silently
converted to such a pointer to its first element). And with just
knowing the address of the first element of the array the function
can't determine the length of the array, thus you have to pass it
separately. Or, as it already has been pointed out, you could use
a sentinel element to mark the end of the array - but that re-
quires that a value existst that never can be a valid data value
of your array.

The only real way around that would be to wrap the array into
a structure - structures (in contrast to arrays) can be passed
to functions. But, of course, there's a downside: when you pass
around a structure a complete copy of the structure must be cre-
ated which can be rather time- and memory-consuming.

                                Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#15050

jt@toerring.de (Jens Thoms Toerring) writes:
> superpollo <superpollo@tznvy.pbz> wrote:
>> so, to summarize: it is not possible for a function that gets an array 
>> passed to figure by herself the size, right?
>
> Correct. And that's because you can't pass an array to a function,
> that's simply not possible in C. All you can pass to a function is
> a pointer to an element (typically the first) of an array (when you
> call a function with an array as an argument the array is silently
> converted to such a pointer to its first element). And with just
> knowing the address of the first element of the array the function
> can't determine the length of the array, thus you have to pass it
> separately. Or, as it already has been pointed out, you could use
> a sentinel element to mark the end of the array - but that re-
> quires that a value existst that never can be a valid data value
> of your array.
>
> The only real way around that would be to wrap the array into
> a structure - structures (in contrast to arrays) can be passed
> to functions. But, of course, there's a downside: when you pass
> around a structure a complete copy of the structure must be cre-
> ated which can be rather time- and memory-consuming.

And the number of elements in the array must be fixed at compile time.
(I suppose you could use a flexible array member, the C99 replacement
for the "struct hack", but you still have to have another mechanism to
get the length.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15052

jt@toerring.de (Jens Thoms Toerring) writes:

> Correct. And that's because you can't pass an array to a function,
> that's simply not possible in C. All you can pass to a function is
> a pointer to an element (typically the first) of an array (when you
> call a function with an array as an argument the array is silently
> converted to such a pointer to its first element). [...]

C99 didn't change any of these fundamentals, but it did make
passing multidimensional arrays to functions more convenient
using "variably modified parameters", which seem to be related to
this topic even if not an answer to the OP's question.

Here's the example from the standard itself:

    void addscalar(int n, int m, double a[n][n*m+300], double x);

    int main()
    {
        double b[4][308];
        addscalar(4, 2, b, 2.17);
        return 0;
    }

    void addscalar(int n, int m, double a[n][n*m+300], double x)
    {
        for (int i = 0; i < n; i++)
                 for (int j = 0, k = n*m+300; j < k; j++)
                           // a is a pointer to a VLA with n*m+300 elements
                           a[i][j] += x;
    }

-- 
"I should killfile you where you stand, worthless human." --Kaz

[toc] | [prev] | [next] | [standalone]

#15034

"superpollo" <superpollo@tznvy.pbz> wrote in message
news:4efa0f91$0$1375$4fafbaef@reader2.news.tin.it...
> BartC ha scritto:
>> "superpollo" <superpollo@tznvy.pbz> wrote in message
>> news:4ef99d34$0$1379$4fafbaef@reader2.news.tin.it...

>> (BTW size(v) is just the number of bytes in a pointer. The array size
>> must be made known explicity.

> so, to summarize: it is not possible for a function that gets an array
> passed to figure by herself the size, right? so the *idiomatic* way to
> give that info to the funtion should be that of the original rosettacode
> code,

That's the usual way. You might be able to invent some other way of doing
it.

Someone mentioned a 'sentinel' where some special value in the array marks
the end of the data.

Or the first element in the array is the size.

Or you pass a pointer to a struct containing an array and it's size (but the
function now takes one argument).

Etc.

Or you can just pass the array pointer, and it's length, explicitly as in
the original example; that's the simplest, when the length can be variable.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#15065

In article <jdd4vs$qfa$1@dont-email.me>, "BartC" <bc@freeuk.com> wrote:

> "superpollo" <superpollo@tznvy.pbz> wrote in message
> news:4efa0f91$0$1375$4fafbaef@reader2.news.tin.it...
> > BartC ha scritto:
> >> "superpollo" <superpollo@tznvy.pbz> wrote in message
> >> news:4ef99d34$0$1379$4fafbaef@reader2.news.tin.it...
> 
> >> (BTW size(v) is just the number of bytes in a pointer. The array size
> >> must be made known explicity.
> 
> > so, to summarize: it is not possible for a function that gets an array
> > passed to figure by herself the size, right? so the *idiomatic* way to
> > give that info to the funtion should be that of the original rosettacode
> > code,
> 
> That's the usual way. You might be able to invent some other way of doing
> it.

One way is to list the elements in a #define call and let it compute the number 
of arguments:

#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>

#define LIST(...)  list(sizeof((char[]){__VA_ARGS__}), __VA_ARGS__)

static void list(int n, ...) {
    va_list argv; va_start(argv, n);
    while (n-->0) printf("%d\n",va_arg(argv,int));
}

int main(int N, char **P) {
    int q[3] = {1, 2, 3};
    LIST(q[0], q[1], q[2], 4);
    return 0;
}

-- 
My name Indigo Montoya.      |        Yippie-kay-yay, mother fakir.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#15035

On 12/27/2011 01:33 PM, superpollo wrote:
> BartC ha scritto:
>> "superpollo" <superpollo@tznvy.pbz> wrote in message 
>> news:4ef99d34$0$1379$4fafbaef@reader2.news.tin.it...
>>> http://rosettacode.org/wiki/Averages/Root_mean_square#C
>>
>>> #include <stdio.h>
>>> #include <math.h>
>>>
>>> double rms(double *v)
>>> {
>>>     const int n = sizeof(v) / sizeof(double);
>>>     int i;
>>>     double sum = 0.0;
>>>     for (i = 0; i < n; i++)
>>>         sum += v[i] * v[i];
>>>     return sqrt(sum / n);
>>> }
>>
>>> [~/superpollo]$ cc -lm rms.c && ./a.out
>>> nan
>>
>>> what gives?
>>
>> Try printing the value of n. You'll probably find it's zero. Your 
>> for-loop while keep going for quite a while, since it starts at i=0, and 
>> won't stop until i<0, perhaps two billion iterations later, by which 
>> time you will have long since breached the array bounds.
>>
>> (BTW size(v) is just the number of bytes in a pointer. The array size 
>> must be made known explicity. Or you can use rand() to just guess the 
>> size; it will probably get it right more often than your code!)
> 
> so, to summarize: it is not possible for a function that gets an array 
> passed to figure by herself the size, right? so the *idiomatic* way to 
> give that info to the funtion should be that of the original rosettacode 
> code, or is there another way?

There's an wide variety of different ways, but all of the ones I can
think of boil down to passing to the function either a count of the
number of elements in the array, or putting a sentinel value in the
array. The wide variety comes in mainly from the many different ways you
can pass in the count, but also from freedom you have in choosing
sentinel values. Since the count and the array are closely related, I
like to package them together in a struct, making use of the flexible
array member feature introduced in C99:

 	struct int_vector
	{
	    size_t n;
	    int array[];
	}

	double sum(struct int_vector* v)
	{
	    double sum = 0.0;
	    for(int i = 0; i < v->n; i++
	        sum += v.array[i];
	    return sum;
	}

[toc] | [prev] | [next] | [standalone]

#15039

On 2011-12-27, superpollo <superpollo@tznvy.pbz> wrote:
> so, to summarize: it is not possible for a function that gets an array 
> passed to figure by herself the size, right?

Basically, yes.  To be more pedantic:  You cannot pass an array to a function
in C.  A function argument which looks like an array type is silently
translated into a pointer-to-array-member type.  So an "int x[]" is really
just an "int *x" as a function argument.

> so the *idiomatic* way to 
> give that info to the funtion should be that of the original rosettacode 
> code, or is there another way?

The usual mechanism is to pass the size as a separate value, or possibly
use a sentinel.  For instance, C string processing uses things which are
functionally equivalent to an array of characters, with the last member of
the array having the value 0.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#15056

superpollo wrote:
...
> so, to summarize: it is not possible for a function that gets an array
> passed to figure by herself the size, right? so the *idiomatic* way to
> give that info to the funtion should be that of the original rosettacode
> code, or is there another way?
...

You *could* use a #define to hide away the size argument.

double rms(double *v, int n);

#define RMS(THIS_MUST_BE_A_VECTOR) 
rms(THIS_MUST_BE_A_VECTOR,sizeof(THIS_MUST_BE_A_VECTOR)/sizeof(double))

but this will do the wrong thing when you pass a double *
So it is a bit questionable.

[toc] | [prev] | [next] | [standalone]

#15062

superpollo於 2011年12月28日星期三UTC+8上午2時33分51秒寫道：
> BartC ha scritto:
> > "superpollo" <superpollo@tznvy.pbz> wrote in message 
> > news:4ef99d34$0$1379$4fafbaef@reader2.news.tin.it...
> >> http://rosettacode.org/wiki/Averages/Root_mean_square#C
> > 
> >> #include <stdio.h>
> >> #include <math.h>
> >>
> >> double rms(double *v)
> >> {
> >>     const int n = sizeof(v) / sizeof(double);
> >>     int i;
> >>     double sum = 0.0;
> >>     for (i = 0; i < n; i++)
> >>         sum += v[i] * v[i];
> >>     return sqrt(sum / n);
> >> }
> > 
> >> [~/superpollo]$ cc -lm rms.c && ./a.out
> >> nan
> > 
> >> what gives?
> > 
> > Try printing the value of n. You'll probably find it's zero. Your 
> > for-loop while keep going for quite a while, since it starts at i=0, and 
> > won't stop until i<0, perhaps two billion iterations later, by which 
> > time you will have long since breached the array bounds.
> > 
> > (BTW size(v) is just the number of bytes in a pointer. The array size 
> > must be made known explicity. Or you can use rand() to just guess the 
> > size; it will probably get it right more often than your code!)
> 
> so, to summarize: it is not possible for a function that gets an array 
> passed to figure by herself the size, right? so the *idiomatic* way to 
> give that info to the funtion should be that of the original rosettacode 
> code, or is there another way?
> 
> bye
> 
> -- 
> Chissa' perche' in un triangolo (5*5)/2=12.5
> ci stanno 125 triangolini ???

This does matter in the pass by register implementations of calling 
a function. The rule of thumb in IA32 X86 is that 3 32bit parameters 
to be the input parameters of a function is OK by __fastcall. 


But for MIPS compatible CPUs, things are not the same. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web