Prev: AES and algebra
Next: Online Coding/Programming competition
From: Paul N on 18 Jan 2010 15:51
On 18 Jan, 18:17, Chad <cdal...(a)gmail.com> wrote:
> Oh yeah. I forgot that current->data is outside the loop. And this
> reminds me that a while back I had asked a similar question on
> comp.lang.c. I'm suspecting that there is some underlying programming
> concept that I haven't quite grasped yet.

Perhaps you mean the concept of "look before you leap"?

For instance, if you want to find the end of a linked list, then this
code:

while (thing) { thing = thing -> next; }

will not work because you run off the end of the list before you stop.
And once thing is NULL, you can't do "thing = thing -> prior" to get
back into the list again.
From: BGB / cr88192 on 18 Jan 2010 15:53

"Moi" <root(a)invalid.address.org> wrote in message
news:6d51$4b54beb0$5350c024$25967(a)cache110.multikabel.net...
> On Mon, 18 Jan 2010 12:39:13 -0700, BGB / cr88192 wrote:
>
>> "Chad" <cdalten(a)gmail.com> wrote in message
>> news:56f0c391-4d56-4159-b864-be6f489ac9dd(a)b10g2000yqa.googlegroups.com...
>> On Jan 18, 9:55 am, Daniel Pitts
>> <newsgroup.spamfil...(a)virtualinfinity.net> wrote:
>>> Chad wrote:
>

<snip>

>>
>> but, I guess likely how one reasons about things will depend a lot on
>> the person.
>> but, visualization is a strategy that often works well in my case I
>> guess...
>
> Practice / experience does help.
> My experience (about 20 years now) has lead me
> to the attitude that I stopped expecting to get it right
> on the first attempt.
>
> For inserting / deleting form (or merging ...) double linked lists
> or performing a rotation on a BST (with parent pointers ...),
> I certainly need pencil and paper (just draw the before- and
> after- graph, add names to the nodes and arrows, and the program
> is almost ready.),
>

yes, ok.

I rarely use pencil/paper, but may often represent diagrams/... in-mind.


I think I also keep a lot of code in mental "templates", where I may end up
recalling a chunk of text or similar representing a particular algorithm, or
a few chunks of basic information combined with rules for how to "expand"
these into a more comprehensive piece of code (for example, I have noted
before that it seems a large amount of vector math, ... exists mentally in
such a "compacted" form...).

however, I have little idea just how much is "stored" in this way, how
exactly it is actually represented, how reliable it is, ...

I suspect I can mentally buffer around 5-10 kloc or so on a short-term basis
(minutes or so), and I suspect a bit more but in an "abstracted" form
(mentally, I get the function prototypes, but it is difficult to "expand"
this to the actual code without going and looking up, in which case it
resides in this short-term "buffer").

I have also noted that this does seem to have an "issue" for older
information:
sequencing seems to be one of the first things to break, where the items are
remembered, but not in the correct order (this usually followed by the exact
names, ... which seem to degrade mostly as a property of their length, ...
numbers seem to degrade primarily in terms of digits, with digits liking to
"migrate" to adjacent digits, and then later, often to letters or other
characters).

....


I have also noted before that I am very poor at working with new
information, or information presented in an unfamiliar form.

mentally, I think it tends to be worked with a lot as lego-like blocks.
detailed structural manipulations, such as those involved in math, often
make the "structure" unrecognized and then very difficult to think about
(nevermind the mental-granding and possibility-trying to figure out how to
work through the math in a reasonable timeframe...).

apparently, this was a big killer in a physics class, where I can do things
well-enough if everything is in a familiar form, but I was left dealing with
everything in an unfamiliar form (mathematical notation, continuous-time
calculations, ...) which apparently killed my thinking abilities (I can't
easily think continuous-time, as I am naturally inclined to think in terms
of discrete time-stepping or events, ...).



> Plus, a lot of testing.
> And there are always more ways to get it wrong.
> (more than you thought of initially)
>

yep, testing is good...

sometimes one can be lazy, and use the "assume for now it will work, maybe
test later" strategy, but this is not good to do too much without testing,
as it can lead to lots of bugs which may jump up some-time later due to
untested code.

thus, it is better if possible to try to keep code small (so that bugs are
easier to shake out), except that code may like to inflate to such an
extreme that one soon finds some of their "small" components to have
expanded to maybe > 100 kloc, and an overall codebase extending its reaches
into the Mloc range...

