Lets say I have a function named loop(). In this loop() I increment a counter count.
I have few functions, A(), B(), C(), etc.
I want to call each one of these functions when the counter reaches some value (different for every function).
My current code looks like:
static unsigned int count = 0;
void loop(){
if (count == VALUE_ONE)
A();
if (count == VALUE_TWO)
B();
if (count == VALUE_THREE)
C();
..... //more cases
if (count == MAX_VAL)
count = 0;
else
count++;
}
VALUE_* are #defines so they are not being changed during the program.
Right now I am using regular if statements to check the counter value. But I want to avoid using the if statement to avoid branch mispredictions.
Is there a better way to do this? Something that will actually avoid branch mispredictions etc?
Edit:
The goal here is to optimize this part of code in order to make it in faster, as for now it sometimes doesn't finish until the time it should. I am aware that there might be a problem with function A(), B(), etc, but for now I am asking about this specific case.
To make it clear, VALUE_ONE, VALUE_TWO, VALUE_THREE, etc might be very large values and not increasing by 1. For example it might be:
#define VALUE_ONE 20
#define VALUE_TWO 1500
#define VALUE_THREE 99777
My compiler version is: gcc (GCC) 4.4.7
Why in the world are you worried about branch misprediction? Do you have a working program? Does it run too slowly? Have you narrowed the problem to branch misprediction in the code you present? Unless the answer to each of those questions is "yes", you are engaging in premature optimization.
Moreover, the conditional branches in the code you present appear to be highly predictable, at least if the counter is expected routinely to reach values in the tens or hundreds of thousands or more, as the updated example code seems to indicate. A misprediction rate on the order of 0.00001 or less -- which is about what you could expect -- will not have a measurable performance impact. Indeed, handling code such as you've presented is the bread and butter of branch prediction. You could hardly ask for a case more friendly to a branch-prediction unit.
In any event, since you are concerned about branch misprediction, your question must be not so much about avoiding the if statements in particular, but about avoiding conditional logic in general. As such, a switch construct probably is not better, at least not for the situation you describe, wherein you want to call functions only for a handful of the large number of distinct values the function will see, sprinkled across a wide range. Although the compiler could, in principle, implement such a switch via a jump table, it is unlikely to do so in your case because of how large the needed table would be, and how few of the elements would differ from the one for the default case.
A hash table has also been discussed, but that's no better, because then either you need conditional logic to distinguish between cache hits and cache misses, or else your hash table must for every input provide a function (pointer) to be called. Calling a function on every iteration would be far more costly than what you are doing now.
Additionally, you need a perfect hash function to avoid conditional logic in the HT implementation. If the possible values of your counter are bounded by a small enough number that a hash table / perfect hash could be used to avoid conditional logic, then a plain array of function pointers would be lighter-weight than a hash table, and could serve the same purpose. It would still have the same problem with function-call overhead, however. If you insist on avoiding conditional logic then this would probably be the best way to go for your particular problem. But don't.
Leave optimisations to the compiler in the first place. Concentrate on writing human-readable code. Optimise only iff you have a timing problem and after you profiled the code. Then concentrate on the hot-spots. If some code is good for branch-prediction is hard to predict with modern CPUs.
Use a switch (for an easier to read introduction please check a good C book) statement to make the code better readable:
switch ( count ) {
case VALUE_ONE:
f1();
break;
case VALUE_TWO:
f2();
break;
...
default:
// be aware to catch illegal/forgotten values, unless you
// are absolutely sure they can be ignored safely.
// still having a default label is good style to signal "I
// though about it".
break;
}
That is not only the most readable version, but also gives the compiler the best chance to optimize the code.
If the values are just increasing by 1 (1, 2, 3, ...), modern compilers will automatically generate a jump-table, even for partial successions (1, 2, 3, 7, 8, etc.), so that is as fast as a manually created function-table. If they are not, it still often will generate something like if ... else if ... else if ... constructs.
Note the case-labels must be constant-expressions.
Edit: After you clarified the values may not be adcascent, my answer still holds true. Depending on the number of compare-values, the switch still is the best solution unless prooved wrong. Try this first, profile and only optimise iff necessary. A hash-table might not be worth the effort.
Even if you'd use a hash-function, the switch above will come in handy. Just use the hash-value instead of count.
I'm skeptical whether the original function is a bottleneck or an effective place to be optimizing. But hey, I like puzzles...
Given that the count is incrementing and the match values are increasing, you really only need to test against the upcoming match value. And while you can't use your match values as an array index you could create states that can be used as an array index. Try something like this.
static unsigned int count = 0;
typedef enum
{
WAITING_FOR_VALUE_ONE = 0,
WAITING_FOR_VALUE_TWO,
WAITING_FOR_VALUE_THREE,
...,
WAITING_FOR_MAX_VALUE,
MAX_STATES
} MyStates;
static MyStates state = WAITING_FOR_VALUE_ONE;
void waitForValueOne()
{
if (count == VALUE_ONE)
{
A();
state++;
}
}
void waitForValueTwo()
{
if (count == VALUE_TWO)
{
B();
state++;
}
}
void waitForMaxValue()
{
if (count == MAX_VAL)
{
count = 0;
state = 0;
}
}
void (*stateHandlers[MAX_STATES]) () =
{
waitForValueOne,
waitForValueTwo,
waitForValueThree,
...
waitForMaxValue
}
void loop()
{
(*stateHandlers[state])();
count++;
}
After count reaches MAX_VAL, your original implementation will run the next loop with count = 0 whereas my implementation will run the next loop with count = 1. But I'm sure you can fix that if it's important.
Update:
I don't like how loop called the state handler every count. It really only needs to call the state handler when there is a match. And also the comparison doesn't need to be repeated in every state handler function if it's performed in loop. Here are a few edits that implement this improvement.
static MyStates state = WAITING_FOR_VALUE_ONE;
static unsigned int matchValue = VALUE_ONE;
void waitForValueOne()
{
A();
state++;
matchValue = VALUE_TWO;
}
void waitForValueTwo()
{
B();
state++;
matchValue = VALUE_THREE;
}
void waitForMaxValue()
{
count = 0;
state = 0;
matchValue = VALUE_ONE;
}
void loop()
{
if (count == matchValue)
{
(*stateHandlers[state])();
}
count++;
}
In your case I can't see any reason for an optimiziation.
But in the case your interrupt will be fired every 20µs and your handler consumes 50% of the complete cpu time, as you check aginst 200 values, then and only then you could change your code.
For an incrementing counter, you only need a single if as you always know which value will be the next one.
void isr(void)
{
count++;
if (count == nextValue)
{
if ( count == VALUE_ONE )
{
A();
nextValue=VALUE_TWO;
}
else if ( count == VALUE_TWO )
{
B();
nextValue=VALUE_THREE;
}
...
}
}
In 99% of the time, the ISR() only needs to increment the counter and check that the value isn't reached.
In reallity, I would use an array of actions and times, instead of the if else if block.
I want to know if its possible to modify an existing chess engine in C that works without multi-threading to be able to support multi-threading. I have no experience in this subject and would appreciate some guidance.
EDIT: To be more specific, is there anything I can add to my implementation of negamax to make it multi-thread compatible? :
static double alphaBetaMax(double alpha, double beta, int depthleft, game_t game, bool player)
{
move_t *cur;
move_t *tmp;
double score = 0;
bool did_move = false;
cur = getAllMoves(game, player);
if(cur == NULL) /*/ check mate*/
return -9999999*(player*2-1);
tmp = firstMove;
firstMove = 0;
while (cur != NULL)
{
game_t copy;
if(depthleft<=0 && !isCapture(game, cur)) { /* Quiescence search */
cur = cur->next;
continue;
}
did_move = true;
copyGame(game, ©);
makeMove(©, *cur);
firstMove = NULL;
score = -alphaBetaMax(-beta, -alpha, depthleft - 1, copy, !player);
if(board_count > MAX_BOARDS)
break;
freeGame(copy);
if(score > alpha)
alpha = score;
if (beta <= alpha)
break;
cur = cur->next;
}
firstMove=tmp;
freeMoves();
if(!did_move)
alpha = evaluate(game)*(player*2-1);
return alpha;
}
A fast chess engine relies on two things: Caching the evaluation of positions, and the alpha/beta strategy. Caching positions and making it thread safe and fast is hard. The alpha/beta strategy relies on the seemingly best move being completely evaluated before you start evaluating other moves. This also makes it tough to use multiple threads.
Beginner composer to Mozart: "Can you tell me how to compose a symphony"? Mozart to beginner: "Maybe at your young age you should try something easier first. " Beginner to Mozart: "But you wrote symphonies when you were much younger than I am now. " Mozart to beginner: "True, but I didn't have to ask anyone".
The Alpha-Beta pruning is inherently single-threaded in nature. There's been successful approaches using variations of Dynamic Tree Splitting which basically means searching various branches at the same time. However the likelihood (in a well tuned engine) that next branch will be searched (or beta-cut) does not usually outweigh the other parallelism bottlenecks like memory waits.
I would suggest, first modify your search to a "re-search" algorithm like NegaScout or PVS which with small code changes will give good improvements over your current pure Alpha-Beta, then secondly fine-tune your move ordering to yield efficient beta-cut.
Thereafter you could try to split the tree based on beta-cut chances. Typically there would be higher chance of cutoff when a move is found in the transposition-table or a killer move and lesser chance when starting to search bad captures and quiet moves.
Take a look at CPW for some thoughts on it and the YBWC algorithm.
Young Brothers Wait Concept
I'm currently writing a c++ chess engine and I have made a quite simple but not optimal solution:
First I'm generating all moves in the form of a list of structs
I start n threads which repeatedly grab "jobs" from the list
do their search and write back the result into the struct. When the
list is empty, a thread kills itself.
In the general search function I join the threads and loop through the results afterwards.
Is this approach most efficient?
As currently the focus on searching the most relevant moves first but you'll eventually look at all moves and also hardly get a cutoff at depth one but works fine
Simple to implement and in any case better than a "one-cpu" search. Even if one move takes way more time - it's running on one cpu, like back then :D
Maybe start out with that
I want to use minimax search (with alpha-beta pruning), or rather negamax search, to make a computer program play a card game.
The card game actually consists of 4 players. So in order to be able to use minimax etc., I simplify the game to "me" against the "others". After each "move", you can objectively read the current state's evaluation from the game itself. When all 4 players have placed the card, the highest wins them all - and the cards' values count.
As you don't know how the distribution of cards between the other 3 players is exactly, I thought you must simulate all possible distributions ("worlds") with the cards that are not yours. You have 12 cards, the other 3 players have 36 cards in total.
So my approach is this algorithm, where player is a number between 1 and 3 symbolizing the three computer players that the program might need to find moves for. And -player stands for the opponents, namely all the other three players together.
private Card computerPickCard(GameState state, ArrayList<Card> cards) {
int bestScore = Integer.MIN_VALUE;
Card bestMove = null;
int nCards = cards.size();
for (int i = 0; i < nCards; i++) {
if (state.moveIsLegal(cards.get(i))) { // if you are allowed to place this card
int score;
GameState futureState = state.testMove(cards.get(i)); // a move is the placing of a card (which returns a new game state)
score = negamaxSearch(-state.getPlayersTurn(), futureState, 1, Integer.MIN_VALUE, Integer.MAX_VALUE);
if (score > bestScore) {
bestScore = score;
bestMove = cards.get(i);
}
}
}
// now bestMove is the card to place
}
private int negamaxSearch(int player, GameState state, int depthLeft, int alpha, int beta) {
ArrayList<Card> cards;
if (player >= 1 && player <= 3) {
cards = state.getCards(player);
}
else {
if (player == -1) {
cards = state.getCards(0);
cards.addAll(state.getCards(2));
cards.addAll(state.getCards(3));
}
else if (player == -2) {
cards = state.getCards(0);
cards.addAll(state.getCards(1));
cards.addAll(state.getCards(3));
}
else {
cards = state.getCards(0);
cards.addAll(state.getCards(1));
cards.addAll(state.getCards(2));
}
}
if (depthLeft <= 0 || state.isEnd()) { // end of recursion as the game is finished or max depth is reached
if (player >= 1 && player <= 3) {
return state.getCurrentPoints(player); // player's points as a positive value (for self)
}
else {
return -state.getCurrentPoints(-player); // player's points as a negative value (for others)
}
}
else {
int score;
int nCards = cards.size();
if (player > 0) { // make one move (it's player's turn)
for (int i = 0; i < nCards; i++) {
GameState futureState = state.testMove(cards.get(i));
if (futureState != null) { // wenn Zug gültig ist
score = negamaxSuche(-player, futureState, depthLeft-1, -beta, -alpha);
if (score >= beta) {
return score;
}
if (score > alpha) {
alpha = score; // alpha acts like max
}
}
}
return alpha;
}
else { // make three moves (it's the others' turn)
for (int i = 0; i < nCards; i++) {
GameState futureState = state.testMove(cards.get(i));
if (futureState != null) { // if move is valid
for (int k = 0; k < nCards; k++) {
if (k != i) {
GameState futureStateLevel2 = futureState.testMove(cards.get(k));
if (futureStateLevel2 != null) { // if move is valid
for (int m = 0; m < nCards; m++) {
if (m != i && m != k) {
GameState futureStateLevel3 = futureStateLevel2.testMove(cards.get(m));
if (futureStateLevel3 != null) { // if move is valid
score = negamaxSuche(-player, futureStateLevel3, depthLeft-1, -beta, -alpha);
if (score >= beta) {
return score;
}
if (score > alpha) {
alpha = score; // alpha acts like max
}
}
}
}
}
}
}
}
}
return alpha;
}
}
}
This seems to work fine, but for a depth of 1 (depthLeft=1), the program already needs to calculate 50,000 moves (placed cards) on average. This is too much, of course!
So my questions are:
Is the implementation correct at all? Can you simulate a game like this? Regarding the imperfect information, especially?
How can you improve the algorithm in speed and work load?
Can I, for example, reduce the set of possible moves to a random set of 50% to improve speed, while keeping good results?
I found UCT algorithm to be a good solution (maybe). Do you know this algorithm? Can you help me implementing it?
I want to clarify details that the accepted answer doesn't really go into.
In many card games you can sample the unknown cards that your opponent could have instead of generating all of them. You can take into account information like short suits and the probability of holding certain cards given play so far when doing this sampling to weight the likelihood of each possible hand (each hand is a possible world that we'll solve independently). Then, you solve each hand using perfect information search. The best move over all of these worlds is often the best move overall - with some caveat.
In games like Poker this won't work very well -- the game is all about the hidden information. You have to precisely balance your actions to keep the information about your hand hidden.
But, in games like trick-based card games, this works pretty well - particularly since new information is being revealed all the time. Really good players have a good idea what everyone holds anyway. So, reasonably strong Skat and Bridge programs have been based on these ideas.
If you can completely solve the underlying world, that is best, but if you can't, you can use minimax or UCT to choose the best move in each world. There are also hybrid algorithms (ISMCTS) that try to mix this process together. Be careful about the claims here. Simple sampling approaches are easier to code -- you should try the simpler approach before a more complex one.
Here are some research papers that will give some more information on when the sampling approach to imperfect information has worked well:
Understanding the Success of Perfect Information Monte Carlo Sampling in Game Tree Search (This paper analyzes when the sampling approach is likely to work.)
Improving State Evaluation, Inference, and Search in Trick-Based Card Games (This paper describes the use of sampling in Skat)
Imperfect information in a computationally challenging game (This paper describes sampling in Bridge)
Information Set Monte Carlo Tree Search (This paper merges sampling and UCT/Monte Carlo Tree Search to avoid the issues in the first reference.)
The problem with rule-based approaches in the accepted answer is that they can't take advantage of computational resources beyond that required to create the initial rules. Furthermore, rule-based approaches will be limited by the power of the rules that you can write. Search-based approaches can use the power of combinatorial search to produce much stronger play than the author of the program.
Minimax search as you've implemented it is the wrong approach for games where there is so much uncertainty. Since you don't know the card distribution among the other players, your search will spend an exponential amount of time exploring games that could not happen given the actual distribution of the cards.
I think a better approach would be to start with good rules for play when you have little or no information about the other players' hands. Things like:
If you play first in a round, play your lowest card since you have little chance of winning the round.
If you play last in a round, play your lowest card that will win the round. If you can't win the round, then play your lowest card.
Have your program initially not bother with search and just play by these rules and have it assume that all the other players will use these heuristics as well. As the program observes what cards the first and last players of each round play it can build up a table of information about the cards each player likely holds. E.g. a 9 would have won this round, but player 3 didn't play it so he must not have any cards 9 or higher. As information is gathered about each player's hand the search space will eventually be constrained to the point where a minimax search of possible games could produce useful information about the next card to play.
I have this line:
0, 6 -> W(1) L(#);
or
\# -> #shift_right R W(1) L
I have to parse this line with flex, and take every element from every part of the arrow and put it in a list. I know how to match simple things, but I don't know how to match multiple things with the same rule. I'm not allowed to increase the limit for rules. I have a hint: parse the pieces, pieces will then combine, and I can use states, but I don't know how to do that, and I can't find examples on the net. Can someone help me?
So, here an example:
{
a -> W(b) #invert_loop;
b -> W(a) #invert_loop;
-> L(#)
}
When this section begins I have to create a structure for each line, where I put what is on the left of -> in a vector, those are some parameters, and the right side in a list, where each term is kinda another structure. For what is on the right side I wrote rules:
writex W([a-zA-Z0-9.#]) for W(anything).
So I need to parse these lines, so I can put the parameters and the structures int the big structure. Something like this(for the first line):
new bigStruc with param = a and list of struct = W(anything), #invert(it is a notation for a reference to another structure)
So what I need is to know how to parse these line so that I can create and create and fill these bigStruct, also using to rules for simple structure(i have all I need for these structures, but I don't how to parse so that I can use these methods).
Sorry for my English and I hope this time I was more clear on what I want.
Last-minute editing: I have matched the whole line with a rule, and then work on it with strtok. There is a way to use previous rules to see what type of structure i have to create? I mean not to stay and put a lots of if, but to use writex W([a-zA-Z0-9.#]) to know that i have to create that kind of structure?
Ok, lets see how this snippet works for you:
// these are exclusive rules, so they do not overlap, for inclusive rules, use %s
%x dataStructure
%x addRules
%%
<dataStructure>-> { BEGIN addRules; }
\{ { BEGIN dataStructure; }
<addRules>; { BEGIN dataStructure; }
<dataStructure>\} { BEGIN INITIAL; }
<dataStructure>[^,]+ { ECHO; } //this will output each comma separated token
<dataStructure>. { } //ignore anything else
<dataStructure>\n { } //ignore anything else
<addRules>[^ ]+ { ECHO; } //this will output each space separated rule
<addRules>. { } //ignore anything else
<addRules>\n { } //ignore anything else
%%
I'm not entirely sure what it it you want. Edit your original post to include the contents of your comments, with examples, and please structure your English better. If you can't explain what you want without contradicting yourself, I can't help you.
Sometimes when I am programming, I find that some particular control structure would be very useful to me, but is not directly available in my programming language. I think my most common desire is something like a "split while" (I have no idea what to actually call this):
{
foo();
} split_while( condition ) {
bar();
}
The semantics of this code would be that foo() is always run, and then the condition is checked. If true, then bar() is run and we go back to the first block (thus running foo() again, etc). Thanks to a comment by reddit user zxqdms, I have learned that Donald E. Knuth writes about this structure in his paper "Structured programming with go to statements" (see page 279).
What alternative control structures do you think are a useful way of organizing computation?
My goal here is to give myself and others new ways of thinking about structuring code, in order to improve chunking and reasoning.
Note: I'm not asking about how to generalize all possible control structures, whether by using jne, if/goto, Lisp macros, continuations, monads, combinators, quarks, or whatever else. I'm asking what specializations are useful in describing code.
One that's fairly common is the infinite loop. I'd like to write it like this:
forever {
// ...
}
Sometimes, I need to have a foreach loop with an index. It could be written like this:
foreach (index i) (var item in list) {
// ...
}
(I'm not particularly fond of this syntax, but you get the idea)
Most languages have built-in functions to cover the common cases, but "fencepost" loops are always a chore: loops where you want to do something on each iteration and also do something else between iterations. For example, joining strings with a separator:
string result = "";
for (int i = 0; i < items.Count; i++) {
result += items[i];
if (i < items.Count - 1) result += ", "; // This is gross.
// What if I can't access items by index?
// I have off-by-one errors *every* time I do this.
}
I know folds can cover this case, but sometimes you want something imperative. It would be cool if you could do:
string result = "";
foreach (var item in items) {
result += item;
} between {
result += ", ";
}
Loop with else:
while (condition) {
// ...
}
else {
// the else runs if the loop didn't run
}
{
foo();
} split_while( condition ) {
bar();
}
You can accomplish that pretty easily using a regular while:
while (true) {
foo();
if (!condition) break;
bar();
}
I do that pretty frequently now that I got over my irrational distaste for break.
If you look at Haskell, although there is special syntax for various control structures, control flow is often captured by types. The most common kind of such control types are Monads, Arrows and applicative functors. So if you want a special type of control flow, it's usually some kind of higher-order function and either you can write it yourself or find one in Haskells package database (Hackage) wich is quite big.
Such functions are usually in the Control namespace where you can find modules for parallel execution to errorhandling. Many of the control structures usually found in procedural languages have a function counterpart in Control.Monad, among these are loops and if statements. If-else is a keyworded expression in haskell, if without an else doesn't make sense in an expression, but perfect sense in a monad, so the if statements without an else is captured by the functions when and unless.
Another common case is doing list operation in a more general context. Functional languages are quite fond of fold, and the Specialized versions like map and filter. If you have a monad then there is a natural extension of fold to it. This is called foldM, and therefor there are also extensions of any specialized version of fold you can think of, like mapM and filterM.
This is just a general idea and syntax:
if (cond)
//do something
else (cond)
//do something
also (cond)
//do something
else
//do something
end
ALSO condition is always evaluated. ELSE works as usual.
It works for case too. Probably it is a good way to eliminate break statement:
case (exp)
also (const)
//do something
else (const)
//do something
also (const)
//do something
else
//do something
end
can be read as:
switch (exp)
case (const)
//do something
case (const)
//do something
break
case (const)
//do something
default
//do something
end
I don't know if this is useful or simple to read but it's an example.
With (lisp-style) macros, tail-calls, and continuations all of this is quaint.
With macros, if the standard control flow constructs are not sufficient for a given application, the programmer can write their own (and so much more). It would only require a simple macro to implement the constructs you gave as an example.
With tail-calls, one can factor out complex control flow patters (such as implementing a state machine) into functions.
Continuations are a powerful control flow primitive (try/catch are a restricted version of them). Combined with tail-calls and macros, complex control flow patterns (backtracking, parsing, etc.) become straight-forward. In addition, they are useful in web programming as with them you can invert the inversion of control; you can have a function that asks the user for some input, do some processing, asks the user for more input, etc.
To paraphrase the Scheme standard, instead of piling more features onto your language, you should seek to remove the limitations that make the other features appear necessary.
if not:
unless (condition) {
// ...
}
while not:
until (condition) {
// ...
}
Labeled loops are something I find myself missing sometimes from mainstream languages. e.g.,
int i, j;
for outer ( i = 0; i < M; ++i )
for ( j = 0; j < N; ++j )
if ( l1[ i ] == l2[ j ] )
break outer;
Yes, I can usually simulate this with a goto, but an equivalent for continue would require you to move the increment to the end of loop body after the label, hurting the readability. You can also do this by setting a flag in the inner loop and checking it at each iteration of the outer loop, but it always looks clumsy.
(Bonus: I'd sometimes like to have a redo to go along with continue and break. It would return to the start of the loop without evaluating the increment.)
I propose the "then" operator. It returns the left operand on the first iteration and the right operand on all other iterations:
var result = "";
foreach (var item in items) {
result += "" then ", ";
result += item;
}
in the first iteration it adds "" to the result in all others it adds ", ", so you get a string that contains each item separated by commas.
if (cond)
//do something
else (cond)
//do something
else (cond)
//do something
first
//do something
then
//do something
else (cond)
//do something
else
//do something
end
FIRST and THEN blocks runs if any of 3 conditionals are evaluated to true. FIRST block runs before the conditional block and THEN runs after the conditional block has ran.
ELSE conditional or final write following FIRST and THEN statement are independent from these blocks.
It can read as :
if (cond)
first()
//do something
then()
else (cond)
first()
//do something
then()
else (cond)
first()
//do something
then()
else (cond)
//do something
else
//do something
end
function first()
//do something
return
function then()
//do something
return
These functions are just a form to read. They wouldn't create scope. It's more like a gosub/return from Basic.
Usefulness and readability as matter of discussion.
How about
alternate {
statement 1,
statement 2,
[statement 3,...]
}
for cycling through the available statements on each successive pass.
Edit: trivial examples
table_row_color = alternate(RED, GREEN, BLUE);
player_color = alternate(color_list); // cycles through list items
alternate(
led_on(),
led_off()
);
Edit 2: In the third example above the syntax is maybe a bit confusing as it looks like a function. In fact, only one statement is evaluated on each pass, not both. A better syntax might be something like
alternate {
led_on();
}
then {
led_off();
}
Or something to that effect. However I do like the idea that the result of which ever is called can be used if desired (as in the color examples).
D's scope guards are a useful control structure that isn't seen very often.
I think I should mention CityScript (the scripting language of CityDesk) which has some really fancy looping constructs.
From the help file:
{$ forEach n var in (condition) sort-order $}
... text which appears for each item ....
{$ between $}
.. text which appears between each two items ....
{$ odd $}
.. text which appears for every other item, including the first ....
{$ even $}
.. text which appears for every other item, starting with the second ....
{$ else $}
.. text which appears if there are no items matching condition ....
{$ before $}
..text which appears before the loop, only if there are items matching condition
{$ after $}
..text which appears after the loop, only of there are items matching condition
{$ next $}
Also note that many control structures get a new meaning in monadic context, depending on the particular monad - look at mapM, filterM, whileM, sequence etc. in Haskell.
ignoring - To ignore exceptions occuring in a certain block of code.
try {
foo()
} catch {
case ex: SomeException => /* ignore */
case ex: SomeOtherException => /* ignore */
}
With an ignoring control construct, you could write it more concisely and more readably as:
ignoring(classOf[SomeException], classOf[SomeOtherException]) {
foo()
}
[ Scala provides this (and many other Exception handling control constructs) in its standard library, in util.control package. ]
I'd like to see a keyword for grouping output. Instead of this:
int lastValue = 0;
foreach (var val in dataSource)
{
if (lastValue != val.CustomerID)
{
WriteFooter(lastValue);
WriteHeader(val);
lastValue = val.CustomerID;
}
WriteRow(val);
}
if (lastValue != 0)
{
WriteFooter(lastValue);
}
how about something like this:
foreach(var val in dataSource)
groupon(val.CustomerID)
{
startgroup
{
WriteHeader(val);
}
endgroup
{
WriteFooter(val)
}
}
each
{
WriteRow(val);
}
If you have a decent platform, controls, and/or reporting formatting you won't need to write this code. But it's amazing how often I find myself doing this. The most annoying part is the footer after the last iteration - it's hard to do this in a real life example without duplicating code.
Something that replaces
bool found = false;
for (int i = 0; i < N; i++) {
if (hasProperty(A[i])) {
found = true;
DoSomething(A[i]);
break;
}
}
if (!found) {
...
}
like
for (int i = 0; i < N; i++) {
if (hasProperty(A[i])) {
DoSomething(A[i]);
break;
}
} ifnotinterrupted {
...
}
I always feel that there must be a better way than introducing a flag just to execute something after the last (regular) execution of the loop body. One could check !(i < N), but i is out of scope after the loop.
This is a bit of a joke, but you can get the behavior you want like this:
#include <iostream>
#include <cstdlib>
int main (int argc, char *argv[])
{
int N = std::strtol(argv[1], 0, 10); // Danger!
int state = 0;
switch (state%2) // Similar to Duff's device.
{
do {
case 1: std::cout << (2*state) << " B" << std::endl;
case 0: std::cout << (2*state+1) << " A" << std::endl; ++state;
} while (state <= N);
default: break;
}
return 0;
}
p.s. formatting this was a bit difficult and I'm definitely not happy with it; however, emacs does even worse. Anyone care to try vim?
Generators, in Python, are genuinely novel if you've mostly worked with non-functional languages. More generally: continuations, co-routines, lazy lists.
This probably doesn't count, but in Python, I was upset there was no do loop.
Anto ensure I get no upvotes for this answer, I wind up annoyed at any language I work in for any period of time that lacks goto's.
for int i := 0 [down]to UpperBound() [step 2]
Missing in every C-derived language.
Please consider before you vote or write a comment:
This is not redundant to for (int i = 0; i <= UpperBound(); i++), it has different semantics:
UpperBound() is evaluated only once
The case UpperBound() == MAX_INT does not produce an infinite loop
This is similar to the response by #Paul Keister.
(mumble, mumble) years ago, the application I was working on had lots of variations of so-called control-break processing -- all that logic that goes into breaking sorted rows of data into groups and subgroups with headers and footers. As the application was written in LISP, we had captured the common idioms in a macro called WITH-CONTROL-BREAKS. If I were to transpose that syntax into the ever-popular squiggly form, it might look something like this:
withControlBreaks (x, y, z : readSortedRecords()) {
first (x) : { emitHeader(x); subcount = 0; }
first (x, y) : { emitSubheader(x, y); zTotal = 0; }
all (x, y, z) : { emitDetail(x, y, z); ztotal += z; }
last (x, y) : { emitSubfooter(x, y, zTotal); ++subCount; }
last (x) : { emitFooter(x, subcount); }
}
In this modern era, with widespread SQL, XQuery, LINQ and so on, this need does not seem to arise as much as it used to. But from time to time, I wish that I had that control structure at hand.
foo();
while(condition)
{
bar();
foo();
}
How about PL/I style "for" loop ranges? The VB equivalent would be:
' Counts 1, 2, ... 49, 50, 23, 999, 998, ..., 991, 990
For I = 1 to 50, 23, 999 to 990 Step -1
The most common usage I can see would be to have a loop run for a list of indices, and then throw in one more. BTW, a For-Each usage could also be handy:
' Bar1, Bar2, Bar3 are an IEnum(Wazoo); Boz is a Wazoo
For Each Foo as Wazoo in Bar1, Bar2, Enumerable.One(Boz), Bar3
This would run the loop on all items in Bar1, all items in Bar2, Boz, and Bar3. Linq would probably allow this without too much difficulty, but intrinsic language support might be a little more efficient.
One of the control structures that isn't available in many languages is the case-in type structure. Similar to a switch type structure, it allows you to have a neatly formatted list of possible options, but matches the first one that's true (rather then the first one that matches the input). A LISP of such such (which does have it):
(cond
((evenp a) a) ;if a is even return a
((> a 7) (/ a 2)) ;else if a is bigger than 7 return a/2
((< a 5) (- a 1)) ;else if a is smaller than 5 return a-1
(t 17)) ;else return 17
Or, for those that would prefer a more C-like format
cond
(a % 2 == 0):
a; break;
(a > 7):
a / 2; break;
(a < 5):
a - 1; break;
default:
17; break;
It's basically a more accurate representation of the if/elseif/elseif/else construct than a switch is, and it can come in extremely handing in expressing that logic in a clean, readable way.
How about iterating with a moving window (of n elements instead of 1) through a list?
This is tangentially related #munificent's answer, I think.
Something like
#python
#sum of adjacent elements
for x,y in pairs(list):
print x + y
def pairs(l):
i=0
while i < len(l)-1:
yield (l[i],l[i+1])
i+=1
It is useful for certain types of things. Don't get me wrong, this is easy to implement as a function, but I think a lot of people try to bring out for and while loops when there are more specific/descriptive tools for the job.