How to read algorithms?

I have some years of experience with implementing functions/algorithms in
C/C++/Java/Matlab. As long as I have to deal with object oriented code
(allocating objects, transferring objects, accessing types etc) I feel
pretty efficient.

But when dealing with single functions I lack some methodology to learn what
is expressed in the various loops and if-then-else statements. I guees it
boils down to my lack of experince and the only way to get better is to
read/implement more functions. But then again it could be interesting to
hear what other people do.

Often I try to hack my way through a complex function writing down the
values of each single variable on a sheet of paper. I often start writing
the min and max ranges of the loops and then draw the intervals to get a
feeling how the data is manipulated. I know this kind of manually executing
an algorithm is sometimes necessary but still I think there must be some
more methodological way that can be reused each time an algorithms is read.
Lets take an example written in matlab:

function M = basis(i, u, k, U)
p = k-1;
M = zeros(1,p+1); // A p+1 array
left = zeros(1,p+2); // A p+2 array
right = zeros(1,p+2); // A p+2 array
M(1) = 1;
for j=1:p
left(j) = u - U(i+1-j);
right(j) = U(i+j) - u;
sav = 0;
for r=1:j
L = left(j-r+1);
R = right(r);
tmp = M(r)/(R + L);
M(r) = sav + R*tmp;
sav = L*tmp;
end
M(j+1) = sav;
end
end

Without any idea of what the above function is supposed to how would you
learn it?

saneman wrote:
[color=blue]
> Without any idea of what the above function is supposed to how would you
> learn it?[/color]

This is what comments are for. Any decent programmer *should* have
prefaced this code with a description of what it does, any corner cases
in the algorithm, any "gotchas" that might be tricky, locking
requirements, etc.

Chris

Chris Friesen <cbf123@mail.usask.ca> writes:[color=blue]
>saneman wrote:
>[color=green]
>> Without any idea of what the above function is supposed to how would you
>> learn it?[/color]
>
>This is what comments are for. Any decent programmer *should* have
>prefaced this code with a description of what it does, any corner cases
>in the algorithm, any "gotchas" that might be tricky, locking
>requirements, etc.
>[/color]

And used meaningful variable names.

scott

Scott Lurndal wrote:[color=blue]
> Chris Friesen <cbf123@mail.usask.ca> writes:[color=green]
>> saneman wrote:
>>[color=darkred]
>>> Without any idea of what the above function is supposed to how would you
>>> learn it?[/color]
>> This is what comments are for. Any decent programmer *should* have
>> prefaced this code with a description of what it does, any corner cases
>> in the algorithm, any "gotchas" that might be tricky, locking
>> requirements, etc.
>>[/color]
>
> And used meaningful variable names.
>
> scott[/color]

And supplied hint tests.

--
Ian Collins.

Ian Collins wrote:[color=blue]
> Scott Lurndal wrote:[color=green]
>> Chris Friesen <cbf123@mail.usask.ca> writes:[color=darkred]
>>> saneman wrote:
>>>
>>>> Without any idea of what the above function is supposed to how would you
>>>> learn it?
>>> This is what comments are for. Any decent programmer *should* have
>>> prefaced this code with a description of what it does, any corner cases
>>> in the algorithm, any "gotchas" that might be tricky, locking
>>> requirements, etc.
>>>[/color]
>> And used meaningful variable names.
>>
>> scott[/color]
>
> And supplied hint tests.
>[/color]
Grr... 'unit tests'.

--
Ian Collins.

On 15 Aug, 22:48, Chris Friesen <cbf...@mail.usask.ca> wrote:[color=blue]
> saneman wrote:[color=green]
> > Without any idea of what the above function is supposed to how would you
> > learn it?[/color]
>
> This is what comments are for. *[/color]

And, for clarification, comments such as:

M = zeros(1,p+1); // A p+1 array
left = zeros(1,p+2); // A p+2 array
right = zeros(1,p+2); // A p+2 array

are generally considered utterly useless, annoying cruft that
ought to be grounds for severe punishment. Comments
like this should get someone fired.

"saneman" <asdff@asd.com> writes:

[...]
[color=blue]
> function M = basis(i, u, k, U)
> p = k-1;
> M = zeros(1,p+1); // A p+1 array
> left = zeros(1,p+2); // A p+2 array
> right = zeros(1,p+2); // A p+2 array
> M(1) = 1;
> for j=1:p
> left(j) = u - U(i+1-j);
> right(j) = U(i+j) - u;
> sav = 0;
> for r=1:j
> L = left(j-r+1);
> R = right(r);
> tmp = M(r)/(R + L);
> M(r) = sav + R*tmp;
> sav = L*tmp;
> end
> M(j+1) = sav;
> end
> end
>
> Without any idea of what the above function is supposed to how would you
> learn it?[/color]

Look at the code which calls it. But in all seriousness, I
wouldn't. Assuming I knew what problem to solve, and that the existing
code doesn't solve it for some reason, I would strongly tend to
re-implement everything which was, either purposely or because of
neglect, written in a way that it needs to be decrypted rather than
read. Incomprehensible code is bad code and trying to understand it is
a waste of time -- the procedure will need to be repeated everytime
there is another reason to look at it, because one will have forgotten
all the details in the meantime.

Chris Friesen <cbf123@mail.usask.ca> writes:[color=blue]
> saneman wrote:[color=green]
>> Without any idea of what the above function is supposed to how would
>> you learn it?[/color]
>
> This is what comments are for. Any decent programmer *should* have
> prefaced this code with a description of what it does, any corner
> cases in the algorithm, any "gotchas" that might be tricky, locking
> requirements, etc.[/color]

One of the wisest things I have read in this respect was 'before
adding a comment explaining some piece of code, consider rewriting it
such that the comment is no longer needed'.

The problem with comments is that they are not executed and there is
no way to determine if they are correct (and often, what they really
mean) without understanding the code first. Someone will copy'n'paste
the code with comments elsewhere, modifiying the executed parts to
solve a somewhat different problem and not update the comments sooner
or later.