Showing posts with label rules. Show all posts
Showing posts with label rules. Show all posts

24 May 2014

🕸Systems Engineering: Cellular Automata (Definitions)

"Cellular automata are mathematical models for complex natural systems containing large numbers of simple identical components with local interactions. They consist of a lattice of sites, each with a finite set of possible values. The value of the sites evolve synchronously in discrete time steps according to identical rules. The value of a particular site is determined by the previous values of a neighbourhood of sites around it." (Stephen Wolfram, "Nonlinear Phenomena, Universality and complexity in cellular automata", Physica 10D, 1984)

"A mathematical construct and technique that models a system in discrete time and discrete space in which the state of a cell depends on transition rules and the states of neighboring cells." (Charles M Macal, "Agent Based Modeling and Artificial Life", 2009) 

[Cellular automaton:] A spatially-extended dynamical system in which spatially-discrete cells take on discrete values, and evolve according to a spatially-localized discrete-time update rule." (James E Hanson, "Emergent Phenomena in Cellular Automata", 2009)

"A spatiotemporal modeling technique in which a set of rules is applied to determine the state transitions of individual cells based on each cell’s current state and the states of its neighbors." (May Yuan, "Challenges and Critical Issues for Temporal GIS Research and Technologies", 2009) 

"Cellular Automata (CA) are discrete, spatially explicit extended dynamic systems composed of adjacent cells characterized by an internal state whose value belongs to a finite set. The updating of these states is made simultaneously according to a common local transition rule involving only a neighborhood of each cell." (Ramon Alonso-Sanz, "Cellular Automata with Memory", 2009) 

"Cellular automata are dynamical systems that are discrete in space, time, and value. A state of a cellular automaton is a spatial array of discrete cells, each containing a value chosen from a finite alphabet. The state space for a cellular automaton is the set of all such configurations." (Burton Voorhees, "Additive Cellular Automata", 2009) 

"They are dynamical systems that are continuous, local, parallel, synchronous and space and time uniform. Cellular automata are used to model phenomena where the space can be regularly partitioned and where the same rules are used everywhere [...]" (Jerome Durand-Lose, "Universality of Cellular Automata", 2009)

"A discrete model consisting of a grip of cells each of which have a finite number of defined states where the state of a cells is a function of the states of neighboring cells and the transition among states is according to some predefined updating rule. (Brian L Heath & Raymond R Hill, "Agent-Based Modeling: A Historical Perspective and a Review of Validation and Verification Efforts, 2010)

"A cellular automaton is composed of a set of discrete elements - the cells - connected with other cells of the automaton, and in each time unit each cell receives information about the current state of the cells to which it is connected. The cellular automaton evolve according a transition rule that specifies the current possible states of each cell as a function of the preceding state of the cell and the states of the connected cells." (Francesc S Beltran et al, "A Language Shift Simulation Based on Cellular Automata", 2011)

"Cellular automata (CA) are idealizations of physical systems in which both space and time are assumed to be discrete and each of the interacting units can have only a finite number of discrete states." (Andreas Schadschneider et al, "Vehicular Traffic II: The Nagel–Schreckenberg Model" , 2011)

"Cellular automata (henceforth: CA) are discrete, abstract computational systems that have proved useful both as general models of complexity and as more specific representations of non-linear dynamics in a variety of scientific fields." (Francesco Berto & Jacopo Tagliabue, "Cellular Automata", Stanford Encyclopedia of Philosophy, 2012) 

29 November 2011

📉Graphical Representation: Rules (Just the Quotes)

"Graphic representation by means of charts depends upon the super-position of special lines or curves upon base lines drawn or ruled in a standard manner. For the economic construction of these charts as well as their correct use it is necessary that the standard rulings be correctly designed." (Allan C Haskell, "How to Make and Use Graphic Charts", 1919)

"It is not possible to lay down any hard and fast rules for determining what chart is the best for any given problem. Ordinarily that one is the best which will produce the quickest and clearest results. but unfortunately it is not always possible to construct the clearest one in the least time. Experience is the best guide. Generally speaking, a rectilinear chart is best adapted for equations of the first degree, logarithmic for those other than the first degree and not containing over two variables, and alignment charts where there are three or more variables. However, nearly every person becomes more or less familiar with one type of chart and prefers to adhere to the use of that type because he does not care to take the time and trouble to find out how to use the others. It is best to know what the possibilities of all types are and to be governed accordingly when selecting one or the other for presenting or working out certain data." (Allan C Haskell, "How to Make and Use Graphic Charts", 1919)

