Confessions of a researchaholic

June 27, 2018

Project pivot versus switch

Filed under: Real — liyiwei @ 12:03 pm
Tags: ,

When we get stuck in a project, the issues could lay on the project or us.
For the former, switching to a different project might help.
For the latter, we should fix our own issues as otherwise no project will work out.

It is not always clear where the issues are.
But if someone keeps on switching projects, it could be a sign of individual instead of project issues.

Even if a project does not work out, it is usually better to pivot by continuous transforming the ideas during progress, instead of discontinuous switch to a separate project without coherence.

Download (SVG, 8KB)

June 8, 2018

Satoshi-Nakamotoism

Filed under: Real — liyiwei @ 9:54 am
Tags: , ,

Aside from rare exceptions like Steve Jobs or Albert Einstein, people usually do not care who is behind an invention or discovery.
(As a quick experiment, can you name the Nobel Prize winners in the most recent year, especially if you are not working in the related fields?)

Thus, I would prioritize our outcomes over our egos for publicity.

May 28, 2018

How to screen PhD/intern applicants

Filed under: Real — liyiwei @ 5:00 pm
Tags:

April 15, 2018

More about choosing graduate programs

Filed under: Real — liyiwei @ 5:19 pm
Tags:

Recently several people asked me about choosing graduate programs. I answered about this before, but some specific cases might still help.

Q: Choose a program that offers financial support over one that does not.

This is certainly a sensible decision, especially if you are cash strapped, even though that is not what I did (see below).

Q: Choose a MS program that is more likely to lead to the PhD program of the same school/department.

In general yes, if you can find a good adviser whom you can convince to take you as a PhD student by doing good research with him or her.

Q: Choose between a school/adviser good at a direction or a methodology

These are different. For example, you might be interested in computer graphics (direction) and want to apply machine learning (methodology) in some way. Should you choose a professor in computer graphics who knows a bit (but not much) about machine learning, or a machine learning expert who is not really doing computer graphics?

Always pick the one who is better at identifying the problems (directions) than the one who is better at suggesting solutions (methods). Solving a wrong problem (unimportant, too easy, too difficult, too crowded, etc.) can completely derail your research career. In contrast, you can find domain experts to collaborate after identifying a good direction.

[I will add more when I receive more questions.]

When I made my decision more than 20 years ago, it was pretty easy: I wanted to go to a top school in the Bay Area, so I basically had only two choices. And I heard from one around Christmas but not another one until the next April or May. What was more difficult is that I only got scholarships from schools in the east coast, and my family preferred me to go there.

February 18, 2018

The most useful faculty advice I have ever received

Filed under: Real — liyiwei @ 4:53 pm
Tags:

From Peter Shirley if I remember correctly:

Do not perform too well on tasks that I do not enjoy so that they would not get assigned to me in the future.
🙂

January 1, 2018

Bean-counting

Filed under: Real — liyiwei @ 12:39 pm
Tags: ,

This has been a widely discussed topic, but when it comes to academic publishing, focus on quality over quantity.

Take my PhD adviser as an example. At this moment, he has “only” 27 journal papers and 40 conference papers according to dblp, but nearly 40000 citations, including 10+ papers with 1000+ citations, according to Google scholar.
In comparison, there are people around his seniority and in our fields (for calibration) with roughly 10-times publications but only one-tenth of citations.
(Citation is one of the mostly commonly used measure for quality/impact, but others are possible, such as products.)

He once told me that the best timing to publish papers is when people beg us to do so (using Brain Curless’ first SIGGRAPH paper as an example). That is probably too extreme, but publishing low quality papers not only wastes our time (it is better to go out and play) but also dilutes our reputation.

November 1, 2017

Simplification

Filed under: Real — liyiwei @ 10:51 am
Tags:

“Everything should be made as simple as possible, but not simpler.” – Einstein

When facing a seemly daunting, difficult, or complex problem, a good strategy is to simplify (in the sense of mesh simplification) the scenario as much as possible, during which the thought process can bring great clarify and insight.

July 18, 2017

Picking research problems

Filed under: Real — liyiwei @ 10:12 am
Tags:

This is the most important stage of conducting research. I do not claim to know the answer, and my experience is limited to specific fields in CS, but (as before) I write this down to get feedbacks and to save the trouble of repeating myself.

Listen to people facing real problems instead of trusting the future work sections in research papers. If there are good (to elaborate) users or product people around you, ask what they need.

Identify concrete problems first, before thinking about other parts like idea novelty, algorithm framework, etc. (Look for hammers after nails.)
If we can find a trivial solution for an important problem, great, solve it, and quickly move on to something else.
This beats the alternative of coming up with a fancy method that does not solve anything.

The problem should fit our interest and expertise well enough, so that we have sufficient willingness and capability to address it.

If the problem is not sufficiently clear or convincing, the research project is probably a waste of time.
If the solution to the problem is not clear or convincing at the beginning, it is not only quite normal but also a potential sign that the problem is sufficiently non-trivial.

March 8, 2017

I almost dropped out of my PhD study

Filed under: Real — liyiwei @ 1:10 pm
Tags: ,

I joined the Stanford computer graphics lab in 1996 summer after passing the entrance test of porting the light field viewer from SGI to PC. When Pat Hanrahan gave his (last ?) SIGGRAPH talk, I was hiding on stage behind him, doing some live demos while trying not to screw up.

After that, I had no idea what I was supposed to do, so I attempted at least 20 different projects. At some point I almost dropped out to join a certain startup (well if I did I probably could retire by now, but who knows). Fortunately, my advisor, Marc Levoy, was very supportive. Eventually I took courses taught by Robert Gray and David Heeger, whose TSVQ and texture synthesis works inspired me to do a course project. I wrote it up and submitted my first single-authored paper to SIGGRAPH 1999, with scathing reviews, mostly because I did not know how to write yet. I took a writing class, and with the help of my adviser, submitted it again next year which eventually became my first SIGGRAPH paper, in 2000, 4 years after I started my PhD program.

For PhD candidates concerned about not publishing enough in their first, second, or even third year, I hope my experience can help you chill out.
I doubt how many of you could have done worse than I did during the initial period.
Granted, your situation might be different from mine (e.g. some degree program is only 4 years and your adviser might not be as cool as mine), but I want to let you know that your PhD study is likely the only period in your life that you can literally try anything you like without the real consequences of failure. So have fun, and you can learn something from everything you have tried, as I did from these 20+ projects.

March 7, 2017

Testing and debugging code

Filed under: Real — liyiwei @ 5:55 pm
Tags:

This post is meant for newbies.

Basically, your code should be highly modular, consisting of well-designed classes and functions. Then, unit test each module. This is much easier than trying to debug a large system, or a monolithic piece of code.

I debug almost entirely based on intuition, and never relied on any low level tools like tracers, even when I was a beginner.

For the ray tracing exercise, if you start with the Shirley series, the code should already be modular and incremental. After you finish that, you should have better foundation to design modular code for the ray tracing book by Glassner et al.

Feel free to ask specific questions (e.g. via the comments field of this post), and I will answer by updating and improving this post.

Next Page »

Theme: Rubric. Get a free blog at WordPress.com