text:
Poker/Hold'em

Texas Hold'em is played in the main event of the World Series of Poker, and is considered by many the most complex and strategic form of poker. In the game everyone tries to make the best 5 card hand they can out of five community cards and two personal cards. In modern games the blinds are then posted. The blinds are forced bets. The player to the left of the dealer puts in the small blind, and the player to the left of the small blind pays the big blind, which is typically twice the small blind. This represents the minimum bet once the action begins. Each player is dealt two cards face down called the hole cards, which they aim to keep secret. Then the first round of betting ensues, with the player to the left of the big blind acting first. After this, a card is discarded and three cards are dealt face up in the middle of the table. These cards are called the flop, and are the first three community cards. There is another round of betting, beginning this time with the small blind. One more card is discarded and one more community card is dealt, called the turn. There is another round of betting, again starting with the small blind, then a discard, and then the final card, called the river, is dealt. There is one final round of betting and then the players who have not folded turn over their cards.

Basic Strategy of Texas Holdem

''Note this strategy guide is for playing no limit texas holdem. Slightly different considerations apply when playing limit or pot limit holdem. It is also heavily oriented towards tournament play, since this is the format where no-limit is most commonly played.''

Position
Position refers to how many players must act after your actions. It is generally preferable to be the last player to act, since your opponents will often reveal some information about their hand by betting or checking (sometimes they may be trapping you by slowplaying or checkraising) before you act, because you have the choice of taking a free card if no-one else has bet, and for various other reasons. Position is probably the single most important factor in no-limit hold'em. The person acting as dealer (also called "being on the button") will always be last to act (except in the first round), and is thus said to "have position" on all other players. Because the dealer can see what all the other players do it is the most desirable position to occupy post-flop.

The blinds, the button and the cutoff seat (one off the button) are normally referred to as late position; the next two or three seats are middle position; and everything else is early position. One important thing for a beginner to realize is that the playability of a hand varies greatly according to their position. Beginners should aim to play fewer than 10% of hands in early position (when you are one of the first to act) but might find 30% playable in late position in an unraised pot.

It is useful to have a shorthand for the pre-flop positions at the table. For this guide, the big blind will be denoted by BB, the small blind by SB; other positions will be represented by a number, with 0 as the button, 1 as the seat next to the button, 2 being 2 places to the right of the button and so on.

Principles of Starting Hand Selection
The single most important thing in choosing which hands to play is to avoid being dominated.

A hand is dominated if it is a non-pair hand facing a higher hand with one card the same, or facing a pair of the same or higher value as one of its cards. For example, AQ is dominated by AK, QQ, KK and AA. QJ, which looks like a good hand to beginners, is dominated by AQ, AJ, KQ, KJ, AA, KK, QQ and JJ - that is, virtually any hand playable for a raise but AK and the medium pairs. A pair is dominated by any higher pair.

This is important not just because the dominated hand is, at best, a 3 to 1 underdog. The implied losses involved in holding AQ against AK are huge, since it can result in losing a large portion of your stack when an ace flops. The legendary player Doyle Brunson once gave up playing AQ entirely, saying that it had lost him more money than any other hand.

This leads to the Gap Concept - you need a better hand to call with than to raise with, from any given position. A player on the dealer button may raise with KJ after the action has been folded around, but should normally fold it to a raise which they judge may represent AK, AJ or KQ. More on this later.

Types of hands
Hands can be divided into a number of types. The value of the types changes depending on the number of players, the level of the blinds and the player's position on the table.

Some hands here are chosen for their ability to make a useful strong one-pair hand; others are chosen for the ability to make a straight, flush or set. The latter are known as drawing hands. A good general rule for drawing hands is: play them in later positions, perhaps the button and positions 1 and 2, and never call with them for more than 5% of the maximum possible return. The maximum return is, roughly, the minimum of your stack and the opponents stack. You might well invest more than that when raising, of course, if you have a stealing opportunity.

A few playable hands, which are not mentioned, fall somewhere in between these two - K9 suited, for example, has a value perhaps somewhere close to KJ off. (But it should be noted that KJ off is not nearly such a strong hand as most beginners would tend to think.)

Big pairs (AA KK QQ)
These cards are a favourite against any hand (except a higher big pair) and must be played aggressively preflop. The general idea is to make as big a pot as possible with as few opponents as possible - which means that you should very rarely slowplay these hands, unless you are playing opponents who know your style, in which case occasional slowplaying has some value. However, there are three general rules for these hands in small tournaments: raise, reraise and all in.

Post-flop, by contrast, pays to be careful. If the pot is small relative to your stack, you are probably only going to find all of your chips in the middle when you are beaten - after all, all you normally have is a one pair hand. The main worries are overcards, a high pair on the board, or a flop with three cards to a straight or flush, especially a high straight like Q-J-T. Knowing when to push for maximum value against someone with top pair or a smaller overpair, when to make a player pay for a draw, and when to slow down or throw your hand away is a question of experience.

High cards (AK AQ AJ KQ AT KJ QJ KT)
Post flop, the hope with these hands is to make top pair, ideally with top kicker. For example, if you play AJ and the flop comes J 8 4 of 3 different suits then you are leading against most hands, such as KJ and QJ. By raising preflop you should eliminate hands such as J8 and 44, or at least make them pay exorbitantly to hit their hand, and so you only need to worry about a player holding 88, JJ or higher. It is standard practice to bet strongly with top pair here, to make it unprofitable for an opponent with T9 to draw for a straight, and avoid someone hitting an overpair. T.J. Cloutier has said that 'Hold'em is a game of top pair, top kicker.'

Ace-King should be regarded in a different category from the other hands, since every time it hits it makes top pair, top kicker with minimal possibility of an overpair. The other hands should be played much more carefully, especially in a raised pot, and especially in a full ring game, where a dominating hand is present much more often than you might think.

Small and medium suited connectors (JT T9 98 … 43; QT J9 … 53; Q9, all suited)
Numerically adjacent cards of the same suit are less likely to make a playable hand on the flop than two big cards. However, when they do make a hand it is usually a very strong one such as a flush, straight, two pair or trips. While pot odds rarely favour these hands, no limit holdem is a game of implied odds, and making that type of hand can easily allow you to double through. Against good players they have the additional advantage of making your play less predictable.

With suited connectors the main aim is to enter a pot cheaply against a number of opponents and from a good position, usually either on or one off the button. With an open-ended straight or flush draw the player will often make a bet called a semi-bluff. If they are called then they are probably behind, but on drawing the correct card it may be possible to force a player with a hand as weak as top pair-top kicker to move all in.

Suited connectors have the most value in full ring games and with low blinds. The true connectors, with no gap between them, are more valuable because they are more likely to make a straight. However the one-gap connectors sometimes gain value from being more deceptive. The medium, offsuit connectors such as JT and T9 may also be playable in late position. The smaller offsuit connectors are trash hands from any position.

The medium connectors are excellent hands to find in late position in an unraised pot, since many players are often holding lower connectors, small pairs, and (especially in online play) high-low combinations, where the medium connectors have a distinct edge. In raised pots the small connectors may become more valuable than the medium ones, however. For example, if a player raises with AQ and another calls with AK, then a 65 suited will be quite a playable hand in a showdown, since the AQ is such a big underdog. (There are pathological cases where the 65 can actually be a favourite in a showdown over the AK here.) Better yet, a flop like A-K-6 will not lose many chips for the player with 65... while a flop like K-6-5 could be quite expensive for the player with AK. By contrast, a QT would be a very bad hand to have.

Suited rag aces (Ax suited)
The ace with a low suited kicker plays very similarly to suited connectors. While pairing the ace is useful, it can easily cause problems when outkicked by a dominating premium ace, and should be played more like middle pair than top pair. The idea, however, is to flop a flush draw. While many inexperienced players will play any two suited cards in the hope of this happening, suited aces have unique advantages here.

Most obviously, when making an ace-high flush you may have the nuts, and you will break any player with a lower flush. Also, when the flop brings a flush draw there are two scenarios; there is no ace, in which case you have a flush draw and an overcard, or there is an ace, in which case you have top pair with a flush draw. This means you have 12 cards to improve your hand above the current top pair by making a flush, pair of aces, or two pair. This gives a very good chance of winning a showdown. Unfortunately, the flush is so obvious that it will take very good play to extract maximum value from a solid, conservative player.

It is worth bearing in mind that an ace with a wheel card (2, 3, 4 or 5) is a stronger drawing hand than an A6 or A7. You may flop a straight, or a flush draw with an inside straight draw, a genuine monster draw with 15 outs over a pair of kings.

Small and medium pairs (JJ TT .. 22)
The medium pairs, JJ through 88, are often the hardest hands to play. For example, suppose a player raised in early position and you called with 99. The flop comes 8-5-3, and the opponent bets. It is clearly unlikely that they have paired the flop, since they raised; if they have a pocket pair of eights then they have a set; if they have a higher pair then you are a massive underdog. All you can beat is a bluff, and even against two overcards you are only a 3-to-1 favourite. So, the medium pairs require very careful handling after the flop unless you hit a set. At the same time they are a little too good to throw away to a single raise, and certainly good enough to raise with. In fact they may be re-raising hands against an aggressive player.

With lower pairs, 77 through 22, hitting an overpair is increasingly unlikely, and they are played more as drawing hands. The standard plan is to enter the pot as cheaply as possible and with good position, try to make a set on the flop, and release the hand upon failing to hit. The pair will make a set approximately 12% of the time, which is enough to pay off handsomely, especially since it is nearly impossible to tell whether or not someone has made a set from the cards on the board.

