Velocity Reviews > NUMERICAL RECIPES

# NUMERICAL RECIPES

nmm1@cam.ac.uk
Guest
Posts: n/a

 01-20-2011
In article <(E-Mail Removed)>,
aruzinsky <(E-Mail Removed)> wrote:
>On Jan 20, 7:47 am, John Bode <(E-Mail Removed)> wrote:
>>
>> > The practice of initializing and
>> > incrementing pointers separately from loop counters is moronic. They
>> > should both be put in the for statement because loop counters and
>> > pointers are more the same than not. If fact, a pointer can be used
>> > as a loop counter. So, then where do you put the pointer
>> > initialization and increment? Thusly, most people who have not
>> > previously been brainwashed into accepting the absurdities of
>> > programmer cultural would find my version more readable.

>>
>> Then again, there is a school of thought that the only things that
>> should appear in the loop control expression are things that *actually
>> control the loop*; IOW, just because you *can* initialize other
>> variables in the loop control expression doesn't mean you *should*. I
>> prefer to keep my loop control expressions as clean as possible.

>
>"schools of thought" - this is group opinion that is inappropriate on
>objective matters. If there are no scientific studies on the
>ergonomics of source code readability that you can reference, you are
>just speaking dogma in the manner of a religious fanatic.

Well, there are. Lots. Of course, you will have to go into a
decent library and look up journals of the 1960s and 1970s to
find them. And, no, I can't remember the references after all
this time.

Of course, those results do NOT discourage the use of heterogeneous
tuples as loop controls - the reason that those never took off is
because nobody ever worked out a simple, clean syntax for them.
In C terms, things like:

for (i = 0, ptr = base, total = 0.0;
++i, ptr = ptr->next, total += ptr.value;
i < limit && ptr != NULL && total < maximum)

But - and this is CRITICAL - where the compiler checks that i, ptr
and total are NOT otherwise changed in the loop, and where the

Some languages have such paradigms, and Fortran has the FORALL
construct, but it is not a success for reasons other than simple

Regards,
Nick Maclaren.

aruzinsky
Guest
Posts: n/a

 01-20-2011
On Jan 20, 7:47*am, John Bode <(E-Mail Removed)> wrote:
> On Jan 10, 6:54*pm, aruzinsky <(E-Mail Removed)> wrote:
> [snip]
>
> > The practice of initializing and
> > incrementing pointers separately from loop counters is moronic. *They
> > should both be put in the for statement because loop counters and
> > pointers are more the same than not. *If fact, a pointer can be used
> > as a loop counter. *So, then where do you put the pointer
> > initialization and increment? *Thusly, most people who have not
> > previously been brainwashed into accepting the absurdities of
> > programmer cultural would find my version more readable.

>
> Then again, there is a school of thought that the only things that
> should appear in the loop control expression are things that *actually
> control the loop*; IOW, just because you *can* initialize other
> variables in the loop control expression doesn't mean you *should*. *I
> prefer to keep my loop control expressions as clean as possible.
>

"schools of thought" - this is group opinion that is inappropriate on
objective matters. If there are no scientific studies on the
ergonomics of source code readability that you can reference, you are
just speaking dogma in the manner of a religious fanatic.

>
>
> > 2. "Is 'c' some convoluted macro?" - No. *Since I told you that my
> > code was C++, you should have guessed that c is instantiation of a
> > class for allocating floating point arrays on the heap and c(int) and
> > c(int,int) are inline member functions for accessing an element of an
> > array by indices. *BTW, I don't want to see classes in Numerical
> > Recipes either.

>
> Given that I'm reading this in comp.lang.c, and since a lot of us in
> c.l.c. aren't also C++ experts, it's a little much to expect us to
> immediately understand something that specific to C++.
>

I'm reading and writing this in sci.math.num-analysis. If you want to
do something constructive, kill the cross poster for fooling you.

> > To Others:

>
> > Everyone who wants to see or not see Jens Thoms Toerring's version of
> > pointer use in Numerical Recipes, please, vote.

>
> Yo. *His version was clearer for me to read at a glance than yours.

