Simple Matrix Rotation

[Netocrat]

[W]ouldn't it have been better to say

"It's true that [a declaration of main with empty parameters] isn't
obsolete, but it is obsolescent."

rather than, or perhaps just before, quoting the paragraph? Otherwise
people might think you're confusing the two terms, or confuse them
themselves.

That may have been clearer.

[C]ould you please use the more up-to-date section numbers in n1124 when
posting (even if you prefer to use N869 for your own
searching/navigation)? I'm sure it would be appreciated if you did.

I've found a more functional PDF viewer so I'll switch to N1124.

 

[Robert Gamble]

[C]ould you please use the more up-to-date section numbers in n1124 when
posting (even if you prefer to use N869 for your own
searching/navigation)? I'm sure it would be appreciated if you did.

I've found a more functional PDF viewer so I'll switch to N1124.

Just out of curiosity, what were you using before and what are you
using now? Is there any reason Adobe's reader isn't satisfactory? (I
don't know what platform you are using but the versions I have used for
Windows and UNIX/Linux seemed pretty functional)

Robert Gamble

 

[August Karlstrom]

So, I suggest:

Figure out what your question is; try to find a
way to state it clearly (and, if possible, succinctly,
but above all clearly); post it in a newsgroup that
addresses programming issues rather than language issues.

....such as comp.programming.


August

 

[Malcolm]

First, you're asking in the wrong newsgroup. Even
though your program is written in C, the question
you're asking is about a C program and not about
the C language. The comp.lang.c newsgroup is for
discussion about the C language, not about C programs
(unless they are being used to illustrate discussion
about the language).

Actually the code is pretty hopeless, because the OP clearly doesn't
understand C. For instnace he seems to think that arrays are 1 based, and
that the transcendental functions take arguements in degrees.
Newbies to C are usually also newbies to algorithms, so we cannot insist on
a too rigid separation of the two issues.

 

[Ivan A. Kosarev]

I have a copy but I find the plain text/html access to N869 easier to
navigate and search than the pdf of N1124.

On that matter, the domain that hosts the drafts I usually access has
recently stopped responding - does anyone know whether dev.unicals.com is
permanently down, moved or only temporarily down? I didn't save local
copies of their html-format drafts and they were great to work with.

All the papers will be available through unicals.com in a few days.

Thanks.

 

[Netocrat]

[C]ould you please use the more up-to-date section numbers in n1124 when
posting (even if you prefer to use N869 for your own
searching/navigation)? I'm sure it would be appreciated if you did.

I've found a more functional PDF viewer so I'll switch to N1124.

Just out of curiosity, what were you using before and what are you
using now?

I was using KGhostview, which is a combined postscript and PDF viewer and
doesn't seem to support text searching or a sidebar contents tree (it
instead displays a list of page thumbnails). I had also tried Gnome PDF
viewer, which supports a sidebar contents tree but doesn't support
searching functionality beyond searching that tree.

Now I'm using KPDF which supports both the sidebar contents tree and text
searching. It (and KGhostview) scroll in screenfuls using PgUP and PgDown
which I also find more useful than Gnome's PDF viewer (entire pages).
The up/down arrow keys scroll across pages whereas using KGhostview and
GNOME PDF viewer they stop on page boundaries.

All software versions are the latest available through my OS distribution
as of a couple of days ago.

Is there any reason Adobe's reader isn't satisfactory? (I
don't know what platform you are using but the versions I have used for
Windows and UNIX/Linux seemed pretty functional)

I haven't used Adobe's reader recently and I try to avoid installing
closed-source software where I can't see a compelling reason. A slightly
more functional PDF viewer doesn't qualify, whereas this:
http://groups.google.com/group/comp.os.linux.misc/msg/9efcb4e65ed09b03?hl=en&
qualifies as a pretty compelling case against.

I'm writing this on a Gentoo Linux box.

 

[aegis]

Am I the only one who actually read the quoted paragraph? it says that

void a();

is obsolescent, and

void b() { ... }

is not.

No. It says 'function declarators' and doesn't specify that it is
either function declarators not part of a definition or having to be
associated with a definition. So it applies to both, as it speaks
about them in a general sense.

 

[Tim Rentsch]

Actually the code is pretty hopeless, because the OP clearly doesn't
understand C. For instnace he seems to think that arrays are 1 based, and
that the transcendental functions take arguements in degrees.
Newbies to C are usually also newbies to algorithms, so we cannot insist on
a too rigid separation of the two issues.

Certainly, if the group so chooses, it can insist on a separation of
the two different areas of discussion.

What I think you mean to say is that it's unrealistic to expect that
novices to C and to programming generally will be able to understand
the distinction enough to separate the two areas. But of course any
responses can make the distinction, and try to educate novices so that
they themselves will (eventually) be able to distinguish also. As I
was trying to do in what I wrote.

 

[Mark McIntyre]

What I think you mean to say is that it's unrealistic to expect that
novices to C and to programming generally will be able to understand
the distinction enough to separate the two areas. But of course any
responses can make the distinction, and try to educate novices so that
they themselves will (eventually) be able to distinguish also.

And isn't this the entire point? The group is here to help people
learn. People learn by being told stuff. That includes the difference
between an algorithm and a programming language. Not telling them is a
betrayal of the group's purpose.

 

[Tim Rentsch]

And isn't this the entire point? The group is here to help people
learn. People learn by being told stuff. That includes the difference
between an algorithm and a programming language. Not telling them is a
betrayal of the group's purpose.

