Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > NUMERICAL RECIPES

Reply
Thread Tools

NUMERICAL RECIPES

 
 
nmm1@cam.ac.uk
Guest
Posts: n/a
 
      01-09-2011
In article <>,
Keith Thompson <kst-> wrote:
>>>
>>>By what process do you get that? Programs without pointers aren't useful?

>>
>> In C, that is true. All of strings, arrays and (when used as objects)
>> functions are actually pointers, and it is important to know and use
>> that when passing them as function arguments.
>>
>> It is not true in Fortran.

>
>It's not true in C either.
>
>Strings are not pointers. Arrays are not pointers. Functions are not
>pointers.
>
>All three are typically managed using pointers, and a declaration that
>looks like a parameter of array or function type is really a pointer
>parameter.


Er, no. While I agree that I was over-simplifying, you have seriously
misunderstood C. It is NOT just when they are parameters, but any
time that they are used as values - there is no such thing as a
string, array or function value in C.

I accept that there are such things as string, array or function
declarations, and array or function types - but you can't do anything
with objects declared as such without converting them to pointers.
Except for sizeof, of course, but that really operates on types.

Seriously. Look at the standard in depth, and see.


Regards,
Nick Maclaren.
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      01-09-2011
On 01/10/11 10:13 AM, wrote:
> In article<>,
> Keith Thompson<kst-> wrote:
>>>>
>>>> By what process do you get that? Programs without pointers aren't useful?
>>>
>>> In C, that is true. All of strings, arrays and (when used as objects)
>>> functions are actually pointers, and it is important to know and use
>>> that when passing them as function arguments.
>>>
>>> It is not true in Fortran.

>>
>> It's not true in C either.
>>
>> Strings are not pointers. Arrays are not pointers. Functions are not
>> pointers.
>>
>> All three are typically managed using pointers, and a declaration that
>> looks like a parameter of array or function type is really a pointer
>> parameter.

>
> Er, no. While I agree that I was over-simplifying, you have seriously
> misunderstood C.


I very much doubt that Keith has misunderstood C!

> It is NOT just when they are parameters, but any
> time that they are used as values - there is no such thing as a
> string, array or function value in C.
>
> I accept that there are such things as string, array or function
> declarations, and array or function types - but you can't do anything
> with objects declared as such without converting them to pointers.
> Except for sizeof, of course, but that really operates on types.


Eh?

int n = 42;
int x[1];
x[0] = n;

Where's the pointer?

--
Ian Collins
 
Reply With Quote
 
 
 
 
Seebs
Guest
Posts: n/a
 
      01-09-2011
On 2011-01-09, <> wrote:
> Er, no. While I agree that I was over-simplifying, you have seriously
> misunderstood C. It is NOT just when they are parameters, but any
> time that they are used as values - there is no such thing as a
> string, array or function value in C.


I'm not quite sure of this. I agree that you can't do much with array
values, but struct assignment of a structure containing an array looks like
it does what you'd expect if you thought arrays had values.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
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.
 
Reply With Quote
 
LR
Guest
Posts: n/a
 
      01-09-2011
Ian Collins wrote:
> On 01/10/11 10:13 AM, wrote:
>> In article<>,
>> Keith Thompson<kst-> wrote:
>>>>>
>>>>> By what process do you get that? Programs without pointers aren't useful?
>>>>
>>>> In C, that is true. All of strings, arrays and (when used as objects)
>>>> functions are actually pointers, and it is important to know and use
>>>> that when passing them as function arguments.
>>>>
>>>> It is not true in Fortran.
>>>
>>> It's not true in C either.
>>>
>>> Strings are not pointers. Arrays are not pointers. Functions are not
>>> pointers.
>>>
>>> All three are typically managed using pointers, and a declaration that
>>> looks like a parameter of array or function type is really a pointer
>>> parameter.

>>
>> Er, no. While I agree that I was over-simplifying, you have seriously
>> misunderstood C.