"The principles of charting and curve plotting are not at all complex, and it is surprising that many business men dodge the simplest charts as though they involved higher mathematics or contained some sort of black magic. [...] The trouble at present is that there are no standards by which graphic presentations can be prepared in accordance with definite rules so that their interpretation by the reader may be both rapid and accurate. It is certain that there will evolve for methods of graphic presentation a few useful and definite rules which will correspond with the rules of grammar for the spoken and written language." (Willard C Brinton, "Graphic Methods for Presenting Facts", 1919) 

"The eye can accurately appraise only very few features of a diagram, and consequently a complicated or confusing diagram will lead the reader astray. The fundamental rule for all charting is to use a plan which is simple and which takes account, in its arrangement of the facts to be presented, of the above-mentioned capacities of the eye."  (William L Crum et al, "Introduction to Economic Statistics", 1938)

"In making up the charts, keep them simple. One idea to a page and not too much detail is a good rule. Try to get variety in the subject matter - now a chart, next a diagram, then a tabulation. Such variety helps hold audience attention." (Edward J Hegarty, "How to Use a Set of Display Charts", The American Statistician Vol. 2 (5), 1948)

"The grid lines should be lighter than the curves, with the base line somewhat heavier than the others. All vertical lines should be of equal weight, unless the time scale is subdivided in quarters or other time periods, indicated by heavier rules. Very wide base lines, sometimes employed for pictorial effect, distort the graphic impression by making the base line the most prominent feature of the chart." (Rufus R Lutz, "Graphic Presentation Simplified", 1949)

"The number of grid lines should be kept to a minimum. This means that there should be just enough coordinate lines in the field so that the eye can readily interpret the values at any point on the curve. No definite rule can be specified as to the optimum number of lines in a grid. This must be left to the discretion of the chart-maker and can come only from experience. The size of the chart, the type and range of the data. the number of curves, the length and detail of the period covered, as well as other factors, will help to determine the number of grid lines." (Calvin F Schmid, "Handbook of Graphic Presentation", 1954)

"As a general rule, plotted points and graph lines should be given more 'weight' than the axes. In this way the 'meat' will be easily distinguishable from the 'bones'. Furthermore, an illustration composed of lines of unequal weights is always more attractive than one in which all the lines are of uniform thickness. It may not always be possible to emphasise the data in this way however. In a scattergram, for example, the more plotted points there are, the smaller they may need to be and this will give them a lighter appearance. Similarly, the more curves there are on a graph, the thinner the lines may need to be. In both cases, the axes may look better if they are drawn with a somewhat bolder line so that they are easily distinguishable from the data." (Linda Reynolds & Doig Simmonds, "Presentation of Data in Science" 4th Ed, 1984)

"The rule is that a graph of a change in a variable with time should always have a vertical scale that starts with zero. Otherwise, it is inherently misleading." (Douglas A Downing & Jeffrey Clark, "Forgotten Statistics: A Self-Teaching Refresher Course", 1996) 

"[...] when data is presented in certain ways, the patterns can be readily perceived. If we can understand how perception works, our knowledge can be translated into rules for displaying information. Following perception‐based rules, we can present our data in such a way that the important and informative patterns stand out. If we disobey the rules, our data will be incomprehensible or misleading." (Colin Ware, "Information Visualization: Perception for Design" 2nd Ed., 2004)

"Plotting data is a useful first stage to any analysis and will show extreme observations together with any discernible patterns. In addition the relative sizes of categories are easier to see in a diagram (bar chart or pie chart) than in a table. Graphs are useful as they can be assimilated quickly, and are particularly helpful when presenting information to an audience. Tables can be useful for displaying information about many variables at once, while graphs can be useful for showing multiple observations on groups or individuals. Although there are no hard and fast rules about when to use a graph and when to use a table, in the context of a report or a paper it is often best to use tables so that the reader can scrutinise the numbers directly." (Jenny Freeman et al, "How to Display Data", 2008)

"[...] if you want to show change through time, use a time-series chart; if you need to compare, use a bar chart; or to display correlation, use a scatter-plot - because some of these rules make good common sense." (Alberto Cairo, "The Functional Art", 2011)

"For every rule in data visualization, there is a scenario where that rule should be broken. This means that choosing the best chart or the best design is always a trade-off between several conflicting goals. Our imperfect perception means that data visualization has a larger subjective dimension than a data table. Sometimes we only need this subjective, impressionist dimension and other times we need to translate it into hard figures. Striving for accuracy is important, but it’s more important to provide those insights that only a visual display can reveal." (Jorge Camões, "Data at Work: Best practices for creating effective charts and information graphics in Microsoft Excel", 2016)