Yes and no. Writing to educate isn't always the same as writing
to inform. A key question in responding to a posting in
comp.lang.c is, is it more appropriate to educate or to inform?
In both cases the intent is to convey information, but what
information is conveyed, and how, will be different depending on
whether it's better to emphasize the one or the other.

So I agree with your basic point that the group is here to help
people get information. I think it is also useful to distinguish
between educating and informing: depending on circumstances it
can be better to do one or the other (or sometimes a mix of two).

Kind of a long way of saying "Don't assume someone is stupid
just because he's ignorant." I think that's the point I was
trying to make originally.

 

[Keith Thompson]

Yes and no. Writing to educate isn't always the same as writing
to inform. A key question in responding to a posting in
comp.lang.c is, is it more appropriate to educate or to inform?
In both cases the intent is to convey information, but what
information is conveyed, and how, will be different depending on
whether it's better to emphasize the one or the other.

I suspect I'm not the only one who's unclear on what distinction
you're making here. Can you clarify the difference between educating
and informing?

 

[Tim Rentsch]

I suspect I'm not the only one who's unclear on what distinction
you're making here. Can you clarify the difference between educating
and informing?

Certainly; or at least certainly I can try.

Suppose someone posted a query, "How can I write recursive
functions in C?" (In most cases the posting would have more
context than that, but here it's just the one question and
nothing else.) There are different kinds of answers one
might give in response.

One example: "All functions in C are (potentially)
recursive; just call a function in your call chain the same
way you would any other function."

Another example: "It's a good idea to put prototypes for
functions that call each other recursively into a header
file (or header files)."

Another example: "Any function may call itself; such a
function is directly recursive. A function foo may call a
function bar, that calls a function bas, that calls a
function xyzzy, and so forth, to eventually call foo again
while the original foo is in the middle of calling bar;
such a function foo is indirectly recursive. (A function
may be both directly recursive and indirectly recursive.)"

Another example: "When you say 'recursive', what do you
mean exactly?" (It turns out that what was being asked
about is expressions like f(g(x)) and h(h(y)), ie, not
really about recursion at all. A subsequent response can
then try to straighten out the problems.)

The examples are roughly monotonic with writing to inform
near the top and writing to educate near the bottom. None
of the answers is absolutely good or absolutely bad;
whether they are or not depends very much on what it is the
questioner understands and what he does not understand.

To say it another way: writing to inform is what you do
when you think the person understands the question he's
asking; writing to educate is what you do when you think
the person doesn't understand the question he's asking (or
maybe doesn't even know _what_ question he's asking). And
of course there are degrees and combinations of the two,
it's not always just one or the other.

So, even though what I've given is more of an extended
example than trying to define what each of the two terms
means, I hope this has helped answer your question.

 

[Robert Gamble]

I suspect I'm not the only one who's unclear on what distinction
you're making here. Can you clarify the difference between educating
and informing?

Someone who doesn't understand the concept of multiplication asks you
what 5 times 8 is. You respond with 40 without an explanation of the
process that yielded the result. You have informed but not educated.

Robrt Gamble

 

[Robert Gamble]

I suspect I'm not the only one who's unclear on what distinction
you're making here. Can you clarify the difference between educating
and informing?

Someone who doesn't understand the concept of multiplication asks you
what 5 times 8 is. You respond with 40 without an explanation of the
process that yielded the result. You have informed but not educated.

Robert Gamble

 

[Mark McIntyre]

On 08 Nov 2005 17:43:32 -0800, in comp.lang.c , Tim Rentsch

(snip ramble)

Kind of a long way of saying "Don't assume someone is stupid
just because he's ignorant." I think that's the point I was
trying to make originally.

Its a point I agree with, and partly why I think its worth informing
and educating if you can .

 

[Tim Rentsch]

On 08 Nov 2005 17:43:32 -0800, in comp.lang.c , Tim Rentsch

(snip ramble)


Its a point I agree with, and partly why I think its worth informing
and educating if you can .

Most answers should have some of each. Depending on the particulars,
however, it might be 90/10, 50/50, or 10/90 that's the best fit.

 

[Dave Thompson]

On 09 Nov 2005 02:13:29 -0800, Tim Rentsch <[email protected]>
wrote:

Suppose someone posted a query, "How can I write recursive
functions in C?" <snip>
Another [answer]: "It's a good idea to put prototypes for
functions that call each other recursively into a header
file (or header files)."

I know this was only an example, but:

Mutually-recursive routines should have (separate = forward)
prototypes. Those prototypes should be in a header file if the call
cycle (or more generally path) crosses module (specifically t.u.)
boundaries, or might. If it is within a t.u. -- particularly if the
routines involved are static = internal -- IMO those declarations are
better put near the top of the source file.
- David.Thompson1 at worldnet.att.net

 

[Tim Rentsch]

On 09 Nov 2005 02:13:29 -0800, Tim Rentsch <[email protected]>
wrote:

Suppose someone posted a query, "How can I write recursive
functions in C?" <snip>
Another [answer]: "It's a good idea to put prototypes for
functions that call each other recursively into a header
file (or header files)."

I know this was only an example, but:

Mutually-recursive routines should have (separate = forward)
prototypes. Those prototypes should be in a header file if the call
cycle (or more generally path) crosses module (specifically t.u.)
boundaries, or might. If it is within a t.u. -- particularly if the
routines involved are static = internal -- IMO those declarations are
better put near the top of the source file.

Certainly that's a reasonable approach. I've found it helpful to
adopt a practice of putting declarations for static functions (and
any other non-public declarations) into a separate private header
file for inclusion only by the owning source (.c) file.