Trash hands (Almost everything else)
Trash hands are trash not because they cannot win - any two cards can win, especially in a game where you normally do not show down a hand - but because it is so difficult to make a hand which you can play strongly on the flop. Take K7 off suit. When pairing the king it cannot really be played as top pair because of the poor kicker. When pairing the 7 it is unlikely to be top pair, and also unlikely to remain as top pair once the turn and river have been dealt. Making two pair can be very profitable, but with only a few percent chance of flopping two pair even the implied odds cannot justify the play.

As a result, trash hands are only playable under certain circumstances. One is a common scenario at the final table of tournaments. The blinds are high, giving you little chance to select premium hands, and the table is shorthanded. This forces gambling play. By the time a tournament gets down to two players it may be normal to go all-in on being dealt a K7. They are also playable for a call or check from the blinds in an unraised pot.

It is also possible to play them simply because your position at the table makes playing any two cards advantageous. This normally occurs when you are the dealer and the players in front of you have passed. If you are an experienced player or have weak or conservative opponents in the blinds then it can be profitable to play simply for the opportunity to bluff.

Outside the blinds, it is vital to raise when playing these hands preflop, not call. By raising you give yourself the opportunity to steal the blinds as well as the best chance of finding yourself heads-up, where it is easiest to win with the worst hand. Also, limping in where you cannot call a raise is rarely a good strategy. This approach works for some of the best players in the modern game such as Daniel Negranu and Gus Hansen, but it is extremely difficult for inexperienced players, who should normally stick to more playable hands.

Pre-Flop Tactics
There is a wide range of pre-flop tactics aimed at winning the pot outright or at least narrowing the range of remaining players before the flop.

The Button Steal
While any raise preflop can be seen as an attempt to win the blinds, there is one scenario where it is especially profitable. This is the previously mentioned situation of having every player before you pass when you are on the button. If the small and big blind will both fold to a raise of twice the big blind two times out of three then the third time is effectively a freeroll, and a freeroll with good position. Late game in high level tournaments is dominated by attempts to steal the blinds in this fashion. Of course, it is possible to steal from positions other than the button, but having late position is very desirable.

The Squeeze
The squeeze is best demonstrated by example. Suppose a player raised and was called in front of you. A reraise here will place the original raiser in a difficult situation. They have no way of knowing what the original caller will do, and any chips they place in the pot may have to be surrendered to an all-in by a large pair or similar. As a result, a good player will not call without a huge hand. This move almost always either wins the pot outright, or sweetens it and moves to heads-up. Even some conservative players will make this move with marginal hands such as suited connectors and small pairs.

The Limp-Reraise
This tactic is exactly what it sounds like - you limp into the pot, an opponent raises, and you make a big reraise. This tactic is somewhat frequently used by novice players when the are dealt AA or perhaps KK from an early position. However, a thinking player could use this play in a variety of situations. For example, let's say that you are dealt JT suited from a relatively early position, you limp in, another player limps in, and an aggressive player puts in a small to medium sized raise from the button. If the blinds fold, you should occasionally raise in this spot. If you do raise, the player who limped after you will almost always fold, and since the button is aggressive and has position, he could easily have a semi-strong hand that he is now forced to fold. Even if he does call, you still have a disguised holding plus you will get first shot at the pot on the flop. Three things to understand: Only use this play on occasion; do not restrict this play to the times when you have a huge hand; try to use this play only against players who may raise with marginal holdings.

Stealing from the Blinds
This is another play that is best illustrated by example: A few players limp into the pot; you put in a big raise from the small blind or big blind; everyone folds and you scoop the pot. This play actually works more often than it sounds like it should. The best circumstances are when two or three players who like to limp with many different hands enter the pot from middle position and late position, AND when you have a hand that is completely worthless. The play is wasted when you have a hand that you would like to see a cheap flop with, which may develop into something big (like a suited connector or small pair). Note that this play also disguises your raises with very good hands. If the only time that you raise is when you have a big pair or a big A-high, you will be too easily read by your opponents.

Reasons to Bet, Check and Call
One of the main mistakes beginners make is acting without a reason. Or rather, acting with a reason that has to do with their cards rather than with gaining chips.

The main reasons to bet and raise are:

 * To gain value

This is the simplest reason. You have a hand, and you think that your opponent may have a worse hand with which they can pay you off. Value bets are the heart of poker.

 * To force a better hand to fold

Bluffing, discussed in detail later. Your chances of winning a showdown are slim, so avoid one.

 * To protect a hand

Almost any hand can be outdrawn, and it is often important to force your opponent to pay for the privilege. How important this is depends on your hand, the board and your opponent's range of hands.

 * To gain information

Betting and raising purely for information is a technical mistake - you are betting in a situation where the bet will not generate income. However, it may be correct to make a small mistake to avoid a large one later.

The main reasons to check are to:

 * Induce a bluff or misrepresent your hand

This might be slowplaying, or it might not in a normal sense; you might check a middle pair to induce a bluff.

 * Keep the pot small

If it's not clear whether you are ahead or behind, or are 1 card away from making your hand, why actively build a bigger pot? Checking a hand down might be a good option in this case because you can bow out if someone (or a few) raise. Also, having more players in the hand means that your bets vs the total pot are less costly vs the odds of improving your hand.

 * Take a free card

In position, especially against a tricky, trapsetting opponent, you might be better off seeing if the next card improves your hand when they check to you. Out of position you cannot guarantee a free card, of course.

 * Gain information

Sometimes, against certain opponents, you might gain more information by checking than by betting. Be aware of these times.

The reasons for calling might be related to a number of the above - but generally, call when neither folding or raising seems like a good option.

These may seem like simple principles, but balancing them in the many different situations of hold'em is one of the keys to post-flop play.

Evaluating the Strength of a Hand
There are several factors which affect how strong a hand is besides its face value.

The more superior hands which can be made or drawn to from the flop, the weaker the hand. Two black aces are excellent preflop, but on a flop of Q J T suited in hearts it becomes a very mediocre holding against the possible flush, straight, two-pair, set and straight flush combinations.

More players in a pot also weakens a hand. Top pair jacks, ace kicker may be excellent heads-up, but it is far less likely to stand up with 5 players, and almost dead if those players are allowed to remain for the turn and river.

A hand becomes stronger when the amount in the pot is high in relation to the maximum you can lose. All-in with top pair is normal when the pot is similar in size to your stack, but suicidal with a ratio of 20:1.

Also, in tournaments the size of the blinds in relation to your stack is an important factor. A shortstack must judge whether it is worth waiting for a better opportunity to double through with a lower stack, or worth making a move now with a weaker hand.

Evaluating the Strength of an Opponent's Hand
The first thing to do on the flop is to evaluate whether the opponent has made a hand. As a rule of thumb, remember this: against one opponent, you will be correct in assuming they missed the flop two times out of three. If the flop has a pair, it is even more likely that the flop did not help their hand. Against more than one opponent, you will be wrong two times out of three or more.

Position is the most useful tool in judging their strength. If they are forced to act before you and check, and if they have no history of check-raising or slowplaying, then it is safe to assume that they hold no hand. This is not necessarily true if the flop came A K Q -- they may be worried about your hand, or they may have flopped the nuts.

On the other hand, with a flop like 7 5 2, a bet may not mean much, especially if the opponent considers you a tight player. This type of bluff on a rag flop is so common as to hardly be considered a bluff; they may be simply protecting an ace-high.

Bluffing
The game of poker cannot be played correctly against rational opponents without bluffing. Of course, not all opponents are rational. If you find an opponent who invariably calls any reasonable bet on the flop and beyond, then only bet if you have a strong hand -- this sounds obvious, but it is something so alien to many players that world champions have been known to struggle in small stake, friendly games.

There are 3 ways in which bluffing pays off:

 * The opponent folds.
 * The opponent calls, and you then draw out to a stronger hand against them.
 * The opponent calls with a stronger hand, sees the bluff, you lose, but the opponent is more inclined to call bets in future because of it.

Against good opponents it may be that the last of these is actually the most profitable.

It is very difficult to establish how often you should bluff. Mathematically, a bet of half the pot breaks even if the opponent(s) fold one time in three, and a pot-sized bet breaks even if they fold half the time, based only on the possibility of them folding. Heads up against a conservative, inexperienced player it may well be profitable to make the first bet on the flop regardless of your hand. It certainly simplifies decision-making.

The main cost of bluffing on the flop is probably the opportunity cost of slowplaying. Checking with a very strong hand is something of a tell if you have bet the last 40 flops.

Slowplaying
Slowplaying, or trapping, is one of the most dangerous moves in Hold'em. The principle is to check after making a good hand, allowing the opponent to either bluff at the pot or improve their hand slightly on the next card.

The problem is that the opponent may find themselves drawing to a better hand than yours. Unless you are able to make some painful laydowns it is important to only trap with hands which are quite unlikely to be outdrawn, given the texture of the flop.

Immediate winners
Immediate winners (also known as "monsters") include nut hands that are impossible to beat (any four of a kind or better, any nut straight or better). With these hands, the imperative is to make as much money as possible. Betting big will scare most players out of the game with many of them guessing your hand, so slowplaying all the way to the showdown is advised. Call very often, but make middle-sized bets if nobody else is inclined to bet. Loose players will often follow you with draws and weaker made hands. You should almost never raise with immediate winners unless you're sure the opponents will call, since your goal is to maximize your winnings. These hands are virtual cheques for the pot and you should almost never fast-play them. Note: beware the nut straight, a connected card on the turn can re-position the nuts!

