16
$\begingroup$

I was reading this on Math SE. The basic question is :

Assume that someone wishes to study something advanced; one way to do this would be to start off from basics and build up. But the "bigger picture" can get lost in this process. One more method (which I prefer to call Recursive Wiki) is to pick up a paper and Google/Wiki the terms which one does not understand; Read them. Within them will be terms which are new; Google/Wiki them till you reach the "base case" of knowing the material thoroughly. Work Backwards till you understand the paper thoroughly. Repeat for other papers. This will allow knowledge gain while maintaining motivation. But, it may cause problems in fundamentals.

It is based on an article by Prof. Vakil from Stanford. Here is an excerpt:

.....mathematics is so rich and infinite that it is impossible to learn it systematically, and if you wait to master one topic before moving on to the next, you'll never get anywhere. Instead, you'll have tendrils of knowledge extending far from your comfort zone. Then you can later backfill from these tendrils, and extend your comfort zone; this is much easier to do than learning "forwards". (Caution: this backfilling is necessary.....

The general consensus among the opponents of such a method was that it was OK for fields like Algebraic Geometry where 100s of papers are published per quarter or String Theory research where if you tried to build up mathematical basics before you touched String Theory, you would be 80 with Alzheimer's. My question is: Is this a good strategy for studying CompSci?

Since Comp Sci is so multidisciplinary (and it is usually a necessity for engineers to know both Math and Computing), is such a recursive mode of study good enough for academic research? Or is the traditional mode too good to be replaced?

For instance, I needed to know about Translation Lookaside Buffer (TLB) with 0 knowledge of Operating Systems.

My recursive path (as per wikipedia) was:

TLB > Cache > (Back) TLB > Page Table > (Back) TLB > Virtual Address > (Back) TLB > Reread. Done

I feel I know what TLB is and if I encounter it again, I'll know whats going on. Am I deceiving myself?

$\endgroup$

1 Answer 1

9
$\begingroup$

I don't think that you're deceiving yourself necessarily, but you should be careful using what you've learned. In this case it's relatively easy. If you need to design your code with TLB-awareness in mind, you've probably got what you need now, and you can prove this to yourself by writing programs. However, if someone asked you to design and implement a TLB, you might need to go do some more research.

I think the important part of learning anything is to also try to understand the limits of your knowledge.

The tendrils approach is clearly a good method for certain kinds of learning. You should use it where appropriate. The nice thing about the other method is that you learn lots of other things along the way which can be helpful in building your ideas and plans for attacking problems. E.g., you now know something about TLBs, but if you didn't encounter and teach yourself about non-temporal accesses (say, to pick an example at random) while you were learning about TLBs, you may have missed a hugely important piece of knowledge about optimizing memory systems. If you'd started at the very bottom in learning about memory systems on chips, you probably would have encountered (however shallowly) non-temporal accesses, so you'd know that you also need to keep these in mind.

I suggest that you judiciously sprinkle learning in both categories as you work to solve your problems. It's rare that you start with a fully-formed problem statement anyway, so there will be some mix of working forwards and backwards and iteration about the nature of the problem as you work through it.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.