One of the most common types of advice we give at Y Combinator is to do things that don't scale. A lot of would-be founders believe that startups either take off or don't. You build something, make it available, and if you've made a better mousetrap, people beat a path to your door as promised. Or they don't, in which case the market must not exist. [1]
Actually startups take off because the founders make them take off. There may be a handful that just grew by themselves, but usually it takes some sort of push to get them going. A good metaphor would be the cranks that car engines had before they got electric starters. Once the engine was going, it would keep going, but there was a separate and laborious process to get it going.
Recruit
The most common unscalable thing founders have to do at the start is to recruit users manually. Nearly all startups have to. You can't wait for users to come to you. You have to go out and get them.
Stripe is one of the most successful startups we've funded, and the problem they solved was an urgent one. If anyone could have sat back and waited for users, it was Stripe. But in fact they're famous within YC for aggressive early user acquisition.
Startups building things for other startups have a big pool of potential users in the other companies we've funded, and none took better advantage of it than Stripe. At YC we use the term "Collison installation" for the technique they invented. More diffident founders ask "Will you try our beta?" and if the answer is yes, they say "Great, we'll send you a link." But the Collison brothers weren't going to wait. When anyone agreed to try Stripe they'd say "Right then, give me your laptop" and set them up on the spot.
There are two reasons founders resist going out and recruiting users individually. One is a combination of shyness and laziness. They'd rather sit at home writing code than go out and talk to a bunch of strangers and probably be rejected by most of them. But for a startup to succeed, at least one founder (usually the CEO) will have to spend a lot of time on sales and marketing. [2]
The other reason founders ignore this path is that the absolute numbers seem so small at first. This can't be how the big, famous startups got started, they think. The mistake they make is to underestimate the power of compound growth. We encourage every startup to measure their progress by weekly growth rate. If you have 100 users, you need to get 10 more next week to grow 10% a week. And while 110 may not seem much better than 100, if you keep growing at 10% a week you'll be surprised how big the numbers get. After a year you'll have 14,000 users, and after 2 years you'll have 2 million.
You'll be doing different things when you're acquiring users a thousand at a time, and growth has to slow down eventually. But if the market exists you can usually start by recruiting users manually and then gradually switch to less manual methods. [3]
Airbnb is a classic example of this technique. Marketplaces are so hard to get rolling that you should expect to take heroic measures at first. In Airbnb's case, these consisted of going door to door in New York, recruiting new users and helping existing ones improve their listings. When I remember the Airbnbs during YC, I picture them with rolly bags, because when they showed up for tuesday dinners they'd always just flown back from somewhere.
Fragile
Airbnb now seems like an unstoppable juggernaut, but early on it was so fragile that about 30 days of going out and engaging in person with users made the difference between success and failure.
That initial fragility was not a unique feature of Airbnb. Almost all startups are fragile initially. And that's one of the biggest things inexperienced founders and investors (and reporters and know-it-alls on forums) get wrong about them. They unconsciously judge larval startups by the standards of established ones. They're like someone looking at a newborn baby and concluding "there's no way this tiny creature could ever accomplish anything."
It's harmless if reporters and know-it-alls dismiss your startup. They always get things wrong. It's even ok if investors dismiss your startup; they'll change their minds when they see growth. The big danger is that you'll dismiss your startup yourself. I've seen it happen. I often have to encourage founders who don't see the full potential of what they're building. Even Bill Gates made that mistake. He returned to Harvard for the fall semester after starting Microsoft. He didn't stay long, but he wouldn't have returned at all if he'd realized Microsoft was going to be even a fraction of the size it turned out to be. [4]
The question to ask about an early stage startup is not "is this company taking over the world?" but "how big could this company get if the founders did the right things?" And the right things often seem both laborious and inconsequential at the time. Microsoft can't have seemed very impressive when it was just a couple guys in Albuquerque writing Basic interpreters for a market of a few thousand hobbyists (as they were then called), but in retrospect that was the optimal path to dominating microcomputer software. And I know Brian Chesky and Joe Gebbia didn't feel like they were en route to the big time as they were taking "professional" photos of their first hosts' apartments. They were just trying to survive. But in retrospect that too was the optimal path to dominating a big market.
How do you find users to recruit manually? If you build something to solve your own problems, then you only have to find your peers, which is usually straightforward. Otherwise you'll have to make a more deliberate effort to locate the most promising vein of users. The usual way to do that is to get some initial set of users by doing a comparatively untargeted launch, and then to observe which kind seem most enthusiastic, and seek out more like them. For example, Ben Silbermann noticed that a lot of the earliest Pinterest users were interested in design, so he went to a conference of design bloggers to recruit users, and that worked well. [5]
Delight
You should take extraordinary measures not just to acquire users, but also to make them happy. For as long as they could (which turned out to be surprisingly long), Wufoo sent each new user a hand-written thank you note. Your first users should feel that signing up with you was one of the best choices they ever made. And you in turn should be racking your brains to think of new ways to delight them.
Why do we have to teach startups this? Why is it counterintuitive for founders? Three reasons, I think.
One is that a lot of of startup founders are trained as engineers, and customer service is not part of the training of engineers. You're supposed to build things that are robust and elegant, not be slavishly attentive to individual users like some kind of salesperson. Ironically, part of the reason engineering is traditionally averse to handholding is that its traditions date from a time when engineers were less powerful—when they were only in charge of their narrow domain of building things, rather than running the whole show. You can be ornery when you're Scotty, but not when you're Kirk.
Another reason founders don't focus enough on individual customers is that they worry it won't scale. But when founders of larval startups worry about this, I point out that in their current state they have nothing to lose. Maybe if they go out of their way to make existing users super happy, they'll one day have too many to do so much for. That would be a great problem to have. See if you can make it happen. And incidentally, when it does, you'll find that delighting customers scales better than you expected. Partly because you can usually find ways to make anything scale more than you would have predicted, and partly because delighting customers will by then have permeated your culture.
I have never once seen a startup lured down a blind alley by trying too hard to make their initial users happy.
But perhaps the biggest thing preventing founders from realizing how attentive they could be to their users is that they've never experienced such attention themselves. Their standards for customer service have been set by the companies they've been customers of, which are mostly big ones. Tim Cook doesn't send you a hand-written note after you buy a laptop. He can't. But you can. That's one advantage of being small: you can provide a level of service no big company can. [6]
Once you realize that existing conventions are not the upper bound on user experience, it's interesting in a very pleasant way to think about how far you could go to delight your users.
Experience
I was trying to think of a phrase to convey how extreme your attention to users should be, and I realized Steve Jobs had already done it: insanely great. Steve wasn't just using "insanely" as a synonym for "very." He meant it more literally—that one should focus on quality of execution to a degree that in everyday life would be considered pathological.
All the most successful startups we've funded have, and that probably doesn't surprise would-be founders. What novice founders don't get is what insanely great translates to in a larval startup. When Steve Jobs started using that phrase, Apple was already an established company. He meant the Mac (and its documentation and even packaging—such is the nature of obsession) should be insanely well designed and manufactured. That's not hard for engineers to grasp. It's just a more extreme version of designing a robust and elegant product.
What founders have a hard time grasping (and Steve himself might have had a hard time grasping) is what insanely great morphs into as you roll the time slider back to the first couple months of a startup's life. It's not the product that should be insanely great, but the experience of being your user. The product is just one component of that. For a big company it's necessarily the dominant one. But you can and should give users an insanely great experience with an early, incomplete, buggy product, if you make up the difference with attentiveness.
Can, perhaps, but should? Yes. Over-engaging with early users is not just a permissible technique for getting growth rolling. For most successful startups it's a necessary part of the feedback loop that makes the product good. Making a better mousetrap is not an atomic operation. Even if you start the way most successful startups have, by building something you yourself need, the first thing you build is never quite right. And except in domains with big penalties for making mistakes, it's often better not to aim for perfection initially. In software, especially, it usually works best to get something in front of users as soon as it has a quantum of utility, and then see what they do with it. Perfectionism is often an excuse for procrastination, and in any case your initial model of users is always inaccurate, even if you're one of them. [7]
The feedback you get from engaging directly with your earliest users will be the best you ever get. When you're so big you have to resort to focus groups, you'll wish you could go over to your users' homes and offices and watch them use your stuff like you did when there were only a handful of them.
Fire
Sometimes the right unscalable trick is to focus on a deliberately narrow market. It's like keeping a fire contained at first to get it really hot before adding more logs.
That's what Facebook did. At first it was just for Harvard students. In that form it only had a potential market of a few thousand people, but because they felt it was really for them, a critical mass of them signed up. After Facebook stopped being for Harvard students, it remained for students at specific colleges for quite a while. When I interviewed Mark Zuckerberg at Startup School, he said that while it was a lot of work creating course lists for each school, doing that made students feel the site was their natural home.
Any startup that could be described as a marketplace usually has to start in a subset of the market, but this can work for other startups as well. It's always worth asking if there's a subset of the market in which you can get a critical mass of users quickly. [8]
Most startups that use the contained fire strategy do it unconsciously. They build something for themselves and their friends, who happen to be the early adopters, and only realize later that they could offer it to a broader market. The strategy works just as well if you do it unconsciously. The biggest danger of not being consciously aware of this pattern is for those who naively discard part of it. E.g. if you don't build something for yourself and your friends, or even if you do, but you come from the corporate world and your friends are not early adopters, you'll no longer have a perfect initial market handed to you on a platter.
Among companies, the best early adopters are usually other startups. They're more open to new things both by nature and because, having just been started, they haven't made all their choices yet. Plus when they succeed they grow fast, and you with them. It was one of many unforeseen advantages of the YC model (and specifically of making YC big) that B2B startups now have an instant market of hundreds of other startups ready at hand.
Meraki
For hardware startups there's a variant of doing things that don't scale that we call "pulling a Meraki." Although we didn't fund Meraki, the founders were Robert Morris's grad students, so we know their history. They got started by doing something that really doesn't scale: assembling their routers themselves.
Hardware startups face an obstacle that software startups don't. The minimum order for a factory production run is usually several hundred thousand dollars. Which can put you in a catch-22: without a product you can't generate the growth you need to raise the money to manufacture your product. Back when hardware startups had to rely on investors for money, you had to be pretty convincing to overcome this. The arrival of crowdfunding (or more precisely, preorders) has helped a lot. But even so I'd advise startups to pull a Meraki initially if they can. That's what Pebble did. The Pebbles assembled the first several hundred watches themselves. If they hadn't gone through that phase, they probably wouldn't have sold $10 million worth of watches when they did go on Kickstarter.
Like paying excessive attention to early customers, fabricating things yourself turns out to be valuable for hardware startups. You can tweak the design faster when you're the factory, and you learn things you'd never have known otherwise. Eric Migicovsky of Pebble said one of things he learned was "how valuable it was to source good screws." Who knew?
Consult
Sometimes we advise founders of B2B startups to take over-engagement to an extreme, and to pick a single user and act as if they were consultants building something just for that one user. The initial user serves as the form for your mold; keep tweaking till you fit their needs perfectly, and you'll usually find you've made something other users want too. Even if there aren't many of them, there are probably adjacent territories that have more. As long as you can find just one user who really needs something and can act on that need, you've got a toehold in making something people want, and that's as much as any startup needs initially. [9]
Consulting is the canonical example of work that doesn't scale. But (like other ways of bestowing one's favors liberally) it's safe to do it so long as you're not being paid to. That's where companies cross the line. So long as you're a product company that's merely being extra attentive to a customer, they're very grateful even if you don't solve all their problems. But when they start paying you specifically for that attentiveness—when they start paying you by the hour—they expect you to do everything.
Another consulting-like technique for recruiting initially lukewarm users is to use your software yourselves on their behalf. We did that at Viaweb. When we approached merchants asking if they wanted to use our software to make online stores, some said no, but they'd let us make one for them. Since we would do anything to get users, we did. We felt pretty lame at the time. Instead of organizing big strategic e-commerce partnerships, we were trying to sell luggage and pens and men's shirts. But in retrospect it was exactly the right thing to do, because it taught us how it would feel to merchants to use our software. Sometimes the feedback loop was near instantaneous: in the middle of building some merchant's site I'd find I needed a feature we didn't have, so I'd spend a couple hours implementing it and then resume building the site.
Manual
There's a more extreme variant where you don't just use your software, but are your software. When you only have a small number of users, you can sometimes get away with doing by hand things that you plan to automate later. This lets you launch faster, and when you do finally automate yourself out of the loop, you'll know exactly what to build because you'll have muscle memory from doing it yourself.
When manual components look to the user like software, this technique starts to have aspects of a practical joke. For example, the way Stripe delivered "instant" merchant accounts to its first users was that the founders manually signed them up for traditional merchant accounts behind the scenes.
Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks. It would be a little frightening to be solving users' problems in a way that wasn't yet automatic, but less frightening than the far more common case of having something automatic that doesn't yet solve anyone's problems.
Big
I should mention one sort of initial tactic that usually doesn't work: the Big Launch. I occasionally meet founders who seem to believe startups are projectiles rather than powered aircraft, and that they'll make it big if and only if they're launched with sufficient initial velocity. They want to launch simultaneously in 8 different publications, with embargoes. And on a tuesday, of course, since they read somewhere that's the optimum day to launch something.
It's easy to see how little launches matter. Think of some successful startups. How many of their launches do you remember? All you need from a launch is some initial core of users. How well you're doing a few months later will depend more on how happy you made those users than how many there were of them. [10]
So why do founders think launches matter? A combination of solipsism and laziness. They think what they're building is so great that everyone who hears about it will immediately sign up. Plus it would be so much less work if you could get users merely by broadcasting your existence, rather than recruiting them one at a time. But even if what you're building really is great, getting users will always be a gradual process—partly because great things are usually also novel, but mainly because users have other things to think about.
Partnerships too usually don't work. They don't work for startups in general, but they especially don't work as a way to get growth started. It's a common mistake among inexperienced founders to believe that a partnership with a big company will be their big break. Six months later they're all saying the same thing: that was way more work than we expected, and we ended up getting practically nothing out of it. [11]
It's not enough just to do something extraordinary initially. You have to make an extraordinary effort initially. Any strategy that omits the effort—whether it's expecting a big launch to get you users, or a big partner—is ipso facto suspect.
Vector
The need to do something unscalably laborious to get started is so nearly universal that it might be a good idea to stop thinking of startup ideas as scalars. Instead we should try thinking of them as pairs of what you're going to build, plus the unscalable thing(s) you're going to do initially to get the company going.
It could be interesting to start viewing startup ideas this way, because now that there are two components you can try to be imaginative about the second as well as the first. But in most cases the second component will be what it usually is—recruit users manually and give them an overwhelmingly good experience—and the main benefit of treating startups as vectors will be to remind founders they need to work hard in two dimensions. [12]
In the best case, both components of the vector contribute to your company's DNA: the unscalable things you have to do to get started are not merely a necessary evil, but change the company permanently for the better. If you have to be aggressive about user acquisition when you're small, you'll probably still be aggressive when you're big. If you have to manufacture your own hardware, or use your software on users's behalf, you'll learn things you couldn't have learned otherwise. And most importantly, if you have to work hard to delight users when you only have a handful of them, you'll keep doing it when you have a lot.
Notes
[1] Actually Emerson never mentioned mousetraps specifically. He wrote "If a man has good corn or wood, or boards, or pigs, to sell, or can make better chairs or knives, crucibles or church organs, than anybody else, you will find a broad hard-beaten road to his house, though it be in the woods."
[2] Thanks to Sam Altman for suggesting I make this explicit. And no, you can't avoid doing sales by hiring someone to do it for you. You have to do sales yourself initially. Later you can hire a real salesperson to replace you.
[3] The reason this works is that as you get bigger, your size helps you grow. Patrick Collison wrote "At some point, there was a very noticeable change in how Stripe felt. It tipped from being this boulder we had to push to being a train car that in fact had its own momentum."
[4] One of the more subtle ways in which YC can help founders is by calibrating their ambitions, because we know exactly how a lot of successful startups looked when they were just getting started.
[5] If you're building something for which you can't easily get a small set of users to observe—e.g. enterprise software—and in a domain where you have no connections, you'll have to rely on cold calls and introductions. But should you even be working on such an idea?
[6] Garry Tan pointed out an interesting trap founders fall into in the beginning. They want so much to seem big that they imitate even the flaws of big companies, like indifference to individual users. This seems to them more "professional." Actually it's better to embrace the fact that you're small and use whatever advantages that brings.
[7] Your user model almost couldn't be perfectly accurate, because users' needs often change in response to what you build for them. Build them a microcomputer, and suddenly they need to run spreadsheets on it, because the arrival of your new microcomputer causes someone to invent the spreadsheet.
[8] If you have to choose between the subset that will sign up quickest and those that will pay the most, it's usually best to pick the former, because those are probably the early adopters. They'll have a better influence on your product, and they won't make you expend as much effort on sales. And though they have less money, you don't need that much to maintain your target growth rate early on.
[9] Yes, I can imagine cases where you could end up making something that was really only useful for one user. But those are usually obvious, even to inexperienced founders. So if it's not obvious you'd be making something for a market of one, don't worry about that danger.
[10] There may even be an inverse correlation between launch magnitude and success. The only launches I remember are famous flops like the Segway and Google Wave. Wave is a particularly alarming example, because I think it was actually a great idea that was killed partly by its overdone launch.
[11] Google grew big on the back of Yahoo, but that wasn't a partnership. Yahoo was their customer.
[12] It will also remind founders that an idea where the second component is empty—an idea where there is nothing you can do to get going, e.g. because you have no way to find users to recruit manually—is probably a bad idea, at least for those founders.
Thanks to Sam Altman, Paul Buchheit, Patrick Collison, Kevin Hale, Steven Levy, Jessica Livingston, Geoff Ralston, and Garry Tan for reading drafts of this.
August 14, 2013
August 2, 2013
C/C++ call by value, call by address(pointer), and call by reference
Note: Here we set function A(a, b) as A and function B(c, d) as B to simplify.
Assume A call B, then the parameters of B are copied from A(i.e., any operation in B will not effected the variables in A).
void Swap(int x, int y)
{
int temp = a;
a = b;
b = temp;
}
Swap(value_A, value_B);
2. Call by address(pointer):
Transfer parameters by pointer. The main concept within this method is still the same as call by value; however, the "value" is a pointer, that's all.
void Swap(int* x, int* y)
{
int temp = *a;
*a = *b;
*b = temp;
}
Swap(&value_A, &value_B);
3. Call by reference:
Only support for C++ and the basic idea is aliases for each parameter.
void Swap(int & x, int & y)
{
int temp = a;
a = b;
b = temp;
}
Swap(value_A, value_B);
The pointer may be copied to caller function when we use "Call by pointer" to transfer parameters. However, if we want to change the value of pointer(i.e., isn't the variable directed to pointer) and generate a non-locally influence "Call by pointer" is not suitable enough. Hence, we have to use "Pointer to pointer" or "Reference to pointer".
Note: Pointer to pointer vs. Reference to pointer(i.e., int** vs. int*&)
Here we show a example to illustrate our concept:
int gInt = 0;
void ChangePointer(int* pInt)
{
pInt = &gInt;
}
void main()
{
int lInt = 1;
int* lPtr = &lInt;
ChangePtr(lPtr);
printf("%d\n", *lPtr);
}
In this case, the parameter *pInt is copied by lPtr in main(). (reference "2. Call by pointer")
4. Pointer to pointer:
int gInt = 0;
void ChangePointer(int** pInt)
{
*pInt = &gInt;
}
void main()
{
int lInt = 1;
int* lPtr = &lInt;
ChangePtr(&lPtr);
printf("%d\n", *lPtr);
}
In this case, result will print 0(i.e., value of gInt).
5. Reference to pointer:
int gInt = 0;
void ChangePointer(int* &pInt)
{
pInt = &gInt;
}
void main()
{
int lInt = 1;
int* lPtr = &lInt;
ChangePtr(lPtr);
printf("%d\n", *lPtr);
}
In this case, we will get the same result as "4. Pointer to pointer". Function declaration (int* &pInt) is the same as "reference pointer to pointer". Hence, lPtr in main() and pInt in ChangePointer() are identical.
July 31, 2013
Common interview examination(evaluation) for FW engineer (CS/EE)
1. Please show the C code for the result of adding up 1 to 100.
Sol. of Global: A variable that is accessible in every scope(unless shadowed).
Sol. 1: for(int i = 1; i <= 100; i++) printf("The result of adding up 1 to 100 is: %d\n", i);
Sol. 2: printf("The result of adding up 1 to 100 is: %d\n", ((1+100)*100)/2);
Note: reference below Question 11.
2. Code review. Note: run it under the 8-bit MCU.
int main()
{
char a, b, *ptra, *ptrb;
a = 255, b = 128;
printf("The value a is %d, b is %d\n", a, b);
ptra = b, ptrb = &a;
printf("The value ptra is %d, ptrb is %d\n", *ptra, *ptrb);
return -1;
}
Sol.: a = 255, b = 128; *ptra = undefined memory, *ptrb = 255.
3. Please describe ISR (Interrupt service routine).
Sol.: reference Google.
4. To explain RISC and CISC.
Sol. of RISC(Reduced Instruction Set Computer):
Advantage: Less power consumption, easy enhance the performance by pipelining due to simple CPU architecture.
Disadvantage: Code size will be larger than CISC architecture.
Example: ARM, ARC, Atom, and so on. (much popular)
Sol. of CISC(Complex Instruction Set Computer):
Advantage: Reduce the amount of instructions required to operate.
Disadvantage: Instruction behavior is much complex and hard to debug for programmers.
Example: Intel x86.
5. Please describe the differences between "global", "local", and "static(in function)" variables in C?
Sol. of Global: A variable that is accessible in every scope(unless shadowed).
Sol. of Local: A variable that is given local scope.
Sol. of Static: A special type of local variable is available in many mainstream languages which allows a value to be retained from one call of the function to another
6. With 2 cubes, please fill in numbers from 0 to 9 on the total 12 surfaces, therefore, the 2 cubes can show the combination of number 01~31.
Sol. 1 (riddle)
Cube 1: 0, 1, 2, 3, 4, 5
Cube 2: 0, 1, 2, 6, 7, 8
Sol. 2 (base on computer science knowledge)
Show target number 01 to 31 with binary type, i.e., 00001 to 11111. Due to the question asks us to fill ten numbers on 2 cubes total 12 surfaces we then adding one bit to the target numbers, i.e., 000001 to 011111. Therefore, we could divided the number into two parts. Here shows the number of 0 to 9 from decimal to binary, i.e., 000 to 111. We hence combine two surface number to fill the question demand.
Cube 1: 000, 001, 010, 011, 100, 101, i.e., 0, 1, 2, 3, 4, 5 in decimal
Cube 1: 000, 001, 010, 011, 110, 111, i.e., 0, 1, 2, 3, 6, 7 in decimal
7. What is script file (batch file) and its purpose? Is it a compiler or interpreter in general?
Sol.: reference Google, and it is much similar to interpreter.
8. With an binary number "010101010101010", after what action with a seed number twice can it still be the same number?
Sol.: XOR
9. What's the difference after executing call "Function" & "ISR"?
Sol.: ISR may record the executing program address and flag register information before interrupt occurred.
10. Please describe the difference between "Stack" and "Heap".
Sol. of Stack: FILO, descend address allocation, store "auto" variables(i.e., recycled automatic by system)
Sol. of Heap: FIFO, ascend address allocation, store "dynamic" variables(i.e., recycled manually by user)
Note: Here we only mentioned "default heap" in C/C++. However, there is still plenty branch in heap, such as fixed and movable heap in default heap and the other type "dynamic heap". Please reference Google by yourself for detail.
11. Please show an example about Brute-Force, Greedy method, and Heuristic mechanism in algorithm topic.
Sol. of Brute-Force:
Advantage: Get the global optimal solution.
Disadvantage: Non-efficiently, large time complexity.
Sol. of Greedy:
Advantage: Save much time by getting the locally optimal solution.
Disadvantage: does not in general produce an optimal solution
Sol. of Heuristic mechanism: ranks alternatives in various choice int order to make a decision.
Advantage: Improve the efficiency of algorithm by reducing the branch factor.
Disadvantage: Potentially exponential effort may be generated.
Note 1: Nonetheless a greedy heuristic may yield locally optimal solutions that approximate a global optimal solution in a reasonable time.
Note 2: "Traveler Question" could apply above algorithms to get its corresponding results.
12. What are the ALU, CU, Memory Mapping I/O, Data bus and PMU in CPU architecture or show the relation diagram?
Sol.: Arithmetic Logic Unit, Control Unit, Memory Mapping I/O, Data Bus, and Power Manage Unit, reference Google for detail.
13. Describe the Code data, Internal data, External data, Bit data in 8051 architecture.
Sol.: reference Google.
14. What are the differences between compiler time and run time in system programming, show and example?
Sol.: For error recognition, compiler error means that compiler will help programmer to find syntax error. The run time error means that compiler had accepted your code(i.e., syntax error free), but when program is running, OS may find unexpected error like memory address error due to our code meaning error.
15. What's the UI and shows an example?
Sol.: User Interface, e.g., Word.
16. What's the embedded system?
Sol.: Embedded system means that the system has its own CPU, memory, buffer, and so on to finish certain requirement.
17. What are the reentrance code and its purpose?
Sol.: Reentrant functions can be called recursively and can be called simultaneously by two or more processes. Reentrant functions are often required in real-time applications or in situations where interrupt code and non-interrupt code must share a function.
18. What's the recursive program and show an example without program?
Sol.: A recursive function is a special function that calls to itself. Example: N! = N*(N-1)*(N-2)…2*1, We can use recursive function to calculate the factorial of a positive integer N.
19. Show an example(story) about using the hash table in your life?
Sol.: The BMI rate of the studetns in a class, we can insert the weight and the height of each student in class, and the weight and the height will output a rate by the BMI equation. So the BMI table of the students can be considered as a hash table .
20. Please describe the major difference between Harvard and Von neumann architecture briefly.
Sol.: The main difference is instruction and data are using separated bus.
Advantage: Two buses are used to both data transfer and instruction fetches simultaneously.
Disadvantage: Difficult to implement.
21. As benary 10101010101000011111111010101010101111 mode 3?
Sol. 1:
2^0 mod 3 = 1
2^1 mod 3 = 2
2^2 mod 3 = 1
2^3 mod 3 = 2
2^4 mod 3 = 1
2^5 mod 3 = 2 and so on
2^2 mod 3 = 1
2^3 mod 3 = 2
2^4 mod 3 = 1
2^5 mod 3 = 2 and so on
so we can find out the regular feature as follow:
binary : 10 1010 1010 1000 0111 1111 1010 1010 1010 1111
remainder : 21 2121 2121 2121 2121 2121 2121 2121 2121 2121
The answer we can simplify as: (2+4+4+2+4+6+4+4+4+6) mod 3 = 1
binary : 10 1010 1010 1000 0111 1111 1010 1010 1010 1111
remainder : 21 2121 2121 2121 2121 2121 2121 2121 2121 2121
The answer we can simplify as: (2+4+4+2+4+6+4+4+4+6) mod 3 = 1
Sol. 2:
unsigned MOD3_1(unsigned input)
{
unsigned result;
do {
result = 0;
while(input) {
result += input & 0x3;
input >>= 2;
}
input = result;
} while( result > 3 )
return ( number == 3 ) ? 0 : number;
}
Sol. 3:
unsigned MOD3_2(unsigned input)
{
unsigned result = input, temp;
while( result > 3 ) {
temp = result >> 2;
result -= ( temp << 2 ) + temp;
}
return ( result == 3 ) ? 0 :result ;
}
Sol. 4:
Setp 1. Set num_A as the sum of bit is equal to 1 of odd number.
Setp 2. Set num_B as the sum of bit is equal to 1 of even number.
Setp 3. Set result = num_A + 2 * num_B
Setp 4. when result >= 3 then back to Step 1.
Note: this method is using "Multiplicative Inverse" to inductive solution.
22. Explain void (*signal(int sig, void (*func)(int)))(int) in C syntax.
Sol.: Here I use the main idea within interpreter to enable any programmer to parse C declaration. (Note: signal is inside parenthesis, we hence resolve it first.)
+-----------------------------+
| +---+ |
| +---+ |+-+| |
| ^ | |^ || |
void (*signal(int, void (*fp)(int)))(int);
^ ^ | ^ ^ || |
| +------+ | +--+| |
| +--------+ |
+----------------------------------+
→ signal is a function passing an int(i.e., sig) and
→ fp is a pointer to
→ fp is a pointer to a function passing int returning
→ fp is a pointer to a function passing int returning nothing(i.e., void)
→ signal is a function passing an int and a pointer(i.e., fp) to a function passing int returning nothing(i.e., void) returning
→ signal is a function passing an int and a pointer(i.e., fp) to a function passing int returning nothing(i.e., void) returning a pointer to
→ signal is a function passing an int and a pointer(i.e., fp) to a function passing int returning nothing(i.e., void) returning a pointer to a function passing an int returning
→ signal is a function passing an int and a pointer(i.e., fp) to a function passing int returning nothing(i.e., void) returning a pointer to a function passing an int returning nothing(i.e., void)
July 30, 2013
July 27, 2013
Disrupting Class 來上一堂破壞課 ISBN: 978-986-157-603-9
Author: Clayton M. Christensen, Michael B. Horn, Curtis W. Johnson
Translator: 袁世珮
ISBN: 978-986-157-603-9
1. Multiple Intelligence (MI) 多元智能 provided by Howard Gardner
* 語言：以文字來思考，並運用語言表達複雜意思的能力。
* 邏輯數理：計算、量化、考慮前提和假設、進行複雜數學運算的能力。
* 空間：以三度空間思考的能力；理解內在與外在的意象；再造、轉換或修正影像；在空間中移動自己或物體；創造或解讀圖像資訊的能力。
* 身體動覺：操作物體和施展精細肢體技能的能力。
* 音樂：分辨和創作音準、旋律、節奏和聲調的能力。
* 人際：理解並有效與人互動的能力。
* 自知：建構正確自我形象，根據這個體認去規劃和指引人生的能力。
* 自然主義：觀察自然的模式、找出和分類物體、理解自然和人為系統的能力。
2.
July 20, 2013
思考的藝術 52個非受迫性思考錯誤 ISBN: 978-986-272-211-4
Author: Rolf Dobelli
Translator: 王榮輝
ISBN: 978-986-272-211-4
在日常生活中，由於成功者的能見度壓倒性地高過失敗者，因此，人們總會系統性地高估了獲得成功的希望。
2. The Swimmer's Body Illusion (泳將身材的錯覺)
由於將篩選標準與結果兩者倒果為因的相互錯置。
3. The Overconfidence Effect (過度自信效應)
我們總是系統性地高估了我們在預測方面的知識與能力，甚至可以說是嚴重高估了。
4. Social Proof (社會認同)
當我們的舉止與周遭的人相同時，該舉止就是對的；換言之，當越多人認為某種想法是對的，這想法也就越正確。
5. The Sunk Cost Fallacy (沉默成本謬誤)
當你在某檔股票上被套的越牢，你就會把那檔股票抱得越緊。
6. The Reciprocity (互惠)
人們其實很難抵擋虧欠感！
7. The Confirmation Bias Part I (確認偏誤 壹)
確認偏誤是所有思考錯誤之母，這是一種將新資訊解釋成合乎既有理論、世界觀或信念的傾向。
8. The Confirmation Bias Part II (確認偏誤 貳)
續
9. The Authority Bias (權威偏誤)
在面對權威時，我們的獨立思考變會不由自主地矮一截！
10. The Contrasted Effect (對比效應)
當我們在觀察事物時，若同時出現某個可供參照的對象，而這個對象較醜、較便宜或較小，我們就會因此判定原本所觀察的事物較美、較貴或較大。
11. The Availability Bias (現成偏誤)
我們會借助一些易取得的現成例證，為自己描繪出一幅世界圖像。我們的大腦是根據「戲劇性原則」在思考，不是根據「量化原則」。
12. Die Es-wird-schlimmer-bevorses-besser-kommt-Falle (「在好轉之前會先惡化」的陷阱)
當專業人士對於其專業上的某些事情根本一無所知、或是沒有保握時，他就會請出在好轉之前會先惡化這件道具。
13. The Story Bias (故事偏誤)
故事扭曲且簡化了事實。我們總是容易被故事吸引，卻拒卻抽象的事實於千里之外。
14. The Hindsight Bias (後見之明偏誤)
從後件知名的角度來看，所有已發生的事，似乎都緊密地遵循著某種看似合理的必然性。
15. The Chauffeur Knowledge (司機的知識)
具有真才實學的人明瞭「知之為知之，不知為不知」。
16. Illusion of Control (控制的錯覺)
我們相信我們可以控制或影響某種事物；但實際上，我們根本無能為力。
17. The Incentive Superresponse Tendency (激勵過敏傾向)
人們會對激勵有所反應，但他們的反應有時並不符合激勵背後的意圖。「千萬別去問理髮師，我究竟需不需要理頭髮。」
18. Regression Toward the Mean (均值迴歸)
極端的成果會與教部極端的成果交戶更迭。
19. The Tragedy of the Common (公地悲劇)
我們實在不能夠只望人類的道德性，唯一可行的路徑只有兩條：「私有化」或「管理」。
20. The Outcome Bias (結果偏誤)
我們總是傾向用「結果」來評斷「決定」，而不是根據「當時的決定過程」來評斷「決定」。
21. The Paradox of Choice (選擇的弔詭)
大量選擇容易令人內心茫然→導致不良的決定→不滿。
22. The Liking Bias (討喜偏誤)
當別人表現的對我們越有好感，我們就愈容易向這些人買東西，或是對這些人伸出援手。
23. The Endowment Effect (稟賦效應)
當我們擁有某件東西，主觀上我門就會顯著地位這件東西加值。
24. The Wonder (奇蹟)
那些所謂不可能的巧合，雖然極為罕見，但絕對是可能發生的事。它們的發生並不令人意外；相反地，若是它們自始至終從來都未發生，那才真叫人意外！
25. Groupthink (團體迷思)
一個由一堆聰明人組成的團體，因為每個成員都刻意去迎合被信以為真的共識，最終這個團體便會做出一些愚蠢的決定。
26. The Neglect of Probability (輕忽機率偏誤)
我們會對期待發生的事件之規模有所反應，至於它們的發生機率，我們則近乎無感。除了風險為靈的情況外，我們其實相當拙於明辨不同分險的危險程度。
27. The Zero-Risk Bias (零風險偏誤)
只有零風險可以治好我們莫名的恐懼。但試著在沒有什麼事是百分百確定的情況下過活！
28. The Scarcity Fallacy (稀少性謬誤)
請謹評價格與效用評斷一件事物，不管它是否很稀少。
29. The Base-Rate Neglect (忽視基本比率)
精確的描述誤導了我們，讓我們不能冷眼面對統計事實。
30. The Gambler's Fallacy (賭徒謬誤)
人類普遍相信冥冥之中存在著某種可以平衡命運的力量。因此，請仔細看清楚所面對的情況，究竟是獨立事件或非獨立事件。
31. The Anchor (錨定)
我們會以一些熟知的事物當初發點，藉此推估出未知的事物。
32. The Induction (歸納法)
一個反例就足以推翻一個經過上千次證明的理論！
33. The Loss Aversion (損失規避)
在獲利與損失規模相同的情況下，損失所造成的情緒反應，是獲利的兩倍！
34. Social Loafing (社會性懈怠)
只要個人可以藉由團體混水摸魚，並且不會被直接看穿，這種效應就會浮現。
35. The Exponential Growth (指數增長)
當遇到與成長率有關的事物，請不要相信自己的直覺。
36. The Winner's Curse (贏者詛咒)
由於標的物的價值並不確定，我們為了在競爭中勝出，因此，一場拍賣會裡的贏家，往往是事實上的輸家。
37. The Fundamental Attribution Error (基本歸因謬誤)
當人們在解釋一些事情時，往往傾向於自動高估人物對於事情所造成的影響。
38. The False Causality (錯誤的因果關係)
關聯性並非因果關係。
39. The Halo Effect (月暈效應)
我們往往會迷失在某個觀點上，並且用這個觀點去設想事物的全貌。
40. The Alternate Path (替代路徑)
請看清經由高風險替代路徑所導致的成功。
41. The Forecast Illusion (預測的錯覺)
只有兩種人會去預言未來：「一無所知的人」或「不曉得自己其實一無所知的人」。
42. The Conjunction Fallacy (聯結謬誤)
我們會直觀地對故事做和諧化或合理化的理解。而直觀的思考有一項缺點，它無法抗拒合情合理的故事。
43. Framing (框架)
對於同樣一件事，我們會因陳述方式有所不同，而產生不同的反應。
44. The Action Bias (行動偏誤)
當我們遇上情況不明的場面時，內心便會泛出一股採取行動的衝動。
45. The Omission Bias (不作為偏誤)
舉凡作為與不作為都能導致損害發生的場合，便會出現不作為偏誤。
46. The Self-Serving Bias (自利偏誤)
成功的話，全部都是自己的功勞；失敗的話，統統都是外在的因素。
47. Hedonic Treadmill (享樂跑步機)
不斷工作，追求升遷，希望藉此享有更多；儘管如此，我們依然不會感到更幸福。
48. The Self-Selection Bias (自我選擇偏誤)
每當自己是抽樣裡的一小部分，就容易落入自我選擇偏誤裡。
49. The Association Bias (聯想偏誤)
經驗容易引導我們犯下錯誤。
50. The Beginner's Luck (新手的運氣)
請嘗試去證偽自己的假設。
51.The Cognitive Dissonance (認知失調)
對自己撒點小謊，讓自己好過些的心理補償。
52. The Hyperbolic Discounting (雙曲貼現)
做決定的時間點與獲利的時間點愈接近，我們的「情緒利率」就愈容易跟著調升。
在群體裡，容易依照別人的想法過活；在孤獨裡，容易一照自己的想法過活。
可是，唯有在群體裡還能夠保持著特立獨行，才值得我們注意。 ─ 愛默生(Ralph Waldo Emerson)
Subscribe to:
Posts (Atom)