"There can be several reasons why someone breaks the rules, whether from ignorance, malice, or the sincere desire to find a more effective way to explore the data or communicate the results. Whatever the reason, breaking the rules frustrates the audience’s expectations and will incur a cost. Sometimes you might consider this an investment, while often it is nothing more than waste." (Jorge Camões, "Data at Work: Best practices for creating effective charts and information graphics in Microsoft Excel", 2016)

"A perfectly relevant visualization that breaks a few presentation rules is far more valuable - it’s better - than a perfectly executed, beautiful chart that contains the wrong data, communicates the wrong message, or fails to engage its audience." (Scott Berinato, "Good Charts : the HBR guide to making smarter, more persuasive data visualizations", 2023)

"But rules are open to interpretation and sometimes arbitrary or even counterproductive when it comes to producing good visualizations. They’re for responding to context, not setting it. Instead of worrying about whether a chart is "right" or "wrong", focus on whether it’s good." (Scott Berinato, "Good Charts : the HBR guide to making smarter, more persuasive data visualizations", 2023)

14 March 2009

🛢DBMS: Rule (Definitions)

"A specification that controls what data may be entered in a particular column, or in a column of a particular user-defined datatype." (Karen Paulsell et al, "Sybase SQL Server: Performance and Tuning Guide", 1996)

"Objects used to enforce business policies by ensuring that data inserted into a column match a certain pattern or fall with a range of values." (Owen Williams, "MCSE TestPrep: SQL Server 6.5 Design and Implementation", 1998)

"A database object that is bound to a column or user-defined data type that specifies what data can be entered in that column. Every time a user enters or modifies a value (with an INSERT or UPDATE statement), SQL Server checks it against the most recent rule bound to the specified column - for example, for limit checking or list checking. Data entered before the creation and binding of a rule is not checked. Rules are supported primarily for backward compatibility." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"A database object that is bound to columns or user-defined data types, and specifies what data values are acceptable in a column. CHECK constraints provide the same functionality and are preferred because they are in the SQL-92 standard." (Thomas Moore, "EXAM CRAM™ 2: Designing and Implementing Databases with SQL Server 2000 Enterprise Edition", 2005)

"A database object that can be applied to columns or alias data types to enforce domain integrity. Is deprecated and should not be used." (Sara Morganand & Tobias Thernstrom , "MCITP Self-Paced Training Kit : Designing and Optimizing Data Access by Using Microsoft SQL Server 2005 - Exam 70-442", 2007)

"1. A database object that is bound to columns or alias data types, and specifies which data values are acceptable in a column. CHECK constraints provide the same functionality and are preferred because they are in the SQL-92 standard. 2. In Analysis Services, a rule specifies restrictions such as Unrestricted, Fully Restricted, or Custom for security read and read/write role permissions." (Microsoft Technet)

13 December 2007

🏗️Software Engineering: Rules (Just the Quotes)

"It is a good rule of thumb that a program should read from top to bottom in the order that it will be executed; if this is not true, watch out for the bugs that often accompany poor structure. Make your programs read from top to bottom." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures." (Rob Pike, "Notes on Programming in C" , 1989)

"Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." (Rob Pike, "Notes on Programming in C", 1989)

"Apart from power laws, iteration is one of the prime sources of self-similarity. Iteration here means the repeated application of some rule or operation - doing the same thing over and over again. [... ] A concept closely related to iteration is recursion. In an age of increasing automation and computation, many processes and calculations are recursive, and if a recursive algorithm is in fact repetitious, self-similarity is waiting in the wings.(Manfred Schroeder, "Fractals, Chaos, Power Laws Minutes from an Infinite Paradise", 1990)

"At the heart of reengineering is the notion of discontinuous thinking - of recognizing and breaking away from the outdated rules and fundamental assumptions that underlie operations. Unless we change these rules, we are merely rearranging the deck chairs on the Titanic. We cannot achieve breakthroughs in performance by cutting fat or automating existing processes. Rather, we must challenge old assumptions and shed the old rules that made the business underperform in the first place." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990)

"The underlying message of all these rules is that inheritance tends to work against the primary technical imperative you have as a programmer, which is to manage complexity. For the sake of controlling complexity, you should maintain a heavy bias against inheritance." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Heuristic" (it is of Greek origin) means discovery. Heuristic methods are based on experience, rational ideas, and rules of thumb. Heuristics are based more on common sense than on mathematics. Heuristics are useful, for example, when the optimal solution needs an exhaustive search that is not realistic in terms of time. In principle, a heuristic does not guarantee the best solution, but a heuristic solution can provide a tremendous shortcut in cost and time." (Nikola K Kasabov, "Foundations of Neural Networks, Fuzzy Systems, and Knowledge Engineering", 1996)