Non-nut winners
Non-nut winners include non-nut straight or better. These hands include:
 * full houses with xxy-shaped flop and lower-ranking card making your trips — e.g. flop: 99J, hand: J9 (nut: JJ)
 * full houses with xxx-shaped flop and KK or lower in the hole — e.g. flop: TTT, hand: QQ (nut: Tx)
 * flushes where you don't have the highest card in the suit not on the table present in your hand — e.g. flop: A72, hand: QJ (king is missing!)
 * outside straights where you don't have the next two cards higher-ranked than three on the table — e.g. flop: QJT, hand: K9 (nut: AK)
 * gapped straights where you don't have the gap card and the higher next higher-ranked card — e.g. flop: 986, hand: 75 (nut: T7)

With non-nut winners you have two strategies available: either scare the opponents outright by making large bets or delay that action until the turn. Should a player follow, be prepared to back your hand to the all-in. You should use the first strategy when there are plenty of scare cards possible on the turn and the possibility of completed bigger draws is higher. The second strategy is advisable if the turn doesn't pose a danger. In both cases you must know when to fold.

Sets
Sets are trips where you have the pair in you hand (a pocket pair). The top set is the set where your pocket pair pairs the highest card in the flop. Likewise, at the middle set the middle card is paired and at the lower set the lower card. All sets are very good hands, but seeing the turn is something you want to avoid, since you only have one nut out and many more cards will be scare cards. Nevertheless, a set can be a good hand at the showdown, but it's way more profitable to get out of trouble before the turn. Make large bets (even doubling the pot is okay) to push the opponents out of the pot. Alternatively, if the board doesn't have consecutive cards or cards of same color (unconnected), you can try slow-playing and make people with weaker but still good hands stay in. A set is a great hand, but a low set has to be protected. You should play more passively with top and middle sets, but don't let your betting become predictable.

Flopped trips
Flopped trips is trips where you have one card in the hole and two in the flop. It is similar to a set, but not as good. Trips are usually slow-played so as not to scare everyone out of the game. (Usually, if you encounter a paired flop, you should be suspicious of a full house or a four of a kind. In this case you should be looking for these hands in other players.) But if the board is connected, be aggressive.

Two pair
For the purpose of determining the flop strategy, a two pair requires that you have one card of each pair in the hand and one on the table. Two pair where you have a pocket pair and the board is paired is not a good hand and you should never count paired flops toward your two pair.

Top two pair and "rags & riches" two pair
The top two pair has both top and middle flop card paired with the hole, while the "rags & riches" two pair has the top and bottom card paired. Both are to be slow-played under ideal conditions (uncoordinated board, no hint about immediate winners available from other players). If you see a possible straight or a flush on the board, bet high and raise to scare off drawing hands. Two pair is good, but you're in fact drawing to a full house. You may stay to the showdown, but make sure in most cases you'll be beat by then.

Bottom two pair
Since the cards you play that are low enough to make the bottom two pair possible, are usually connected, you'll get dangerous flops. Make sure the drawers get out before the turn. There's also the possibility of top card being paired and thus making everyone a top pair and degrading your hand to the level of middle pair, low kicker. This advice is also valid for the "rags & riches" two pair.

Pocket pairs
Pocket pairs are pairs where both cards are in the hole.

Overpair
Overpair is a pocket pair bigger than the top card in the flop. When you have the biggest overpairs (pocket aces or kings), slow-play and pretend you bluffed. If you're against multiple opponents, try to filter them out, since the value of an overpair decreases with each new community card. If the overpair isn't that big (usually TT-QQ), bet more aggressively since your overpair isn't that good anymore. Be wary of flops with straight and/or flush draws. If someone chases you persistently at such a flop, you'll probably end up against a made hand or an even-money draw.

2nd pair
The 2nd pair is a pocket pair between the top card and the middle card. It is a usual bet/fold position. When in a late position and it's checked to you, take the free card. A strong player betting in front of you probably means he has something better than a 2nd pair. If you get raised after you've bet, fold unless you're absolutely sure it's a loose player drawing.

3rd pair
3rd pair is below the middle flop card. Check/fold or make a position bet if it's checked to you and the pair is above the bottom flop card. Do not call any bets or raises. This is a hand where you're hoping to get to the turn for free and get two pair or an unlikely trips.

Split pairs
Split pairs are pairs where you have one card in your hand and the other one in the flop. They aren't necessarily worse than pocket pairs, but the kicker is crucial.

Top pair
Top pair, top kicker (sometimes known as TPTK) is the best split pair possible. If you don't see imminent danger (such as a connected flop), slow-play. Else, bet big and try to force everyone out. The only thing is that you have to make sure you don't get carried away by a leading bettor who has obviously beaten you, but you're still holding on to the TPTK. TPTK is not a miracle hand and definitely not an immediate winner. Any overpair or even two pair is way better and you shouldn't hold on to the old pair to the showdown if you don't improve your hand in the meantime. Beware overpairs if you don't have additional outs in your hand (e.g. straight or flush draw).

Middle pair
A middle pair is a pair involving the middle flop card. If you get a middle pair, you should either bet or check/fold, depending on the playing conditions. It is a big advantage here to have an ace kicker. With an Ax hand, you can play more freely and usually take a free card when possible, since you want to get two pair, trips or a flush draw. If you get two pair, you can dominate the overcards, if you get trips, you can dominate the other player with the trips by your ace kicker, if you get a flush, your ace will guarantee you a win etc. However, if you have a worse kicker, play less aggressively and don't take much free cards. Should a tight opponent bet, fold.

Bottom pair
This is the worst split pair. Of course, the advice is to play very passively. If anyone bets, fold. In most cases you'll lose a bottom pair on the showdown, so your goal is to improve. You have only 5 outs to improve. If you decide to bluff and bet with a hand like this, do not make it a costly habit. If you're last to act and the table seems quiet, take a free card.

Draws
The opposite of made hands, draws are hands where you're aiming at a combination such as a straight or a flush, but you have only 4 cards necessary. You're aiming to get the fifth one either at turn or at river. If you have only 3 cards, you have a backdoor draw. The only feasible backdoor draw is a backdoor flush draw, getting you 1-2 outs. A backdoor straight draw is worthless. A nut draw is a draw to a nut hand.

Draws with 9 or more outs are generally good. Do not call here, make some action. 12 nut outs (ace-flush draw) are usually enough for a 50% turn & river chance, making you an even-money bet against a random opponent. The more opponents you have, the higher your calling odds are. You should remember not to "draw dead" (i.e. when you're drawing to a straight and it seems obvious someone has already got a flush). Also, beware of dead outs (your own outs that also help your opponents).

You should be more careful if you're not drawing to a nut hand. In that case, you could often by showdown find yourself against a better hand, even if you complete your draw. If you have a mid-to-late position and a rather good draw, try to make a middle-sized bet to take the pot outright.

If you have less than 9 outs, the pot odds become the imperative here. Do not call scare bets, you'll be wasting your money.

Big overcards
Big overcards are strong preflop holdings (AKs, AQs, AK, KQs, AQ, AJs) against a flop with no face cards with no made hand and no 4-card draws in sight. Be careful when playing with these against strong players as they know this is one of your most frequent hands. Sometimes try to pass it off as an overpair, but don't do it too frequently. Don't play this hand against more than two opponents.

Other hands
Anything not mentioned here is usually not even worth a bluff. Check/fold as you'll usually lose with such bad hands. Playing something like this is OK only on a late stage of a tournament.

title: Poker/Hold'em


text:
Talk:How to choose your pet and take care of it

Why was this page deleted? I was wikimoving it. - WhisperToMe from Wikipedia...

changed the so called free link. Is the one who wrote the link an advertiser? inkybutton from wikipedia...

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
User:Bddunnington~enwikibooks

I am Bryan. I have the same user name in wikipedia.

title: User:Bddunnington~enwikibooks


text:
Introduction to Programming

/Components of a computer/
The following sections will introduce various concepts in computer programming. There are some simplifications in the explanations below. Don't take anything too literally.

Programming Languages
The purpose of programming is to tell the computer what to do. Computers are better at doing some things than you are, like a chef is better at cooking than you are. It's easier to tell a chef to cook you a meal than to cook it yourself. The more precise you are in your request, the more your meal will turn out how you like it. In most scenarios like this in real life, small amounts of ambiguity and misinterpretation are acceptable. Perhaps the chef will boil your potato before mashing it instead of baking it. With computers, however, ambiguity is rarely acceptable. Programs are so complex that if the computer just guessed at the meaning of ambiguous or vague requests, it might cause problems so subtle that you'd never find them. Programming languages, therefore, have been designed to accept only completely clear and unambiguous statements. The program might still have problems, but the blame is then squarely on you, not on the computer's guess. Much of the difficulty in programming comes from having to be perfectly precise and detailed about everything instead of just giving high-level instructions.

Some languages require total and complete detail about everything. C and C++ are such languages, and are called low-level languages. Other languages will make all sorts of assumptions, and this lets the programmer specify less detail. Python and Basic are such languages, and are called high-level languages. In general, high-level languages are easier to program but give you less control. Control is sometimes important, for example if you want your program to run as quickly as possible. Most of the time total control and speed aren't necessary, and as computers get faster high-level languages become more popular. Here we will deal exclusively with high-level languages. Low-level languages are generally similar except there's often more lines of code to write to accomplish the same thing.

Statements
Most programming languages have the concept of a statement. A statement is a command that the programmer gives to the computer. For example:

print "Hi there!"

This command has a verb ("print") and other details (what to print). In this case, the command print means "show on the screen," not "print on the printer." The programmer either gives the statement directly to the computer (by typing it while running a special program), or creates a text file with the command in it. You could create a file called "hi.txt" using a program like Notepad, put the above command in it, and give the file to the computer. (The details of how to do all this are language- and system-specific, so they won't be covered here. This is just an introduction to the concepts.)

If you have more than one command in the file, each will be performed in order, top to bottom. So the file could contain:

print "Hi there!" print "Strange things are afoot..."

The computer will perform each of these commands sequentially. It's invaluable to be able to "play computer" when programming. Ask yourself, "If I were the computer, what would I do with these statements?" If you're not sure what the answer is, then you are very likely to write incorrect programs. Stop and check the manual for the programming language you're using.

In the above case, the computer will look at the first statement, determine that it's a print statement, look at what needs to be printed, and display that text on the computer screen. It'll look like this:

Hi there!

Note that the quotation marks aren't there. Their purpose in the program is to tell the computer where the text begins and ends, just like in English prose. The computer will then continue to the next statement, perform its command, and the screen will look like this:

Hi there! Strange things are afoot...

When the computer gets to the end of the text file, it stops and waits for further instructions. There are many different kinds of statements, depending on which programming language is being used. For example, there could be a beep statement that causes the computer to output a beep on its speaker, or a window statement that causes a new window to pop up.

Also, the way statements are written will vary depending on the programming language. The programming language Python uses statements that look like the above. In C you would write:

puts("Hi there!"); puts("Strange things are afoot...");

Note a few differences: These differences are fairly superficial. The set of rules like the first two is called a programming language's syntax. The set of verbs is called its library.
 * 1) The parameters (the text in quotation marks that print uses to determine what to display) are surrounded by parentheses.
 * 2) Each statement is terminated by a semicolon.
 * 3) The verb print is called puts, for "put string".  The word string is the computer term for some text.  It comes from "a string of letters."  The "put" means "put on the screen."