I meant vote between Jens Thoms Toerring's version of pointer use
versus a version using indexing instead of array pointers. Which do
you most want to see in Numerical Recipes?

nmm1@cam.ac.uk
Guest
Posts: n/a

 01-20-2011
In article <(E-Mail Removed)>,
aruzinsky <(E-Mail Removed)> wrote:
>>

>You are begging the question here. Statistically, "simple, clean
>syntax," i.e., the simplicity and cleanliness of syntax should only be
>determined by scientific studies and not informal group opinion,
>whereas, you previously said, "Of course, those results do NOT
>discourage the use of heterogeneous tuples as loop controls." You do
>not have valid reasons for knowing why "those never took off" and you
>should take an agnostic position.

Have you read those studies? I did. And you are suffering from
delusions if you think that you know what they found without doing
so, or you think you know what I have read and learnt.

>Again, you wrongly pretend that "readability" is a property of
>language and not a statistical property of people. Readability should
>to be scientifically studied using statistical methods on a large
>sampling of people. Until then, you should take an agnostic
>position.

I am a statistician, incidentally, and those studies were considerably
more scientific than your claims of The One True Procedure.

Anyway, enough is enough.

Regards,
Nick Maclaren.

aruzinsky
Guest
Posts: n/a

 01-20-2011
On Jan 20, 10:17*am, (E-Mail Removed) wrote:
> In article <(E-Mail Removed)..com>,
>
>
>
>
>
> aruzinsky *<(E-Mail Removed)> wrote:
> >On Jan 20, 7:47 am, John Bode <(E-Mail Removed)> wrote:

>
> >> > The practice of initializing and
> >> > incrementing pointers separately from loop counters is moronic. *They
> >> > should both be put in the for statement because loop counters and
> >> > pointers are more the same than not. *If fact, a pointer can be used
> >> > as a loop counter. *So, then where do you put the pointer
> >> > initialization and increment? *Thusly, most people who have not
> >> > previously been brainwashed into accepting the absurdities of
> >> > programmer cultural would find my version more readable.

>
> >> Then again, there is a school of thought that the only things that
> >> should appear in the loop control expression are things that *actually
> >> control the loop*; IOW, just because you *can* initialize other
> >> variables in the loop control expression doesn't mean you *should*. *I
> >> prefer to keep my loop control expressions as clean as possible.

>
> >"schools of thought" - this is group opinion that is inappropriate on
> >objective matters. *If there are no scientific studies on the
> >ergonomics of source code readability that you can reference, you are
> >just speaking dogma in the manner of a religious fanatic.

>
> Well, there are. *Lots. *Of course, you will have to go into a
> decent library and look up journals of the 1960s and 1970s to
> find them. *And, no, I can't remember the references after all
> this time.
>
> Of course, those results do NOT discourage the use of heterogeneous
> tuples as loop controls - the reason that those never took off is
> because nobody ever worked out a simple, clean syntax for them.

You are begging the question here. Statistically, "simple, clean
syntax," i.e., the simplicity and cleanliness of syntax should only be
determined by scientific studies and not informal group opinion,
whereas, you previously said, "Of course, those results do NOT
discourage the use of heterogeneous tuples as loop controls." You do
not have valid reasons for knowing why "those never took off" and you
should take an agnostic position.

That is not to say that you shouldn't have personal preferences. Just
don't pretend that your preferences apply to everyone or even most
people.

> In C terms, things like:
>
> for (i = 0, ptr = base, total = 0.0;
> * * ++i, ptr = ptr->next, total += ptr.value;
> * * i < limit && ptr != NULL && total < maximum)
>
> But - and this is CRITICAL - where the compiler checks that i, ptr
> and total are NOT otherwise changed in the loop, and where the
> above usage paradigm is enforced.
>
> Some languages have such paradigms, and Fortran has the FORALL
> construct, but it is not a success for reasons other than simple

Again, you wrongly pretend that "readability" is a property of
language and not a statistical property of people. Readability should
to be scientifically studied using statistical methods on a large
sampling of people. Until then, you should take an agnostic
position.

aruzinsky
Guest
Posts: n/a

 01-20-2011