"All OO languages show some tendency to suck programmers into the trap of excessive layering. Object frameworks and object browsers are not a substitute for good design or documentation, but they often get treated as one. Too many layers destroy transparency: It becomes too difficult to see down through them and mentally model what the code is actually doing. The Rules of Simplicity, Clarity, and Transparency get violated wholesale, and the result is code full of obscure bugs and continuing maintenance problems." (Eric S Raymond, "The Art of Unix Programming", 2003)

"Software design patterns are what allow us to describe design fragments, and reuse design ideas, helping developers leverage the expertise of others. Patterns give a name and form to abstract heuristics, rules and best practices of object-oriented techniques." (Philippe Kruchten, [foreword] 2004)

"The traditional view on software architecture suffers from a number of key problems that cannot be solved without changing our perspective on the notion of software architecture. These problems include the lack of first-class representation of design decisions, the fact that these design decisions are cross-cutting and intertwined, that these problems lead to high maintenance cost, because of which design rules and constraints are easily violated and obsolete design decisions are not removed." (Jan Bosch, "Software architecture: The next step", 2004)

"A heuristic is a rule applied to an existing solution represented in a perspective that generates a new" (and hopefully better) solution or a new set of possible solutions." (Scott E Page, "The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools and Societies", 2008)

"You should choose a set of simple rules that govern the format of your code, and then you should consistently apply those rules. If you are working on a team, then the team should agree to a single set of formatting rules and all members should comply." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"As a general rule, implementations do not just spontaneously combust. Failures tend to stem from the aggregation of many issues. Although some issues may have been known since the early stages of the project" (for example, the sales cycle or system design), implementation teams discover the majority of problems during the middle of the implementation, typically during some form of testing." (Phil Simon, "Why New Systems Fail: An Insider's Guide to Successful IT Projects", 2010)

"Making domain concepts explicit in your code means other programmers can gather the intent of the code much more easily than by trying to retrofit an algorithm into what they understand about a domain. It also means that when the domain model evolves - which it will, as your understanding of the domain grows - you are in a good position to evolve the code. Coupled with good encapsulation, the chances are good that the rule will exist in only one place, and that you can change it without any of the dependent code being any the wiser." (Dan North [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])

"[...] heuristics are simple, efficient rules - either hard-wired in our brains or learned - that kick in especially when we're facing problems with incomplete information." (David DiSalvo, "What Makes Your Brain Happy and Why You Should Do the Opposite", 2011)

"But the history of large systems demonstrates that, once the hurdle of stability has been cleared, a more subtle challenge appears. It is the challenge of remaining stable when the rules change. Machines, like organizations or organisms, that fail to meet this challenge find that their previous stability is no longer of any use. The responses that once were life-saving now just make things worse. What is needed now is the capacity to re-write the procedure manual on short notice, or even" (most radical change of all) to change goals." (John Gall, "The Systems Bible: The Beginner's Guide to Systems Large and Small"[Systematics 3rd Ed.], 2011)

"Coding standards are rules, sometimes relatively arbitrary, that define the coding styles and conventions that are considered acceptable within a team or organization. In many cases, agreeing on a set of standards, and applying them, is more important than the standards themselves." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"Heuristics are simplified rules of thumb that make things simple and easy to implement. But their main advantage is that the user knows that they are not perfect, just expedient, and is therefore less fooled by their powers. They become dangerous when we forget that." (Nassim N Taleb, "Antifragile: Things that gain from disorder", 2012)

"Ultimately, software quality boils down to a matter of tradeoffs, and there's no one universal rule for how to do things. [... ] Rigidly adhering to a notion of building something 'the right way' can paralyze discussions about tradeoffs and other viable options. Pragmatism - thinking in terms of what does and doesn't work for achieving our goals - is a more effective lens through which to reason about quality." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Breaking rules is indeed an important part of creativity. Innovation needs a level of guidance." (Pearl Zhu,  "Digitizing Boardroom: The Multifaceted Aspects of Digital Ready Boards", 2016)

"It is not loyalty or internal motivation that drives us programmers forward. We must write our code when the road to our personal success is absolutely clear for us and writing high quality code obviously helps us move forward on this road. To make this happen, the management has to define the rules of the game, also known as process", and make sure they are strictly enforced, which is much more difficult than 'being agile'."" (Yegor Bugayenko, "Code Ahead", 2018)