>
> I very much doubt that Keith has misunderstood C!
>
>> It is NOT just when they are parameters, but any
>> time that they are used as values - there is no such thing as a
>> string, array or function value in C.
>>
>> I accept that there are such things as string, array or function
>> declarations, and array or function types - but you can't do anything
>> with objects declared as such without converting them to pointers.
>> Except for sizeof, of course, but that really operates on types.

>
> Eh?
>
> int n = 42;
> int x[1];
> x[0] = n;
>
> Where's the pointer?


This may be of interest.

http://c-faq.com/aryptr/aryptrequiv.html
"comp.lang.c FAQ list · Question 6.3"
"So what is meant by the ``equivalence of pointers and arrays'' in C?"

I tried this little snippet using c++, but I think it will compile in C
as well, maybe with some changes.

int n = 42;
int x[1];
int *p;

0[x] = n;
*(x+0) = n;

p = x;
p[0] = n;
0[p] = n;

char c = "abcd"[2]; /* c == 'c' */

LR


 
Reply With Quote
 
nmm1@cam.ac.uk
Guest
Posts: n/a
 
      01-10-2011
In article <>,
Ian Collins <ian-> wrote:
>>>> In C, that is true. All of strings, arrays and (when used as objects)
>>>> functions are actually pointers, and it is important to know and use
>>>> that when passing them as function arguments.
>>>>
>>>> It is not true in Fortran.
>>>
>>> It's not true in C either.
>>>
>>> Strings are not pointers. Arrays are not pointers. Functions are not
>>> pointers.
>>>
>>> All three are typically managed using pointers, and a declaration that
>>> looks like a parameter of array or function type is really a pointer
>>> parameter.

>>
>> Er, no. While I agree that I was over-simplifying, you have seriously
>> misunderstood C.

>
>I very much doubt that Keith has misunderstood C!


While I have a great deal of respect for Keith, from his postings,
I have not understood from them that he is an expert on the detailed
wording of the C standard. On this topic, look at:

6.3.2.1 Lvalues, arrays, and function designators