then one may find that there is no telling how many bugs lurk within the
depths...


> HTH,
> AvK
>


From: BGB / cr88192 on 18 Jan 2010 15:58

"Paul N" <gw7rib(a)aol.com> wrote in message
news:9ffda5b8-c5f6-4164-bb56-fdc6791fadfe(a)a32g2000yqm.googlegroups.com...
> On 18 Jan, 18:17, Chad <cdal...(a)gmail.com> wrote:
>> Oh yeah. I forgot that current->data is outside the loop. And this
>> reminds me that a while back I had asked a similar question on
>> comp.lang.c. I'm suspecting that there is some underlying programming
>> concept that I haven't quite grasped yet.
>
> Perhaps you mean the concept of "look before you leap"?
>
> For instance, if you want to find the end of a linked list, then this
> code:
>
> while (thing) { thing = thing -> next; }
>
> will not work because you run off the end of the list before you stop.
> And once thing is NULL, you can't do "thing = thing -> prior" to get
> back into the list again.

for some uses, it may be useful to instead keep a 'prev' pointer:
prev = NULL;
while (thing) { prev = thing; thing = thing -> next; }

granted, this would likely be pointless in this case, but this is also
useful for some cases...



From: Pascal J. Bourguignon on 18 Jan 2010 16:12
Chad <cdalten(a)gmail.com> writes:

> On Jan 18, 9:55�am, Daniel Pitts
> <newsgroup.spamfil...(a)virtualinfinity.net> wrote:
>> Chad wrote:
>> > At the following url...
>> >http://cslibrary.stanford.edu/110/BinaryTrees.html
>>
>> > They have the following as a solution to finding the min value of a
>> > binary tree...
>> > 4. minValue() Solution (C/C++)
>> > /*
>> > �Given a non-empty binary search tree,
>> > �return the minimum data value found in that tree.
>> > �Note that the entire tree does not need to be searched.
>> > */
>> > int minValue(struct node* node) {
>> > � struct node* current = node;
>>
>> > � // loop down to find the leftmost leaf
>> > � while (current->left != NULL) {
>> > � � current = current->left;
>> > � }
>>
>> > � return(current->data);
>> > }
>>
>> > Why do they do �'current->left != NULL' in the while loop instead of
>> > something like 'current != NULL'? �Ie, something like the
>> > following....
>>
>> > int minValue(struct node* node) {
>> > � struct node* current = node;
>>
>> > � // loop down to find the leftmost leaf
>> > � while (current != NULL) {
>> > � � current = current->left;
>> > � }
>>
>> > � return(current->data);
>> > }
>>
>> The reason should be obvious if you think about what current->data means
>> after the loop has finished. �If you loop until current is NULL, then
>> you end up with NULL->data, which is not what you want, and likely to be
>> undefined behavior anyway.
>>
>
> Oh yeah. I forgot that current->data is outside the loop. And this
> reminds me that a while back I had asked a similar question on
> comp.lang.c. I'm suspecting that there is some underlying programming
> concept that I haven't quite grasped yet.

Don't they teach Hoare anymore?


When you have a while loop, the post condition is "not the stop
condition and the postcondition of the body".

while(current!=NULL){
whatever();
assert(post_of_body);
}
assert(not(current!=NULL) and post_of_body);
// <=>
assert((current==NULL) and post_of_body);

--
__Pascal Bourguignon__ http://www.informatimago.com/
From: Chad on 18 Jan 2010 16:25
On Jan 18, 12:51 pm, Paul N <gw7...(a)aol.com> wrote:
> On 18 Jan, 18:17, Chad <cdal...(a)gmail.com> wrote:
>
> > Oh yeah. I forgot that current->data is outside the loop. And this
> > reminds me that a while back I had asked a similar question on
> > comp.lang.c. I'm suspecting that there is some underlying programming
> > concept that I haven't quite grasped yet.
>
> Perhaps you mean the concept of "look before you leap"?
>
> For instance, if you want to find the end of a linked list, then this
> code:
>
> while (thing) { thing = thing -> next; }
>
> will not work because you run off the end of the list before you stop.
> And once thing is NULL, you can't do "thing = thing -> prior" to get
> back into the list again.

Yes. Maybe I'm wrong, but wouldn't 'thing' in the while loop *get*/
*retrieve* the value? Then 'thing = thing -> next' would not only
*get*/*retrieve* the value, but then also store that value in 'thing'.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: AES and algebra
Next: Online Coding/Programming competition