"Engineering is an art of simplification, and the rules - when and how to simplify - are a matter of experience and intuition." (Olle I Elgerd)


10 December 2007

🏗️Software Engineering: Heuristic (Just the Quotes)

"Heuristic reasoning is reasoning not regarded as final and strict but as provisional and plausible only, whose purpose is to discover the solution of the present problem. We are often obliged to use heuristic reasoning. We shall attain complete certainty when we shall have obtained the complete solution, but before obtaining certainty we must often be satisfied with a more or less plausible guess. We may need the provisional before we attain the final. We need heuristic reasoning when we construct a strict proof as we need scaffolding when we erect a building." (George Pólya, "How to Solve It", 1945)

"The aim of heuristics is to study the methods and rules of discovery and invention. [...] Heuristic, as an adjective, means 'serving to discover'." (George Pólya, "How to Solve It", 1945)

"An algorithm gives you the instructions directly. A heuristic tells you how to discover the instructions for yourself, or at least where to look for them." (Steve McConnell, "Code Complete", 1993)

"Heuristic (it is of Greek origin) means discovery. Heuristic methods are based on experience, rational ideas, and rules of thumb. Heuristics are based more on common sense than on mathematics. Heuristics are useful, for example, when the optimal solution needs an exhaustive search that is not realistic in terms of time. In principle, a heuristic does not guarantee the best solution, but a heuristic solution can provide a tremendous shortcut in cost and time." (Nikola K Kasabov, "Foundations of Neural Networks, Fuzzy Systems, and Knowledge Engineering", 1996)

"Heuristic methods may aim at local optimization rather than at global optimization, that is, the algorithm optimizes the solution stepwise, finding the best solution at each small step of the solution process and 'hoping' that the global solution, which comprises the local ones, would be satisfactory." (Nikola K Kasabov, "Foundations of Neural Networks, Fuzzy Systems, and Knowledge Engineering", 1996)

"Models of bounded rationality describe how a judgement or decision is reached (that is, the heuristic processes or proximal mechanisms) rather than merely the outcome of the decision, and they describe the class of environments in which these heuristics will succeed or fail." (Gerd Gigerenzer & Reinhard Selten [Eds., "Bounded Rationality: The Adaptive Toolbox", 2001)

"A heuristic is a rule applied to an existing solution represented in a perspective that generates a new (and hopefully better) solution or a new set of possible solutions." (Scott E Page, "The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools and Societies", 2008)

"There are two parts to learning craftsmanship: knowledge and work. You must gain the knowledge of principles, patterns, practices, and heuristics that a craftsman knows, and you must also grind that knowledge into your fingers, eyes, and gut by working hard and practicing." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"A second class of metaphors - mathematical algorithms, heuristics, and models - brings us closer to the world of computer science programs, simulations, and approximations of the brain and its cognitive processes." (Diego Rasskin-Gutman, "Chess Metaphors: Artificial Intelligence and the Human Mind", 2009)

"[...] heuristics are simple, efficient rules - either hard-wired in our brains or learned - that kick in especially when we're facing problems with incomplete information." (David DiSalvo, "What Makes Your Brain Happy and Why You Should Do the Opposite", 2011)

"This is the essence of intuitive heuristics: when faced with a difficult question, we often answer an easier one instead, usually without noticing the substitution." (Daniel Kahneman, "Thinking, Fast and Slow", 2011)

"Heuristics are simplified rules of thumb that make things simple and easy to implement. But their main advantage is that the user knows that they are not perfect, just expedient, and is therefore less fooled by their powers. They become dangerous when we forget that." (Nassim N Taleb, "Antifragile: Things that gain from disorder", 2012)

"A good heuristic decision is made by 1) knowing what to look for, 2) knowing when enough information is enough (the 'threshold of decision' ), and 3) knowing what decision to make." (Patrick Van Horne, "Left of Bang", 2014)

"Heuristic decision making is fast and frugal and is often based on the evaluation of one or two salient bits of information." (Amitav Chakravarti, "Why People (Don’t) Buy: The Go and Stop Signals", 2015)

"A heuristic is a strategy we derive from previous experience with a similar problem." (Darius Foroux, "Think Straight", 2017)

More quotes on "Heuristic" at the-web-of-knowledge.blogspot.com

Related Posts Plugin for WordPress, Blogger...

About Me

My photo
Koeln, NRW, Germany
IT Professional with more than 24 years experience in IT in the area of full life-cycle of Web/Desktop/Database Applications Development, Software Engineering, Consultancy, Data Management, Data Quality, Data Migrations, Reporting, ERP implementations & support, Team/Project/IT Management, etc.