On Jan 20, 11:37*am, (E-Mail Removed) wrote:
> In article <(E-Mail Removed)..com>,
>
> aruzinsky *<(E-Mail Removed)> wrote:
>
> >You are begging the question here. *Statistically, "simple, clean
> >syntax," i.e., the simplicity and cleanliness of syntax should only be
> >determined by scientific studies and not informal group opinion,
> >whereas, you previously said, "Of course, those results do NOT
> >discourage the use of heterogeneous tuples as loop controls." *You do
> >not have valid reasons for knowing why "those never took off" and you
> >should take an agnostic position.

>
> Have you read those studies? *I did. *And you are suffering from
> delusions if you think that you know what they found without doing
> so, or you think you know what I have read and learnt.

No, I am talking your word for it that "those results do NOT
discourage the use of heterogeneous tuples as loop controls." If by
"nobody" you mean no researcher in those studies, then it does not
logically follow this is the cause for them "not taking off."

>
> >Again, you wrongly pretend that "readability" is a property of
> >language and not a statistical property of people. Readability should
> >to be scientifically studied using statistical methods on a large
> >sampling of people. *Until then, you should take an agnostic
> >position.

>
> I am a statistician, incidentally, and those studies were considerably
> more scientific than your claims of The One True Procedure.
>

I don't recall making any "claims of The One True Procedure."

Your profile shows that, out of 6120 posts, you have ZERO in
sci.stat.math. Thusly, it seems that you have absolutely no interest

> Anyway, enough is enough.
>

By what statistical procedure did you determine that "enough is
enough" such that you feel qualified to pontificate on how much is
enough?

Tim Rentsch
Guest
Posts: n/a

 01-30-2011
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:

> In article <(E-Mail Removed)>,
> [snip]
>
> I suggest that you try and think of a construct where phase 8 has
> the concept of an array value (or even an array object) - you may
> find it harder than you think

It's obvious the Standard considers array objects as existing at
runtime - simply witness the numerous uses of the term 'array
object' in subsections of 6.5, describing execution-time semantics.

> And, while the conversion can often be done in phase 8 (just as
> sizeof() can be), it is conceptually a phase 7 operation.

This statement is nonsense. Just because some conversions can be
done at compile time in some specific instances, the operation of
converting is still conceptually a run-time operation, in the same
way that '+' is a run-time operation even though '+' is done at
compile time in some constant expressions. If anyone needs
convincing, consider code like

int x[5][10];

...

int *p = x[i];

Here it isn't even known until execution which array object is being
converted, so the conversion must take place at run time.

> You can
> see that if you look at the specification of function declarations
> and calls in detail, or consider code like:
>
> double a[100], b[sizeof(a+0)];

A specious argument, because the sizeof operator works on types, not
values; no array-to-pointer conversion occurs in this code (either
at run time or at compile time), because the argument to sizeof is
never evaluated.

Tim Rentsch
Guest
Posts: n/a

 01-30-2011
aruzinsky <(E-Mail Removed)> writes:

> On Jan 20, 7:47 am, John Bode <(E-Mail Removed)> wrote:
>> On Jan 10, 6:54 pm, aruzinsky <(E-Mail Removed)> wrote:
>> [snip]
>>
>> > The practice of initializing and
>> > incrementing pointers separately from loop counters is moronic. They
>> > should both be put in the for statement because loop counters and
>> > pointers are more the same than not. If fact, a pointer can be used
>> > as a loop counter. So, then where do you put the pointer
>> > initialization and increment? Thusly, most people who have not
>> > previously been brainwashed into accepting the absurdities of
>> > programmer cultural would find my version more readable.

>>
>> Then again, there is a school of thought that the only things that
>> should appear in the loop control expression are things that *actually
>> control the loop*; IOW, just because you *can* initialize other
>> variables in the loop control expression doesn't mean you *should*. I
>> prefer to keep my loop control expressions as clean as possible.
>>

>
> "schools of thought" - this is group opinion that is inappropriate on
> objective matters. If there are no scientific studies on the
> ergonomics of source code readability that you can reference, you are
> just speaking dogma in the manner of a religious fanatic.

Do you have any scientific studies to back up that statement?
Or is it just your opinion?