i think it is worth to increase the it budgets on security to 20%. Because there is more awareness for multiple layers of security measures. High profile data breaches ensure executives know what is at stake, it's not just the security pros, network managers and system admins scrambling for adequate budgets.
It's not clear whether overall IT budgets are growing in the surveyed organizations but I'd guess they're not, at least not by much. I suspect IT budgeting is still pretty much a zero-sum game. While the added spending on security is good news, I suspect it means other worthy projects are not funded. Add that to the cost of cybercrime
Re:I agree... no time soon..
on
Cracking Go
·
· Score: 1
This is the explanation about Go before i explain about the problems. However, i read this information somewhere.
Go is played on a board crisscrossed by 19 vertical and 19 horizontal lines whose 361 points of intersection constitute the playing field. The object is to conquer those intersection points.
A player makes a move by placing a lozenge-shaped "stone" on an intersection, then the other player counters, and the two alternate moves. Players capture enemy stones by surrounding them, that is, by removing their "liberties," which consist of either the vacant points adjacent to a stone itself or to friendly stones to which it is itself connected (see illustration, "The Goal of Go"). When no more moves are possible, the players count up the intersection points they control, and the player with the most points wins.
All the leading Go programmers today belittle brute force. In this they resemble the computer chess experts of 40 years ago. Selective search dominated thinking on computer chess from the late 1940s to the late 1970s, and that mind-set prevented any program from advancing beyond the level of a Class C player.
Go does, however, present two real problems, both having to do with the amount of searching the program must perform.
(1)The first problem is the tree of analysis. Because Go offers more possibilities at every turn, the tree is far bigger for Go than for chess. At the start of the game, the first player can place a stone on any one of 361 positions, the second player has 360 choices, and so on. A typical game lasts about 200 moves, so it averages at least 200 move choices per turn--nearly 10 times as many as in the average chess position.
(2)The second problem is the evaluation of the end positions. In Go you can't just count up stones, because you have to know which stones are worth counting. Conquered territory is defined as board space occupied or surrounded by "living" stones--stones the opponent cannot capture by removing their liberties. Before you can count a stone as live, you have to calculate several moves ahead just to satisfy yourself that it is really there in the first place.
Put these two problems together and you get a computational problem that at first glance seems intractable
Slashdot Mirror
i think it is worth to increase the it budgets on security to 20%. Because there is more awareness for multiple layers of security measures. High profile data breaches ensure executives know what is at stake, it's not just the security pros, network managers and system admins scrambling for adequate budgets.
It's not clear whether overall IT budgets are growing in the surveyed organizations but I'd guess they're not, at least not by much. I suspect IT budgeting is still pretty much a zero-sum game. While the added spending on security is good news, I suspect it means other worthy projects are not funded. Add that to the cost of cybercrime
This is the explanation about Go before i explain about the problems. However, i read this information somewhere.
Go is played on a board crisscrossed by 19 vertical and 19 horizontal lines whose 361 points of intersection constitute the playing field. The object is to conquer those intersection points.
A player makes a move by placing a lozenge-shaped "stone" on an intersection, then the other player counters, and the two alternate moves. Players capture enemy stones by surrounding them, that is, by removing their "liberties," which consist of either the vacant points adjacent to a stone itself or to friendly stones to which it is itself connected (see illustration, "The Goal of Go"). When no more moves are possible, the players count up the intersection points they control, and the player with the most points wins.
All the leading Go programmers today belittle brute force. In this they resemble the computer chess experts of 40 years ago. Selective search dominated thinking on computer chess from the late 1940s to the late 1970s, and that mind-set prevented any program from advancing beyond the level of a Class C player.
Go does, however, present two real problems, both having to do with the amount of searching the program must perform.
(1)The first problem is the tree of analysis. Because Go offers more possibilities at every turn, the tree is far bigger for Go than for chess. At the start of the game, the first player can place a stone on any one of 361 positions, the second player has 360 choices, and so on. A typical game lasts about 200 moves, so it averages at least 200 move choices per turn--nearly 10 times as many as in the average chess position.
(2)The second problem is the evaluation of the end positions. In Go you can't just count up stones, because you have to know which stones are worth counting. Conquered territory is defined as board space occupied or surrounded by "living" stones--stones the opponent cannot capture by removing their liberties. Before you can count a stone as live, you have to calculate several moves ahead just to satisfy yourself that it is really there in the first place.
Put these two problems together and you get a computational problem that at first glance seems intractable