Syntax
All computer languages have syntax, rules to create proper statements, just like natural languages do. For example, most sentences are ended with a full stop or a period. Likewise it is common for statements in source code to be ended with a semicolon, but many languages do not have this requirement so it is important to know the syntax of the language you are programming in. For example, if you wanted the computer to display two different things you could write:

print "I have a dog. His name is Bort."

or you could write:

print "I have a dog. " + "His name is Bort."

The second example has two strings, each enclosed in quotation marks. There's a plus (+) sign in between them, which means, "Attach the two strings together, turning them into a single string." (Attaching two strings is called concatenation.) The two above statements will display the same thing:

I have a dog. His name is Bort.

In the above examples there's no reason why you'd use a <tt>+</tt> and two strings when you could just use a single string, as in the first example, but below there will be cases where concatenation of strings is necessary. The languages Python and Java use plus (<tt>+</tt>) for string concatenation, Perl and PHP use the period (<tt>.</tt>), and Visual Basic uses ampersand (<tt>&</tt>). Again, these differences are superficial; what's important is the concept of string concatenation and of language syntax to do things like concatenation. Separate in your mind an underlying concept and a particular language's way of expressing that concept.

When programs are compiled, or converted into an executable program, they are analyzed by a parser, the equivalent of a proofreader, to determine if the syntax is correct. Assuming the program's source code is syntactically correct, the compiler will continue to analyze the source code to determine if there are any semantical errors.

Semantics
Semantics refers to the meaning or logic of a computer program. Two syntactically correct statements can make perfect sense by themselves, but they may not make sense when placed next to each other. Sometimes these flaws in logic can be detected by the compiler, what is known as a compile-time error, but typically these errors surface when the program is executed, known as run-time errors.

Observe the following conversation: Alice: Terrible news. Carl's wife was in a car accident. Bob: Oh, that is terrible. Send some nice flowers and get everyone to sign a card. Alice: Sure. Oh, and Dan called in sick again. Bob: Not again. Send him a pink slip. The conversation makes perfect, logical sense. This conversation shows a good, consistent use of semantics.

Now observe this conversation: Alice: Terrible news. Carl's wife was in a car accident. Bob: Not again. Send him a pink slip. Alice: Sure. Oh, and Dan called in sick again. Bob: Oh, that is terrible. Send some nice flowers and get everyone to sign a card. Although this conversation contains the exact same sentences as the previous one, it has a very different meaning. A human may be able to bend the rules of grammar and structure to determine the intended meaning of a conversation, but computers are not as flexible. Therefore, it is important to use proper syntax and use good semantics in order to properly convey to the computer what you want it to do. Understand though, that the first conversation could have been rearranged and still have the same meaning or different sentences could have been used to convey the same idea. In that sense there can be many different ways to write the same program.

Variables
Say you had a program that talked about your dog. It might look like this:

print "I have a dog. It is called Bort." print "Bort likes to eat dog food." print "My children and Bort get along very well." print "My dog Bort barks at my neighbor, whose name is also Bort."

You might go on like this for a while, asking the computer to display many such interesting things about your dog. If, one day, you changed your dog's name, or instead wanted to talk about your other dog, or gave this program to a friend and they wanted to change it to refer to their own dog, you'd have to go through the whole program and change every occurrence of "Bort" to the new name. You could use your text editor's search-and-replace feature to do this, but doing so is tedious and you might make mistakes. For example, you might accidentally replace the neighbor's name when you only intended to change the dog's name.

Programming languages solve this problem by allowing you to write the dog's name only once and then refer to it using a label. This is a bit like using pronouns in natural languages. So you could write:

dog = "Bort"

If you're "playing computer" and get to the above statement, you'll think, "Remember the string "Bort", and whenever the word dog is used, substitute the word "Bort"." This is called an assignment statement because you're assigning meaning to the word dog. A subsequent statement could say:

print dog

Note that there are no quotation marks here. You don't literally want to print the word "dog", you want the computer to remember the string it had previously associated with that word. It's a bit like the distinction between saying "He said his age" and "He said, 'his age'." In the first case it's a number and in the second it's the words "his age". The word dog is a variable. It's a symbol that the computer associates with something else, in this case the word "Bort". Our original program can now be written as:

print "I have a dog. It is called " + dog + "." print dog + " likes to eat dog food." print "My children and " + dog + " get along very well." print "My dog " + dog + " barks at my neighbor, whose name is Bort."

Note that string concatenation (using the plus sign) was necessary here, since sometimes we wanted to use quotation marks (to mean literal text) and sometimes we didn't (to refer to the variable). The computer will see a statement like:

print dog + " likes to eat dog food."

and first substitute the word dog with the string "Bort":

print "Bort" + " likes to eat dog food."

then concatenate the strings:

print "Bort likes to eat dog food."

then perform the statement, displaying this on the screen:

Bort likes to eat dog food.

Note also that the name of the neighbor was not replaced by a reference to dog. The variable dog refers to the name of the dog. That's the whole point of using the variable: to keep track of a specific concept. You could have a different variable to keep track of the neighbor's name:

neighbor = "Bort"

and change the last line of our program to:

print "My dog " + dog + " barks at my neighbor, whose name is " + neighbor + "."

That way you can change the name of your dog or your neighbor easily at the top of the file and the rest of the program will run correctly. I removed the word "also" from the line since, now that we're using variables, I can no longer be sure that the two names are the same. I wouldn't want to change one of the two and have my program still display the word "also" there. Later we'll see a way of displaying the word "also" only if the two names are the same.

It's important to remember two things about variables. Firstly, a variable must be set before it is used. So you must write:

dog = "Bort" print dog

and not:

print dog                            (Wrong!) dog = "Bort"

Remember when "playing computer" that you must look at each statement individually and in order from top to bottom. In the second example above you would first get to the "print dog" statement and have no idea what the variable dog was referring to. Different languages react differently when they run into this problem. Some just assume the variable is an empty string (""), but most stop the program and report the error.

Secondly, when you're "playing computer" and see the second line of the correct program:

dog = "Bort" print dog

it's very important that you don't "go back up" to the first line to see what dog refers to. The first line is long gone. You can only look at one line at a time, and always sequentially. The first line makes a note somewhere (in memory) that dog refers to "Bort", but then the line itself is left behind and forgotten. The second line checks memory and gets the variable's meaning there, not from the first line directly. This may seem like a trivial distinction, but we'll use variables in more sophisticated ways later and it won't work to "go back up" to find where a variable was set; you'll need to think of the variable and its value as being stored in memory.

The word variable implies that variables can change, and indeed they can. You could write the following program:

dog = "Bort" print "My first dog was called " + dog + "." dog = "Milou" print "And my second dog was called " + dog + "."

The computer will see the first line, associate the string "Bort" with the variable dog, use that string in the second line, change the association of the variable dog to "Milou" in the third line, and use the new association in the fourth. In memory the variable dog can only be associated with one string. The third line above replaces the old association with the new. The second and fourth lines look into memory to see what that association is, and at each statement the value is different because the value in memory is different at that point in the program's execution. You'll see:

My first dog was called Bort. And my second dog was called Milou.

Math
When the computer sees a mathematical expression, it performs the arithmetic automatically. For example, you can write:

print 5 + 6

Note again that there are no quotation marks. If there were, the computer would take that literally and print "5 + 6". The plus sign is called an operator because it performs operations on other values. When the computer sees the above line, it will perform the arithmetic and get:

print 11

Executing the statement will just print the number:

11

Note that the following two statements will display the same thing:

print 11 print "11"

except that in the first case the computer knows it's a number, whereas in the second case it's just a string. Sometimes that distinction matters, but we can ignore it for now. The math can get pretty complicated:

print (5 + 12) * 9 / 14

The computer would perform the arithmetic step by step, just like you would in your head. It would first do the addition, since it's in parentheses:

print 17 * 9 / 14

Then the multiplication, since it's on the left:

print 153 / 14

Then the division:

print 10

And you'd see this if you ran the original line:

10

Note that 153 divided by 14 is actually something like 10.928, but the computer printed the round number below the real value. That's because there are two kinds of numbers most languages deal with: integers and reals. Integers are round numbers, like the ones above. Reals are numbers with a decimal point, like 10.928. When the computer sees an expression using entirely integers, it keeps using integers to do the math, even if the result really should be a real. Had we written:

print (5.0 + 12.0) * 9.0 / 14.0

then the computer would have performed the math using reals and we would have seen something like this printed:

10.9285714286

This is a quirky result of the historical development of computers. It can lead to bizarre results, like this line:

print 1 / 2

displaying "0" instead of the expected "0.5". There are times when the current behavior is desirable, but often it's not and you should keep the distinction between integers and reals in mind. Also note that the above rules about integers and reals apply to most commonly-used programming languages, but each language is free to make up its own rules for dealing with numbers, and you may one day use a language that does things differently, such as making "1 / 2" result in "0.5".

Variables can be used to refer to numbers as well as strings. You could write:

x = 5 print x

to print "5". Or you could write:

age = 33 print age * 2

to find out twice your age. Again here the first line creates in memory an association between the variable whose name is age with the number 33. The second line looks into memory, grabs the number associated with age, and performs the arithmetic. Note that the first line is not algebra. It's not an equation that makes age and the number 33 the same. It's an assignment of the value 33 to the variable age. The distinction is important when you see a line like:

x = x + 5

The above line is impossible in algebra. The value of x cannot be equal to the value of x plus five. But in a programming language, the line reads as, "Find the value of the variable x in memory, add 5 to it, then associate the result with the variable x." The fact that x is used both in the math expression on the right of the equal sign and as the place to store the results is irrelevant. Its value is used in the math expression before the result is stored back into the variable. Here's another example:

x = 5 y = x + 2 print x   print y

You'll get:

5   7

But now if you write:

x = 5 y = x + 2 x = 10 print x   print y

You'll get:

10   7

Go through each line and "play computer" to convince yourself of why the above would behave this way. Use a piece of paper to keep track of the x and y variables if you need to. If the above isn't clear, stop and re-read this section or the one on variables. This is a very common stumbling block for new programmers.

You might have noticed that we use the plus (<tt>+</tt>) symbol to mean both "string concatenation" and "numerical addition". This is fine and usually clear, but what should the computer do with a statement like this:

print "5" + 6

Should the numbers 5 and 6 be added to yield 11? Should the string "5" be concatenated with the string "6" to yield "56"? Should the computer stop and report an error? Each language deals with this ambiguity in different ways. In Python, the above line would be an error. You'd have to explicitly tell the computer which interpretation you wanted. In Java the "6" would be turned into a string, resulting in the string "56". In Perl, PHP, and Visual Basic the string concatenation operator is not plus, it's period for Perl and PHP and ampersand in Visual Basic, so it's always clear what needs to be done based on which operator is used.

Conditionals
Say we had a simple program that displayed your age:

age = 25 print "You are " + age + " years old."

If you ran this program it would display:

You are 25 years old.

Next year you could change the first line to "age = 26" and the program's output would update appropriately. In fact you could give this program to anyone and they could modify the first line so that the second line would print the right age. Once you turned 30 you might want to modify it like this:

age = 30 print "You are " + age + " years old." print "Your warranty has expired!"

That would work fine, except that if you now gave it to someone who was 25 they would not only have to modify the first line but remember to remove the third line. But why force a human to remove the third line? The computer should be able to automatically display or not display the third line depending on the value of age. We can use an "if" statement to tell the computer to do just that:

age = 30 print "You are " + age + " years old." if age > 29: print "Your warranty has expired!"

Again let's "play computer": when you get to the third line, you look at the word age, realize it's a variable, and get its value (30) from memory (it was stored there on line 1):

if 30 > 29:

This line says, "If 30 is greater than 29, perform the statements that are indented. If not, skip the indented statements." Since 30 is greater than 29, the indented statements are performed and the joke is displayed on the screen. If a friend changes the first line to "age = 25", the third line will compare 25 to 29, and since 25 is not greater than 29, the fourth line will be skipped.

This is a conditional. Whether the fourth line is run is conditional on the math expression on the third line. That expression could be more complex, such as:

if age >= 40 and age < 50: print "You are in your forties."

The <tt>>=</tt> symbol means "greater than or equal to". Here the "print" line won't get run unless the age is between 40 and 49. You can also put more than one indented statement:

if age >= 50 and age < 60: print "You are in your fifties." print "Mid-life crisis yet?"

If the person's age is between 50 and 59, both lines will be displayed; otherwise neither will. Now notice that if the age of the user is 1, the second line of our original program will display a grammatical error:

You are 1 years old.

That should be "year", not "years". We can use a conditional to fix this bug:

age = 25 if age == 1: print "You are " + age + " year old." if age != 1: print "You are " + age + " years old."

The <tt>==</tt> means "is equal to". There are two equal signs in order to differentiate it from an assignment statement, which uses a single equal sign (as in the first line of our program). This is related to what we wrote above about computer languages always wanting to be perfectly clear about what's intended. The <tt>!=</tt> means "not equal to". Think of the math symbol of the equal sign with a slash through it, then imagine the exclamation mark being that slash. Now if you set age to 1 you'll get this:

You are 1 year old.

Which is correct. If the age is not 1, then the first "print" will be skipped and the second will run, displaying the version of the text with a plural "years". It's fairly common to want to do one thing if a condition is true (such as "age == 1") and another if that condition is not true ("age != 1"). So computer languages have a shortcut to save you from having to retype a whole "if" statement with the inverse condition. You simply write this:

age = 25 if age == 1: print "You are " + age + " year old." else: print "You are " + age + " years old."

That means, "If age is 1, run the first print statement. If not (else), run the second print statement." Again you can have multiple statements in either the first section or the second:

age = 25 if age == 1: print "You are " + age + " year old." print "You're an infant!" else: print "You are " + age + " years old." print "You're not an infant."

Now you can give this program to someone else and they only need to change the first line to get a few lines of accurate text displayed about them. You can imagine that this can get arbitrarily complex, with very sophisticated conditions being tested. Consider this:

age = 25 if age == 1: print "You are " + age + " year old." print "You're an infant!" else: print "You are " + age + " years old." if age < 25: print "You're young." else: print "You're mature!"

This is called a "nested if". The second "if" (the one that compares age with 25) is nested (within) the first "if". Since it's indented, the second "if" will itself only be run if the first condition ("age == 1") is not true. If age is in fact 1, the first "print" will be run and the entire second section, including the second "if", will be skipped. So the program will display only one of "You're an infant!" or "You're young." or "You're mature!". You should "play computer" through this program with various values of age, such as 1, 5, 25, and 30.

Conditionals are extremely useful. In our example, it would have been possible (though inconvenient) for each person to add or remove "print" statements as they modified the age in the first line, but in reality the value for age would have come from elsewhere, such as a form or a database, and the program would have to run as-is, unmodified, and display the correct text for any value of age that it might get.

We can look at conditionals in C, again to show that basic concepts are available in different programming languages with only superficial differences:

if (age > 29) puts("Your warranty has expired!");

Note these differences: there are parenthese around the condition; "print" was replaced with "puts", as before; the text to display is surrounded by parentheses; and there's a terminating semicolon at the end of the "puts" statement. If you wanted to display more than one line, you'd have to write it like this:

if (age >= 50 && age < 60) { puts("You are in your fifties."); puts("Mid-life crisis yet?"); }