[#3] Except when it is the operand of the sizeof operator or
the unary & operator, or is a string literal used to
initialize an array, an expression that has type ``array of
type'' is converted to an expression with type ``pointer to
type'' that points to the initial element of the array
object and is not an lvalue. If the array object has
register storage class, the behavior is undefined.

[#4] A function designator is an expression that has
function type. Except when it is the operand of the sizeof
operator54) or the unary & operator, a function designator
with type ``function returning type'' is converted to an
expression that has type ``pointer to function returning
type''.

There are a hell of a lot of other references to look at, of course,
but the executive summary is that arrays (including strings) do not
last beyond translation phase 7, except as the pointers they have
been converted to and implicit bounds on the arithmetic permitted
on those pointers.

Similarly, functions become pointers in all contexts except actual
calls.

>Eh?
>
>int n = 42;
>int x[1];
>x[0] = n;
>
>Where's the pointer?


6.5.2.1 Array subscripting

Constraints

[#1] One of the expressions shall have type ``pointer to
object type'', the other expression shall have integer type,
and the result has type ``type''.


Regards,
Nick Maclaren.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-10-2011
On 01/10/2011 06:43 AM, wrote:
> In article<>,
> Ian Collins<ian-> wrote:
>>>>> In C, that is true. All of strings, arrays and (when used as objects)
>>>>> functions are actually pointers, and it is important to know and use
>>>>> that when passing them as function arguments.
>>>>>
>>>>> It is not true in Fortran.
>>>>
>>>> It's not true in C either.
>>>>
>>>> Strings are not pointers. Arrays are not pointers. Functions are not
>>>> pointers.
>>>>
>>>> All three are typically managed using pointers, and a declaration that
>>>> looks like a parameter of array or function type is really a pointer
>>>> parameter.
>>>
>>> Er, no. While I agree that I was over-simplifying, you have seriously
>>> misunderstood C.

>>
>> I very much doubt that Keith has misunderstood C!

>
> While I have a great deal of respect for Keith, from his postings,
> I have not understood from them that he is an expert on the detailed
> wording of the C standard. On this topic, look at:
>
> 6.3.2.1 Lvalues, arrays, and function designators
>
> [#3] Except when it is the operand of the sizeof operator or
> the unary& operator, or is a string literal used to
> initialize an array, an expression that has type ``array of
> type'' is converted to an expression with type ``pointer to
> type'' that points to the initial element of the array
> object and is not an lvalue. If the array object has
> register storage class, the behavior is undefined.
>
> [#4] A function designator is an expression that has
> function type. Except when it is the operand of the sizeof
> operator54) or the unary& operator, a function designator
> with type ``function returning type'' is converted to an
> expression that has type ``pointer to function returning
> type''.
>
> There are a hell of a lot of other references to look at, of course,
> but the executive summary is that arrays (including strings) do not
> last beyond translation phase 7, except as the pointers they have
> been converted to and implicit bounds on the arithmetic permitted
> on those pointers.


I'm quite sure that Keith is well aware of the factual content of that
paragraph.

You're talking about values, but strings, arrays, and functions are NOT
values in C. An array is an object, and a string is a data format.
Arrays don't even actually exist until the start of their lifetime,
during execution of the program, and they continue to exist until the
end of that lifetime. Strings don't exist until the required null
terminator value is stored, and cease to be strings when no longer so
terminated, all of which occurs during execution, If strings and arrays
disappeared in translation phase 7, then the corresponding pointers
would have nothing to point at.

> Similarly, functions become pointers in all contexts except actual
> calls.


Functions remain functions throughout the lifetime of the program, but
function identifiers in source code gets converted into pointers to the
corresponding function. If the function ceased to exist in translation
phase 7, the resulting pointer would have nothing to point at.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-10-2011
This followup is about C, but I've kept the wide cross-post for
now to make sure it's seen. Please consider redirecting further
followups to comp.lang.c if you want to discuss this further.
If you don't care about C, feel free to stop reading now; there is
no Fortran, PL/I, or numerical analysis content.

writes:
> In article <>,
> Keith Thompson <kst-> wrote:
>>>>
>>>>By what process do you get that? Programs without pointers aren't useful?
>>>
>>> In C, that is true. All of strings, arrays and (when used as objects)
>>> functions are actually pointers, and it is important to know and use
>>> that when passing them as function arguments.
>>>
>>> It is not true in Fortran.

>>
>>It's not true in C either.
>>
>>Strings are not pointers. Arrays are not pointers. Functions are not
>>pointers.
>>
>>All three are typically managed using pointers, and a declaration that
>>looks like a parameter of array or function type is really a pointer
>>parameter.

>
> Er, no. While I agree that I was over-simplifying, you have seriously
> misunderstood C.
>
> It is NOT just when they are parameters, but any
> time that they are used as values - there is no such thing as a
> string, array or function value in C.
>
> I accept that there are such things as string, array or function
> declarations, and array or function types - but you can't do anything
> with objects declared as such without converting them to pointers.
> Except for sizeof, of course, but that really operates on types.
>
> Seriously. Look at the standard in depth, and see.


I have looked at the standard in depth, and no, I haven't
misunderstood it.

A "string" is, by definition, "a contiguous sequence of characters
terminated by and including the first null character" (C99 7.1.1p1).
It's a data *layout*, not a data type. An array object may *contain*
a string at run time.

There's a tight relationship between arrays and pointers in C, but that
relationship absolutely is not identify. They are very different
things. An array type "describes a contiguously allocated nonempty set
of objects with a particular member object type, called the element
type" (C99 6.2.5p20); a pointer type "describes an object whose value
provides a reference to an entity of the referenced type" (same
paragraph).

There are several rules in C that tend to cause confusion in this area.

First, a parameter declaration of array type, such as
int foo(char arr[]);
is really a pointer declaration:
int foo(char *arr);
This isn't a run-time conversion, it's a compile-time adjustment.
For details, see C99 6.7.5.2p7.

Second, any expression of array type is implicitly converted to a
pointer to the array object's first element, with three exceptions.
This is a conversion, not an equivalence; it's an entirely separate
rule from the one for parameters, and applies in all expression
contexts. The exceptions are when the array expression is the
argument of a sizeof operator (sizeof arr yields the size of the
array, not the size of a pointer to the first element of the arrray),
when it's the argument of a unary "&" (address) operator (&arr yields
the address of the entire array, not of its first element; they're of
different types), and when it's a string literal in an initializer
used to initialize an object of array type (``char arr[10] = "hello";''
doesn't convert "hello" to an address). C99 6.3.2.1p3.

Section 6 of the comp.lang.c FAQ, <http://www.c-faq.com/> does a very
good job of explaining the relationship between C pointers and C arrays.

Similar rules apply to expressions of function type; see C99
6.3.2.1p4. Note that sizeof func, if func is a function name,
doesn't cause a conversion to pointer type, but in this case the
result is an error (constraint violation), since sizeof cannot
be applied to a function. A function call (which can be thought
of as an applicaton of the function call operator) requires a
pointer-to-function as its prefix. In most cases, this will be a
function name (an expression of function type) implicitly converted
to a pointer-to-function type.

Are there a string values? Maybe. There's no string type, but an array
object can contain a string. I don't think the standard uses the
term "string value".

Are there function values? No. There are expressions of function
type, but in most contexts they're immediately converted to pointers.

Are there array values? Absolutely. A "value" is the "precise
meaning of the contents of an object when interpreted as having a
specific type" (C99 3.17). For an array object, the value consists
of the values of all its elements. (Note that the standard's
definition of "value" is incomplete; it doesn't cover the value of
an expression, an unfortunate oversight IMHO.)

As I said, arrays and functions are almost always manipulated via
pointers (for arrays, it's usually a pointer to the first element
rather than a pointer to the entire array). Neither array types nor
pointer types are first-class, as they are in some other languages.
But they are types, and they are most definitely distinct from
pointer types (though the language sometimes seems to conspire to
obscure that distinction).

For example:

void print(char param[]) {
puts(param);
}
/* ... */
char s[6] = "Hello";
print(s);

The declaration of "param" is really a pointer declaration,
though the syntax makes it look like an array declaration; I could
equivalently have written ``void print(char *param)''. In the call
to print(), it *looks* like an array value is being passed to a
function that takes an array argument -- but in fact what's being
passed is a pointer to the array's first element (and the function
finds the end of the string by looking for the terminating null
character) -- or rather the puts function does that). Nevertheless,
there is a real array object called "s", and it contains an array
value consisting of 6 char values ('H', 'e', 'l', 'l', 'o', '\0').
And in the calls themselves, ``puts'' and ``print'' are expressions
of function type (the names of functions), but they're implicitly
converted to values of pointer-to-function type.