Note these two additional differences: the "and" has been replaced with "&&" in the condition; and there are braces around the pair of "puts" statements. In C (and languages derived from C, such as C++, Java, and C#), indentation is ignored, so the "if" statement will assume that only the very next statement will be conditionally run. If you want more than one statement, you have to group them with braces to tell the language that all of these are conditionally run. In our Python-like language above, indentation is used to tell which statements are under the control of the "if" and "else" lines.

Input
In the above examples, the age was placed right in the source code, on line 1:

age = 25

This is called hard-coding the age. The hard comes from the fact that once the program is written that way, the age is always 25. If the user wants to run the program with a different age, they need to change the source code. But that assumes that they understand programming. Since most users don't understand programming, we'd really like to simply ask the user their age so that they never need to see the source code at all.

We can use a line like this:

age = input

To input something means to put it into the computer. Output is the reverse, like the print statements we've been using.

So our program now looks something like:

print "What is your age?" age = input if age == 1: print "You are " + age + " year old." else: print "You are " + age + " years old."

When the user runs the program, instead of immediately seeing the "You are ..." text, they'll first see this:

What is your age?

and the system will appear to stop. The user will then be able to enter their age, press Enter, and the program will continue as it did before, with the variable age set to whatever number the user entered.

You may be curious about the set of parentheses after the word input. If you didn't have those, like this:

age = input

the word input would look a lot like a variable. Since computers always want to be completely clear about what needs to be done, we add parentheses to mean, "This isn't a variable, it's a command. Do something clever." <tt>input</tt> is actually a function. We'll cover functions later, but for now you can think of them as bits of code that do interesting things (like getting a number from the keyboard) and making some value available as a result (for assignment to age in this case). When the computer sees this line:

age = input

It first sees the function <tt>input</tt>, does the clever thing (gets a number from the keyboard), and replaces the function with the value that it got:

age = 25

(if the user typed 25). Then the assignment continues as it did before, storing the value 25 into memory and associating it with the word age.

Loops
Say we wanted to write a program that asked the user how many times they wanted a phrase repeated. (Yes, it really is necessary to have these silly examples. More realistic examples are often too complex to demonstate a single new concept.)

print "How many times?" count = input if count == 1: print "Are we there yet?" if count == 2: print "Are we there yet?" print "Are we there yet?" if count == 3: print "Are we there yet?" print "Are we there yet?" print "Are we there yet?" if count == 4: print "Are we there yet?" print "Are we there yet?" print "Are we there yet?" print "Are we there yet?"

If you run this program, the user will be asked "How many times?" and the computer will wait for an answer. The user can then type a number between 1 and 4 and the phrase "Are we there yet?" will be displayed that many times. There are several problems with this program. Firstly, it can at most handle a count of 4. If the user wants it displayed 5 times, the program must be extended to handle that case. Secondly, as the number of cases grows, it will be difficult to make sure that the program is correct. If you extend it all the way to, say, 20 times, it's difficult to check using your text editor that the case for 17 really has 17 lines in it. Perhaps you made an error and only cut-and-pasted the line 16 times. We could be clever and rewrite it like this:

print "How many times?" count = input if count >= 1: print "Are we there yet?" if count >= 2: print "Are we there yet?" if count >= 3: print "Are we there yet?" if count >= 4: print "Are we there yet?"

This is somewhat tricky, so it's important to follow the logic carefully, as the computer would. Let's say count is 3. The first "if" statement will check if 3 is greater than or equal to 1, and since it is, print the first phrase. The next "if" will compare count to 2, and print the second phrase. The same thing will happen when <tt>count >= 3</tt> is tested, since 3 is greater than or equal to 3. But the fourth test will not work, since 3 is not greater than or equal to 4. So the fourth phrase will not be displayed. The phrase will have been displayed 3 times (once for each of the first three "if" statements), which is what we wanted since count is 3.

This new way of writing the program is simpler to verify for correctness. We just need to make sure that each number in successive "if" statements is one more than the previous number. Since each "if" statement only prints a single line, we don't risk mis-counting the number of "print" lines as in the first example. But it's still somewhat tedious to extend the program to handle higher values of count. You have to cut-and-paste two lines and remember to increase the number in the "if" statement.

We could make that a little easier with this new version:

print "How many times?" count = input if count >= 1: print "Are we there yet?" count = count - 1 if count >= 1: print "Are we there yet?" count = count - 1 if count >= 1: print "Are we there yet?" count = count - 1 if count >= 1: print "Are we there yet?" count = count - 1

Now the program is more complicated, but each "if" statement is identical. That makes cutting and pasting much easier—we can simply hold down the Ctrl-V key and have a program that handles very large values of count. Here's how the new program works. The first "if" statement, as before, compares count to 1 and prints the phrase if count is greater than or equal to 1. But it also does something else: it decreases the value of count by one. This statement:

count = count - 1

does three things: it finds the value of count in memory, subtracts 1 from it, and puts the result back into memory, replacing the old value of count. So if count is 3, the count on the right side is replaced with its value:

count = 3 - 1

then the arithmetic is done:

count = 2

and the new value is stored into memory as before, replacing the 3 that was there. You may wonder why only the count on the right side of the equal sign gets replaced with its value, and not the left. Why doesn't the computer replace both words with the value 3, like this:

3 = 3 - 1

Obviously this wouldn't be very useful. The assignment statement only looks up the existing value of variables when they appear on the right of the equal (assignment) sign. The single variable on the left of the equal sign is used as-is to know what name to associate with the result of the arithmetic on the right.

So after the first phrase is displayed, count is decreased by one, and the next "if" is tested. It's the same test, comparing count with 1. Say that count is 3 initially. At the first "if" we'll see the phrase displayed and count will become 2. At the second "if" we'll see the phrase and count will become 1. At the third "if" we'll see the phrase and count will become 0. At the fourth "if" the test "0 >= 1" will not be true, so the phrase won't get displayed and count won't be decreased. No matter how many more "if" statements you have after that, the value of count will stay 0 and none of the <tt>print</tt> statements will run. You'll see the phrase three times, which is what we wanted since count was 3 originally.

Our program now has one final problem: no matter how many times we cut-and-paste these three lines, the user could always enter a number that's higher than that. You could have pasted the "if" statement 500 times, and if the user enters "510", your program will only display the phrase 500 times, once for each "if". The program will end with the variable "count" set to 10, since there are 10 more phrases to go, but the last 10 "if" statements won't be there.

We can fix this last problem with a loop, like this:

print "How many times?" count = input while count >= 1: print "Are we there yet?" count = count - 1

That's the entire program. Specifically, this is a while loop, because there are several different kinds. We removed all the "if" statements except one, and replaced the word if with the word while. It almost reads like an English sentence: "While count is greater than or equal to 1, print this phrase and decrease count by one." Let's "play computer" with count initially set to 3. The computer will get to the "while" statement, compare 3 to 1, see that 3 is greater than or equal to 1, display the phrase, decrease count by 1 (to 2), and loop back up to the while statement. Again the computer will compare count to 1, and since 2 is greater than or equal to 1, it will print the statement, decrease count to 1, loop back up, compare count with 1, and since 1 is greater than or equal to 1, display the phrase and decrease the variable count to zero. It will then loop back up to the "while" statement, compare count to 1, and since 0 is not greater than or equal to 1, the indented statement will not be run and the "while" loop will finish, moving on to the statements that follow. In this program there are no statements that follow, so the program will end. Each time through the loop is called an iteration.

There are several different types of loops. Which one to use depends both on what's available in the programming language you're using and which makes the most sense for what you're trying to do. For example, in the example above, we could print the value of count in each iteration, like this:

print "How many times?" count = input while count >= 1: print "Are we there yet?" print count count = count - 1

Running the program would look something like this (if the user typed "3" when asked):

How many times? 3                    (what the user types in) Are we there yet? 3   Are we there yet? 2   Are we there yet? 1

The numbers 3, 2, 1 are the values of count at each iteration. What if, instead, just wanted to count upwards? Or what if you didn't want to modify count, because you wanted to use it later on in the program? You could use a for loop, like this:

print "How many times?" count = input for i = 1 to count: print "Are we there yet?" print count

(Note: So far the language we've used for examples has been similar to the popular programming language Python. But Python has no such for loop.  The above syntax is based on the language Basic.)

This for loop means, "Run the indented statements once for each value between 1 and count, and set the variable i to that value." If the user enters 3 you'll see this:

How many times? 3                    (what the user types in) Are we there yet? 1   Are we there yet? 2   Are we there yet? 3

The 1, 2, 3 are the values of i at each iteration. Note that we no longer need to decrease the value of count in each iteration. The computer automatically increases i by 1 each iteration until it reaches count. In fact, count is unchanged after the loop finishes. This loop:

for i = 1 to count: print i

is essentially identical to this version:

i = 1 while i <= count: print count i = i + 1

The for loop is generally preferable to while loops when you want to cover a range of numbers. It's shorter and easier to read. The while loop, though, is more flexible since you're doing all the work yourself. You could increment i by 2 at each iteration to see only the odd numbers, or you could double the value of i to see all the powers of two:

print "What is the maximum?" maximum = input i = 1 while i <= maximum: print i       i = i * 2

What is the maximum? 128                    (what the user types in) 1   2    4    8    16    32    64    128

You can't do that with a simple for loop. Incidentally, in a for loop the starting and ending values (1 and count in our example) can actually be any pair of numbers. You could do:

for i = 20 to 24: print i

to display the values 20, 21, 22, 23, and 24. The variable i is used here, but any variable could be used. i is a commonly-used variable for for loops; it stands for index. You could also use a variable name that makes more sense in your particular context, such as:

for year = 1992 to 2004: print "The year is " + year

Another type of loop is the foreach loop. That's similar to the for loop except that the variable doesn't just go through a numerical range, it's actually set to each element in a set of numbers:

foreach year in [1992, 1996, 2000, 2004]: print "The " + year + " Olympic Games."

That also reads almost like an English sentence: "For each year in the set 1992, 1996, 2000, 2004, print this statement." (Note: Python does have such a for loop, except the word for is used instead of foreach.)

There are a few other types of loops, but they're usually variations on the above three types.

title: Introduction to Programming


text:
Set Theory/Cardinals

Infinite Sets and Cardinality
The Size of a Finite Set

When deciding how large finite sets are, we generally count the number of elements in the set, and say two sets are the same size if they have the same number of elements. This approach doesn't work too well if the sets are infinite, however, because we can't count the number of elements in an infinite set.

However, there is another way to define when two sets have the same size that works equally well for finite and infinite sets. We say that two sets $$A$$ and $$B$$ have the same size if we can define a function $$f: A\to B$$ which satisfies the following properties:

 * $$f(a)$$ is defined for every $$a\in A$$.
 * $$\forall b\in B$$, $$\exists a\in A$$ such that $$ f(a)=b$$. We say that f is onto or surjective.
 * $$\forall a_1, a_2\in A$$, $$f(a_1)=f(a_2) \implies a_1=a_2$$. We say that f is one-to-one or injective.

Functions which satisfy these properties are called bijections.

Examples

The sets $$\{1,2,3\}$$ and $$\{4,5,6\}$$ both have three elements. We can define a bijection between them like this: $$f(1)=6, f(2)=4, f(3)=5$$.

The set of all positive integers, $$\{1,2,3,...\}$$ is the same size as the set of nonnegative integers, $$\{0,1,2,...\}$$. Let $$f(1)=0, f(2)=1$$, and more generally $$f(n)=n-1$$.

Exercise

Prove that the above function is a bijection.

Often it is difficult to construct an explicit bijection between two sets of the same cardinality, so the following theorem can come in handy:

Cantor-Schroeder-Bernstein Theorem

See proof at Cantor–Bernstein–Schroeder theorem

If $$A$$ and $$B$$ are two sets and there exist injective functions $$f:A\to B$$ and $$g:B\to A$$, then there exists a bijection between $$A$$ and $$B$$.

Definition
There are many ways of defining cardinality, and one method is to use ordinals as a reference. The cardinality of a set can be defined to be the smallest ordinal in one-to-one correspondence with the set. However, when speaking of cardinality, it is common to compare with the set of real numbers etc. when speaking of cardinalities greater than the countable cardinal, so in practice cardinality is thought of as something simply compared between two sets. One reason for this is because the possible sizes of ordinals can generally depend on the axioms one is working with.

title: Set Theory/Cardinals


text:
Robotics/Types of Robots

In general, robots are classified based on their capabilities. Some standard classifications of robots include their domain of operation, degree of autonomy, and the goal they are designed to fulfill.

Domain of Operation
Robots can be designed and built for any environment imaginable. One popular way of classifying robots is by what environments they're designed to operate in. Some typical examples include:
 * Stationary
 * These robots are fixed in one place and cannot move. This category includes robotic arms, computerized machine tools, and most other Industrial Robots.
 * Industrial Robots are robots used in mass production e.g. welding robots, CNC plate cutters or CNC drills. The large majority of these robots are stationary and tethered to a computer.

 * Ground
 * These robots are designed to operate on the surface of the earth or other planet, and are usually sub categorized by their drive train:

 * Wheels
 * Tracks
 * Legs
 * Underwater
 * Also known as Autonomous Underwater Vehicles, these are designed to operate underwater, possibly at great depth.

 * Aerial
 * Unmanned Aerial Vehicles are various kinds of robotic flying machines, including planes and helicopters.

 * Microgravity
 * Robots that have been designed to operate in low-gravity environments, such as earth orbit.

 * other specific Hazardous Environments

Degree of Autonomy
Autonomy is the quality of being self-controlled. One measure of autonomy is the amount of human control that is required for the robot's operation. An autonomous robot can operate properly without intervention indefinitely and can deal with unexpected problems gracefully. Teleoperated robots constantly require humans to send the robot control signals. These are only the endpoints; there is a continuum of possibilities between them.

A robot can also be classified by how self-contained it is. Power, logic circuitry, and other things may be located either on the main chassis or connected via a cable tether or wireless link from another location.

Goal
Robots are also routinely categorized by the goals they are designed to achieve. These include contests, personal enrichment, manufacturing, and entertainment.

title: Robotics/Types of Robots


text:
Robotics/Types of Robots/Contest Robot

Here are a few examples of contests with robots: (Here's a list of different contests)

Fire fighter
In a fire fighter contest the robot has to find the flame of a candle and extinguish it.

See this site for an example.

Maze
Find the way through the maze as fast as possible.

For example: see this site.

For a video examples:
 * video 1
 * video 2
 * video 3 (multiple contestants--both successful and not)

Obstacle Course
There are many different obstacle course to build for a robot contest. The Melexis Safety Trophy has tin cans with small candles inside and concrete bricks as obstacles and tennis balls (which the robot had to touch) for extra points. Another contest uses traffic signs with arrows to direct the way.

See this site for an example.

Soccer robot
Robots playing soccer. The goal of this type of contest is to build a team of robots that can work together.

See this site for an example.

Sumo Robot
In this type of contest 2 robots are placed on a playground within a large circle. The goal is to push the other robot out of this circle.

See here for an example.

title: Robotics/Types of Robots/Contest Robot


text:
Robotics/Types of Robots/Entertainment Robot

These are robots that have no real useful application. They're build for fun and practice but little else more. Most homebuilt robots would fall in this category.

They can be simple robots that use simple sensors (light sensor, sound, bumper switches) and have simple behavior, but they could as well have complex sensors and extensive programming.

One other category of robots that's very close related to this category are robot build as "tech-demos". For example the Asimo robot.


text:
Robotics/Design Basics/Electronic Components

Basic Electronics
For basic electronics you may want to consult this wikibook and this section on Microcontrollers.

google has some links on PCB fabrication.

Special Electronic Components
There are many electronic components that aren't described in most electronic textbooks, but are very useful in robotics. Most of these components are covered in other section in this book (e.g Sensors and Motors).

A typical robot needs a heat sink on the power transistors connected to its motors and other actuators, but often does not need a heatsink connected to its CPU.


text:
Ada Programming/Types/record

A record is a composite type that groups one or more fields. A field can be of any type, even a record.

Basic record
Basic_Record A : Integer; ;

Null record
The null record is when a type without data is needed. There are two ways to declare a null record:

Null_Record ;    ;

Null_Record  ;

For the compiler they are the same. However, programmers often use the first variant if the type is not finished yet to show that they are planning to expand the type later, or they usually use the second if the (tagged) record is a base class in object oriented programming.

Record Values
Values of a record type can be specified using a record aggregate, giving a list of named components thus

A_Basic_Record       Basic_Record          Basic_RecordA  42 Another_Basic_Record Basic_Record          A  42 Nix                   Null_Record

Given a somewhat larger record type,

Car Identity       Long_Long_Integer Number_Wheels  Positive  1  10 Paint          Color Horse_Power_kW Float  00  2_0000 Consumption    Float  00  1000

a value may be specified using positional notation, that is, specifying a value for each record component in declaration order

BMW Car  2007_752_83992434 5 Blue 1900 101

However, naming the components of a Car aggregate offers a number of advantages.
 * 1) Easy identification of which value is used for which component. (After all, named components are the raison d'être of records.)
 * 2) Reordering the components is allowed—you only have to remember the component names, not their position.
 * 3) Improved compiler diagnostic messages.

Reordering components is possible because component names will inform the compiler (and the human reader!) of the intended value associations. Improved compiler messages are also in consequence of this additional information passed to the compiler. While an omitted component will always be reported due to Ada's coverage rules, messages can be much more specific when there are named associations. Considering the Car type from above, suppose a programmer by mistake specifies only one of the two floating point values for BMW in positional notation. The compiler, in search of another component value, will then not be able to decide whether the specified value is intended for Horse_Power_kW or for Consumption. If the programmer instead uses named association, say Horse_Power_kW 1900 it will be clear which other component is missing.

BMW Car Identity       2007_752_83992434 Number_Wheels  5 Horse_Power_kW 1900 Consumption    101 Paint          Blue

In order to access a component of a record instance, use the dot delimiter, as in BMWNumber_Wheels.

Discriminated record
Discriminated_Record (Size : Natural) A : String (1 .. Size); ; ...  Item : Discriminated_Record := (Size => Value'Length, A => Value);

Variant record
The variant record is a special type of discriminated record where the presence of some components depend on the value of the discriminant.

Traffic_Light (Red, Yellow, Green); Variant_Record (Option : Traffic_Light) Option Red => Yellow => Green => ;     ;

Mutable and immutable variant records
You can declare variant record types such that its discriminant, and thus its variant structure, can be changed during the lifetime of the variable. Such a record is said to be mutable. When "mutating" a record, you must assign all components of the variant structure which you are mutating at once, replacing the record with a complete variant structure. Although a variant record declaration may allow objects of its type to be mutable, there are certain restrictions on whether the objects will be mutable. Reasons restricting an object from being mutable include:

 * the object is declared with a discriminant (see Immutable_Traffic_Light below)
 * the object is aliased (either by use of in the object declaration, or by allocation on the heap using )

Traffic_Light (Red, Yellow, Green); Mutable_Variant_Record (Option : Traffic_Light := Red) Location : Natural; Option Red => Flashing : Boolean := True; Yellow => Timeout   : Duration := 0.0; Green => Whatever : Positive := 1; ;     ; ... Mutable_Traffic_Light   : Mutable_Variant_Record; Immutable_Traffic_Light : Mutable_Variant_Record (Option => Yellow); ... Mutable_Traffic_Light  := (Option => Yellow,                                                     Location => 54,                                                       Timeout => 2.3); ... Traffic_Light_Access   Mutable_Variant_Record; Any_Traffic_Light      : Traffic_Light_Access := Mutable_Variant_Record; Aliased_Traffic_Light  :  Mutable_Variant_Record;

Conversely, you can declare record types so that the discriminant along with the structure of the variant record may not be changed. To make a record type declaration immutable, the discriminant must not have a default value.

Traffic_Light (Red, Yellow, Green); Immutable_Variant_Record (Option : Traffic_Light) Location : Natural := 0; Option Red => Flashing : Boolean := True; Yellow => Timeout   : Duration; Green => Whatever : Positive := 1; ;     ; ... Default_Traffic_Light   : Immutable_Variant_Record; Immutable_Traffic_Light : Immutable_Variant_Record (Option => Yellow);

Union
Traffic_Light (Red, Yellow, Green); Union (Option : Traffic_Light := Traffic_Light'First) Option Red => Yellow => Green => ;     ;   (Union); (C, Union);

The difference to a variant record is such that Option is not actually stored inside the record and never checked for correctness - it's just a dummy.

This kind of record is usually used for interfacing with C but can be used for other purposes as well (then without ).

Tagged record
The tagged record is one part of what in other languages is called a class. It is the basic foundation of object orientated programming in Ada. The other two parts a class in Ada needs is a package and primitive operations.

Person Name  : String (1 .. 10); Gender : Gender_Type; ;

Programmer  Person Skilled_In : Language_List; ;

Ada 2005 only:

Programmer  Person Printable Skilled_In : Language_List; ;

Abstract tagged record
An abstract type has at least one abstract primitive operation, i.e. one of its operations is not defined and implementation must be provided by derivatives of the abstract type.

With aliased elements
If you come from C/C++, you are probably used to the fact that every element of a record - which is not part of a bitset - has an address. In Ada, this is not true because records, just like arrays, can be packed. And just like arrays you can use to ensure that an element can be accessed via an access type.

Basic_Record A : Integer; ;

Please note: each element needs its own.

Limited Records
In addition to being variant, tagged, and abstract, records may also be limited (no assignment, and no predefined equality operation for Limited Types). In object oriented programming, when tagged objects are handled by references instead of copying them, this blends well with making objects limited.

Wikibook

 * Ada Programming
 * Ada Programming/Types
 * Ada Programming/Keywords/record
 * Ada Programming/Keywords/null
 * Ada Programming/Keywords/abstract
 * Ada Programming/Keywords/case
 * Ada Programming/Keywords/when
 * Ada Programming/Pragmas/Unchecked Union

Ada Issues

|Record Programación en Ada/Tipos/Registros

title: Ada Programming/Types/record


text:
Ada Programming/Platform/Windows/GNAVI

GWindows is a community supported Ada binding to Windows. It is part of the GNAVI project, a Delphi like environment for Ada. http://www.gnavi.org/gwindows

GNATCOM is a community supported Ada binding to COM+/COM/DCOM/ActiveX. It is part of the GNAVI project, a Delphi like environment for Ada. http://www.gnavi.org/gnatcom

GNAVI is a community supported RAD (Rapid application development) visual development environment that uses GWindows and GNATCOM.

Library links

 * Authors : David Botton and others

Wikibook

 * Ada Programming
 * Ada Programming/Libraries

|Win32binding

title: Ada Programming/Platform/Windows/GNAVI


text:
C Programming/Structure and style

C Structure and Style
This is a basic introduction to good coding style in the C Programming Language. It is designed to provide information on how to effectively use indentation, comments, and other elements that will make your C code more readable. It is not a tutorial on actual C programming.

As a beginning programmer, the point of creating structure in the program code might not be clear, as the compiler doesn't care about the difference. However, as programs become complex, chances are that writing the program has become a joint effort. (Or others might want to see how it was accomplished. Or you may have to read it again years later.) Well-written code also helps you get an overview of what the code does.

In the following sections, we will attempt to explain good programming practices that will in turn make your programs clearer.

Introduction
In C, programs are composed of statements. Statements are terminated with a semi-colon, and are collected in sections known as functions. By convention, a statement should be kept on its own line, as shown in the example below:

The following block of code is essentially the same. While it contains exactly the same code, and will compile and execute with the same result, the removal of spacing causes an essential difference: it's harder to read.

The simple use of indents and line breaks can greatly improve code readability without impacting code performance. Readable code makes it much easier to see where functions and procedures end and which lines are part of which loops and procedures.

This lesson is going to focus on improving the coding style of an example piece of code which applies a formula and prints the result. Later, you'll see how to write code for such tasks in more detail. For now, focus on how the code looks, not what it does.

Line Breaks and Indentation
The addition of white space inside your code is arguably the most important part of good code structure. Effective use of white space can create a visual scale of how your code flows, which can be very important when returning to your code when you want to maintain it.

Line Breaks
With minimal line breaks, code is barely human-readable, and may be hard to debug or understand:

Rather than putting everything on one line, it is much more readable to break up long lines so that each statement and declaration goes on its own line. After inserting line breaks, the code will look like this:

Blank Lines
Blank lines should be used to offset the main components of your code. Always use them:
 * After preprocessor directives.
 * After new variables are declared.
 * Use your own judgment for finding other places where components should be separated.

Based on these two rules, there should now be at least two line breaks added: This will make the code much more readable than it was before:
 * After line 1, because line 1 has a preprocessor directive.
 * After line 6, because line 6 contains a variable declaration.

The following lines of code have line breaks between functions, but without indentation.

But it's still not as readable as it can be.

Indentation
Although adding simple line breaks between key blocks of code can make code easier to read, it provides no information about the block structure of the program. Using the tab key can be very helpful. Indentation visually separates paths of execution by moving their starting points to a new column. This simple practice will make it much easier to read and understand code. Indentation follows a fairly simple rule:

 * All code inside a new block should be indented by one tab more than the code in the previous path.

Based on the code from the previous section, there are two blocks requiring indentation:

 * Lines 4 to 16
 * Line 13

It is now fairly obvious as to which parts of the program fit inside which blocks. You can tell which parts of the program the coder has intended to be conditional, and which ones he or she has not. Although it might not be immediately noticeable, once many nested paths get added to the structure of the program, the use of indentation can be very important. Thus, indentation makes the structure of your program clear.

It is claimed that research has shown that an indentation size between 2 to 4 characters is easier to read than 8 character indents. However, an indent of 8 characters may still be in use for some systems.

Comments
Comments in code can be useful for a variety of purposes. They provide the easiest way to set off specific parts of code (and their purpose); as well as providing a visual "split" between various parts of your code. Having good comments throughout your code will make it much easier to remember what specific parts of your code do.

Comments in modern flavors of C (and many other languages) can come in two forms:

and

Note that Single line comments are a more recent addition to C, so some compilers may not support them. A recent version of GCC will have no problems supporting them.

This section is going to focus on the various uses of each form of commentary.

Single-line Comments
Single-line comments are most useful for simple 'side' notes that explain what certain parts of the code do. The best places to put these comments are next to variable declarations, and next to pieces of code that may need explanation. Comments should make clear the intention and ideas behind the corresponding code. What is immediately obvious from reading the code does not belong in a comment.

Based on our previous program, there are various good places to place comments:
 * Line 5 and/or 6, to explain what 'int revenue' and 'int cost' represent,
 * Line 8, to explain what the variable 'roi' is going to be used for,
 * Line 10, to explain the idea of the calculation,
 * Line 12, to explain the purpose of the 'if'.

This will make our program look something like:

Multi-line Comments
Multi-line comments are most useful for long explanations of code. They can be used as copyright/licensing notices, and they can also be used to explain the purpose of a block of code. This can be useful for two reasons: They make your functions easier to understand, and they make it easier to spot errors in code. If you know what a block is supposed to do, then it is much easier to find the piece of code that is responsible if an error occurs.

As an example, suppose we had a program that was designed to print "Hello, World! " a certain number of lines, a specified number of times. There would be many for loops in this program. For this example, we shall call the number of lines i, and the number of strings per line as j.

A good example of a multi-line comment that describes 'for' loop i's purpose would be:

This provides a good explanation of what i's purpose is, whilst not going into detail of what j does. By going into detail over what the specific path does (and not ones inside it), it will be easier to troubleshoot the path.

Similarly, you should always include a multi-line comment before each function, to explain the role, preconditions and postconditions of each function. Always leave the technical details to the individual blocks inside your program - this makes it easier to troubleshoot.

A function descriptor should look something like: This system allows for an at-a-glance explanation of what the function should do. You can then go into detail over how each aspect of the program is achieved later on in the program.

Finally, if you like to have aesthetically-pleasing source code, the multi-line comment system allows for the easy addition of comment boxes. These make the comments stand out much more than they would otherwise. They look like this:

Applied to our original program, we can now include a much more descriptive and readable source code:

This will allow any outside users of the program an easy way to comprehend what the code functions are and how they operate. It also inhibits uncertainty with other like-named functions.

A few programmers add a column of stars on the right side of a block comment: But most programmers don't put any stars on the right side of a block comment. They feel that aligning the right side is a waste of time.

Comments written in source files can be used for documenting source code automatically by using popular tools like Doxygen.

title: C Programming/Structure and style


text:
Typography

Introduction
Broadly typography consists of the choice and application of: Typography can be broadly divided into:
 * /Fonts/, the software used to generate typefaces.
 * /Typefaces/, their style size and weight.
 * /Spacing/ of these letterforms, in words, paragraphs and lines.
 * /Arrangement/ of these blocks of information appropriately for the media on which they are to be distributed and read.
 * Display typography which aims to communicate visually as well as literally. It is often allusive and evocative in its visual form as well as the strict meaning of the language used. The history and associations of particular letterforms are carefully chosen to reinforce the message. Letter forms can be considered to be comparable to different ‘tones of voice’ or the full range of dramatic forms of speech.
 * Examples include: Advertising Hoardings, Posters, Book Jackets.
 * Text typography is primarily for continuous reading. It aims to unobtrusively convey the intentions of the author with as little informational ‘noise’ as possible. Letterforms or typefaces for continuous reading tend to be relatively conservative and displayed in a range of layout conventions appropriate to their use, to aid readability. There is often a complex hierarchy of information design to ensure that the relative importance of elements and optimal flow of information is implicit in the design.
 * Examples include: Book and magazine design. Fiction and non-fiction texts.
 * Website design is currently an interesting mixture of the two approaches, with the addition of new means of user interaction and animation.
 * Typography also includes the highly specialised field of type design but excludes the autographic craft traditions of lettering and calligraphy which are usually not considered part of this discipline unless they result in a full font or reusable typeface.

Suggested Readings
Some suggested current readings would include:
 * HELLER, Steven [2004] The Education of a Typographer, Allworth Press
 * LUPTON, Ellen [2004] Thinking with Type, Princeton
 * BAINES, Phil & HASLAM Andrew [2002] Type & Typography, Laurence King
 * JURY, David [2004] About Face

Sample Classes
Some seminal classics include:
 * MORISON, Stanley[] First Principles of Typography, Cambridge UP
 * SIMON, Oliver[] An Introduction to Typography, Faber
 * BRINGHURST, Robert [1992] the Elements of Typographic Style, Hartley & Marks
 * TRACY, Walter [1986] Letters of Credit, Gordon Fraser
 * TSCHICHOLD, Jan [] The New Typography
 * TSCHICHOLD, Jan [] Asymetric Typography, Faber
 * TSCHICHOLD, Jan [] The Form of the Book, Lund Humphries

title: Typography


text:
Template:Hindi

 * Introduction
 * Script
 * Devanagari
 * Combinations (Conjuncts)
 * Grammar
 * Gender
 * Honorifics
 * Plurals
 * Parts of speech
 * Conjugation
 * Questions
 * Word order
 * Negation
 * Nouns
 * Verbs
 * Pronouns
 * Tenses
 * Vocabulary
 * Everyday Phrases
 * Numbers
 * Days of the week
 * Colors
 * Family relations
 * Time

title: Template:Hindi