Strings are not pointers. Arrays are not pointers. Functions are not
pointers.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-10-2011
Ian Collins <ian-> writes:
[...]
> Eh?
>
> int n = 42;
> int x[1];
> x[0] = n;
>
> Where's the pointer?


In ``x[0] = n'', the subexpression ``x'' is implicitly converted to
a pointer to the first (zeroth) element of the array x. So there's
a pointer *value*, but there's no pointer *object*.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-10-2011
writes:
> In article <>,
> Ian Collins <ian-> wrote:
>>>>> In C, that is true. All of strings, arrays and (when used as objects)
>>>>> functions are actually pointers, and it is important to know and use
>>>>> that when passing them as function arguments.
>>>>>
>>>>> It is not true in Fortran.
>>>>
>>>> It's not true in C either.
>>>>
>>>> Strings are not pointers. Arrays are not pointers. Functions are not
>>>> pointers.
>>>>
>>>> All three are typically managed using pointers, and a declaration that
>>>> looks like a parameter of array or function type is really a pointer
>>>> parameter.
>>>
>>> Er, no. While I agree that I was over-simplifying, you have seriously
>>> misunderstood C.

>>
>>I very much doubt that Keith has misunderstood C!

>
> While I have a great deal of respect for Keith, from his postings,
> I have not understood from them that he is an expert on the detailed
> wording of the C standard. On this topic, look at:
>
> 6.3.2.1 Lvalues, arrays, and function designators
>
> [#3] Except when it is the operand of the sizeof operator or
> the unary & operator, or is a string literal used to
> initialize an array, an expression that has type ``array of
> type'' is converted to an expression with type ``pointer to
> type'' that points to the initial element of the array
> object and is not an lvalue. If the array object has
> register storage class, the behavior is undefined.
>
> [#4] A function designator is an expression that has
> function type. Except when it is the operand of the sizeof
> operator54) or the unary & operator, a function designator
> with type ``function returning type'' is converted to an
> expression that has type ``pointer to function returning
> type''.
>
> There are a hell of a lot of other references to look at, of course,
> but the executive summary is that arrays (including strings) do not
> last beyond translation phase 7, except as the pointers they have
> been converted to and implicit bounds on the arithmetic permitted
> on those pointers.


Array types, like any types, don't really exist after compilation.
Array objects do exist at run time, and they hold array values.

Any expression of array type is *converted* to a pointer to the array's
first element. This is conceptually a run-time operation, though it's
almost certainly handled at compile time.

As I explained in my other followup, there are array values (see the
standard's definition of "value" in 3.17); it's just somewhat unusual to
manipulate them as values.

But as Seebs pointed out, a struct may contain an array member, which
may be assigned as part of assigning the struct value:

struct foo {
int arr[10];
};
struct foo sf1 = { 0 };
struct foo sf2;
sf2 = sf1;

> Similarly, functions become pointers in all contexts except actual
> calls.


Functions don't *become* pointers. Expressions of function type are
*converted* to pointer values.

>>Eh?
>>
>>int n = 42;
>>int x[1];
>>x[0] = n;
>>
>>Where's the pointer?

>
> 6.5.2.1 Array subscripting
>
> Constraints
>
> [#1] One of the expressions shall have type ``pointer to
> object type'', the other expression shall have integer type,
> and the result has type ``type''.


Right. A pointer value is created by the conversion, but there's no
pointer object. (The unqualified word "pointer" is ambiguous; I
generally try to refer to pointer types, pointer objects, and pointer
values explicitly. Likewise for arrays.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
aruzinsky
Guest
Posts: n/a
 
      01-10-2011
On Jan 9, 11:29*am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-01-09, aruzinsky <aruzin...@general-cathexis.com> wrote:
>
> > Proper implementation of C pointers increases program speed but the
> > source code is relatively unreadable.

>
> No, it isn't.
>
> > I much rather
> > read C source code written to resemble pseudo-code. *Afterwards, it is
> > easy enough for me to implement pointers (which later I have
> > difficulty reading).

>
> There are tons of algorithms which are elegant and clear using pointers,
> and hard to write clearly at all without them. *Perhaps you should just
> practice more until pointers are more comfortable for you.
>
> -s
> --
> Copyright 2010, all wrongs reversed. *Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
> I am not speaking for my employer, although they do rent some of my opinions.


Here is an example of C++ source using array pointers that I wrote:

float sum, *xx, *px, *cx;
for (xx=x,j=0;j<mn;j++,xx++)
{
for (sum=0, i=psfsm, cx=&c(psfs.ip[j]), px=psfs.z[j]; i; i--, cx++,
px++) sum += *px * *cx;
*xx = sum;
}

No sane person would want to see such constructs in Numerical Recipes.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Chicken Recipes - The Web's Largest Chicken Recipes Collection dartioposit@gmail.com Java 2 02-21-2009 02:44 AM
Java numerical recipes online... Al Murphy Java 1 02-05-2004 06:14 PM
Error in Numerical Recipes lubksb routine mma C Programming 5 12-09-2003 09:36 AM
Re: numerical recipes book E. Robert Tisdale C Programming 0 07-31-2003 02:02 AM
Re: numerical recipes book Rouben Rostamian C Programming 0 07-30-2003 02:04 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57