Happy (personal) fifth MathOverflow anniversary!

(Kevin Buzzard is partly to blame for my participation; his sci.math.research posting first made me aware of the MathOverflow forum.)

In celebration of MathOverflow’s fifth anniversary, I have a post on meta.mathoverflow.net which answers the question “How is MathOverflow useful to me?”, and I would expand on both the answer and the question now.

A brief recap of my posted answer: MathOverflow allows me to express that part of me which enjoys mathematics and sharing mathematics. It gives me the benefits of academia that I enjoyed as a graduate student, which I see as access to the thoughts and opinions of a select and like-minded group of people as well as the ability to contribute, while avoiding the major disadvantages of academia, which for me appear to involve politics and the pressures to perform associated and distracting administrative tasks.

I would expand the question to ask how MathOverflow can be useful to me and to others. Here are some of my ideas and observations.

MathOverflow serves as an online forum where (often) specific questions are asked and specific and relevant answers to these questions are given. Other things also happen on this forum and associated fora (chat and meta versions), some of which are useful side effects:

• collaboration on existing research questions,
• hyperlinked references to useful material,
• some discussion,
• some automated cross-referencing,
• some crowdsourcing requests,
• some new research questions are asked,
• some insights and suggestions for understanding arise.

I think the following are related to and can be derived from the current efforts at MathOverflow:

• making an archive version of some of the database
• creating a public directory of those wishing an online presence that reflects and enhances their real-life interests in mathematics
• allowing the creation of several templates for collaborative efforts, such as proof-wikis, tackling research problems, documenting the current and future historical development of disciplines of mathematics as well as past development.

I also think that certain efforts outside of MathOverflow can benefit from the work being done on the forum. In particular, encouraging and influencing the development of the WDML (World Digital Mathematics Library), helping people in developing countries with their mathematical efforts by showing them how to create localized (language-specific) versions of MathOverflow, and development of applications to facilitate various kinds of computation on low and intermediate levels and make them available to many. Further, I believe MathOverflow heralds the development of online resources to accompany and perhaps surpass upon current graduate level textbooks, improving their breadth and accessibility.

It is presently beyond the basic mission of MathOverflow to attempt any of the above efforts under its umbrella. I would instead suggest various project proposals for public consideration and I shall create some “Internet space” for development and small-scale implementation of some of these proposals. Serious inquiries can be directed to an email address found on my MathOverflow user page; a link to this page is at the meta post above.

Transcriptions IV

Templates. It is good to find a useful pattern, which can be successfully repeated. Template design should come after some experience in using the pattern you wish to copy. It is often desired to make templates out of durable material. Laminated sheets, metal versions of wood fabrications and saved (on a read only disk) files are such examples.

Macros are a special example of template. In preparing text-based systems, there is a program that will do pattern replacement. One can then make special words which are abbreviations of longer phrases or concepts. Some macros are modifiable, so that if you provide the abbreviation and some special text, the resulting substitution contains the special text.

Macro design and usage is nontrivial. One needs to see if the pattern occurs often enough that it is worth creating a macro for it. One also has to consider if the pattern will be useful in all the places it presently occurs.

0128

Power tools. Once one has experience designing systems one can start using/making tools to design systems faster/better. When one has used/made some tools, one looks for power tools.

Power tools relieve one of the drudgery and tedium associated with certain tasks. Pneumatic hammers, drill presses, mold making machines, tunnel builders are some progressively complex power tools for physical manufacture. Include files, abstract data types, object classes, automated design tools, are some similar examples in the software domain.

Power tools often need training and discipline to use. Because they do so much so fast, it is easy to use them in the wrong way, sometimes with harmful consequences. One can build more complex systems with power tools, but a lack of understanding of how the tool (and the system it helps to create) will affect the environment, such a lack can lead to failure, even death.

Thus, power tools, and even tools, (and even systems) should not be used willy-nilly. Experience and guidance are suggested in learning and using even the simplest of systems.

0129

Connections. Usually a system is designed as a collection of components which bear some relations to one another. Often this relation is called a connection. It represents a point of contact, or something being shared.

In many cases, the connections deserve as much design considerations as the components. Care must be taken in specifying the connection as it will often determine bottlenecks in future performance of the system.

Connections often indicate flow of material or information. The flow can be multi- or single-directional. If there is need for more of a commodity to flow, the connection is sometimes drawn at a size roughly proportional to the size of the flow.

THe flow can be highly specialized. Thus components will be designed with certain specifications in regard to the “shape” of the connection. Interface files in C programming are one such example.

Connections can also be physical as in forces on members of a truss.

0130

Transcriptions, III

Communication. In designing systems for others you need to make your intentions for usage known. This is sometimes called documenting the system.

You should write documentation with one target audience in mind. Then review the documentation with an eye toward rewriting it for a less savvy audience.

It is useful to write something like a theory of operation section, which gives the user some notion of what the system does and why he/she would want it to do that. Then, technical details of how can follow.

One also should consider that no one reads the documentation. Thus, appropriate blurbs should be used. (Don’t put remaining hand in grinder.) Further, the design should consider making the documentation simpler.

0109

Constraints. They can be a good thing. In designing a system, limiting ones choices can focus the development of the design, and allow it to go more quickly. Indeed, given enough carefully chosen constraints, very few design possibilities result, and the system comes together like putting a jigsaw puzzle together.

It is good to know where constraints come from, and why. Many result from user requirements, some from the capabilities of the components, some from economic consideration. Whatever the source, it helps to know if a constraint can be removed, or relaxed. This is especially important when there are too many constraints, i.e. the limitations make it unlikely to produce a result satisfying all of the limits. It is not expected to build an ice cube maker, that, under normal conditions, produces ice cubes that are cube-shaped and warm to the touch, i.e. should be both below and above 50 degrees F at the same time.

0110

Maintenance. How long does your system last?

For systems with physical components, it is easy to think of such systems needing occasional repair and maintenance. If well designed, such repair can be done quickly and easily. However, complex nonphysical systems
also need maintenance. A common type of example is a data storage system. In order to use less space, data may be reorganized and rearranged and rerepresented. In software, garbage collection is a type of routine used in
memory management. Systems also need updates and improving to keep up with changing demand. Thus, flexible systems can accommodate redesign and adaptations. Certain government codicils allow for such amendments.

0112

Transcriptions II

Perspective. I stand over someone, my head 2 feet above theirs. I point to something in some bushes at my eye level. Can the other person see it?

A lot of interesting things can happen because of differences, even minor differences, in points of view. Arguments can start, ideas discovered, new systems invented. In doing a system design, some changes in perspective can be quite useful. In doing usability studies, some system designers use and watch users use the prototypes, in order to improve the performance of the system under conditions in the field. By viewing a particular problem in more than one way, the solution becomes clear.

A classic example: Plant 10 trees in 5 rows of 4 trees each. One can look at this from the perspective of 10 trees. It becomes clear that the 5 rows can’t all be parallel and so one starts placing 10 trees in various arrangements. It can take some time to arrange these trees to get 5 rows with 4 trees in each row.

Now comes the change in perspective: Instead of placing trees, try placing rows. Since some rows will intersect, you can start by choosing 5 lines, no 2 of which are parallel. When you do this, you will find the 10 points of intersection satisfy the desired conditions. Instead of hunting around for a placement of points, any line placement works.

0106

Delegate. In dealing with large systems, it helps to forget some details, at least temporarily.

Two methods take advantage of this forgetfulness. Designing from the top down involves representing the components of the system by blocks and requirements and interrelations between the blocks, and then considering each block as a system to be designed to fit the previous requirements and interrelations. If necessary, each block can itself be broken into smaller blocks and interrelations.

The second method involves recognizing a set of primitive components, each of which can be easily designed and implemented, and then forgetting the implementation of the components and combining them in interesting ways to form larger systems.

0107

What is success? The system you make should meet some goal, and in some cases you need to demonstrate the goal is being achieved, at least in part. So what do you do?

One strategy is design-to-test. This strategy says to create components that allow you to measure, or test, parts of the system to establish yes/no answers related to the system goals.

One such goal is reliability. Given the same conditions or stimuli, will the system give the same response? Will the system respond the same way even under environmental extremes? What limits will the system endure, or start to malfunction?

Other tests are diagnostics. If the system fails a certain test, does the failure indicate what portions need repair/replacing?

Some systems are transparent enough that all required tests can be performed externally, without the need for components specific for testing. Black box design does require at times a design-for-test philosophy.

0108

Get ready, get set, …

I feel the need for another preface. The next set of postings are lightly edited transcriptions from notes made some years ago. They may seem like disjointed topics grouped together; they should be considered as kernels for larger essays to be developed. One intent is to be provocative: I want you to think critically about the subject and find something to add or subtract from it. The notes will be posted with a title like “Transcriptions” here. I will also include some numbers for my temporary reference. When the sdfae domains are configured, the posts will be rearranged and expanded to accommodate other goals.

I thank you for waiting and storing your feedback to give when the proper mechanisms are in place. Your patience is appreciated and I will reward it.

… go! Transcriptions I

I will show you several ways of thinking. The different ways serve different goals (masters?) and are not always compatible (agreeable?) . However, with practice, you can employ combinations of them to great effect. System Design should not be pinned down to a single philosophy or frame of reference. System Design also should not be a static collection of principles, heuristics, and rules-of-thumb. System Design should be fluid, personalized, and grow and change as you see fit. What is presented here should serve as a catalyst, prototype, and laboratory. Even if you do not create a system for yourself or others, System Design can aid your comprehension of other systems.

There are various methods by which you can acquire the skills presented here, but only two things can guarantee success: thinking about the material, and its relations to your experience; and practicing the concepts. Reading and memorizing without comprehending will not work.

0101

What is a system? Pretty much, it is what I say it is. I will not define it for you, but I will describe some of it. A system is sometimes some arrangement of stuff that, in some sense, does something. Many things in life are systems. Some that show signs of man-made construction are philosophies, religions, governments, plans, buildings, betting protocols, recipes, algorithms for sorting, desserts, piles of paper, a book, many manufactured items, a bill of lading, receipts, notations. There are systems that are not made by man, but have some arrangement or classification imposed on them, such as sedimentation, cell structure, anatomy, life cycles, chemical reactions, crystalline arrangements, and so on. Even things that have no pattern or clear arrangement can be considered systems, such as weather, and other physical processes. Many systems involve more than one things, but not all systems. My untidy desk is a system. Someone’s scrapbook is a system. Someone else’s family tree is a system. Many of these systems will reveal, through scrutiny, how they were designed. Or, how they can be designed again.

0102

Language is important. In attempting to convey meaning, people will set up a context, and then use abbreviations and other devices to aid in delivering information quickly, or reliably. Repetition, use of pronouns, social conventions, all of these are used in our communications. One can use or tweak this to adjust the intent, causing double entendre, ambiguity, even humour. One can also apply contexts other than that of the source to derive a different meaning. Let me set up some context that will be used later.

Being a literalist, I take the phrase “all bears” to mean the totality of all objects such that each such object can be considered a bear, without qualifications. Thus, if not specified or otherwise modified, “all bears” refers to living and dead bears, mythical and teddy, polar and grizzly, bears that were, are, and shall be, and excludes many things, such as bookmarks or political statements. “Most bears” refers to a large subcollection of “all bears”, such subcollection usually being a majority. I use “many bears” and “some bears” to refer to a collection of bears which usually has 2 or more bears. “No bears” refers to an empty subcollection. I intend to avoid absolute statements, except in controlled circumstances.

0103

The Joy of Beginning

I had the following pattern: I would get a diary, or a small planner, or some notebook with dates, and I would get it on or before New Years Day of the year that was stenciled on the outside of the diary/planner/notebook. I would write in it some notes that happened that January first of that year, and intend to write daily notes to journal some aspect of my life.

Many times this desire to journal tapered off within a few days, and I would be left with a journal of mostly blank pages. Sometimes it would take a whole week before I stopped my intense writing for the year. It might be the odd occasion when I would go back to that
to add some note or thought, but mostly I have a scattered collection of such small books which record my New Years resolve and its short-life.

There were a few times in my life when the resolve lasted for more than a month. One was when I decided to write various letters at the rate of one per day to parents, friends, acquaintances new and old. I still have that snapshot of that part of my life to substitute for a journal.

Another was when I decided to start this project. Elsewhere you will read of the events behind the inspiration for sdfae; one of them was writing material on a nightly basis for this endeavour, come what may. That year my resolve carried me for almost five months, up to and a little past the day when my mother died.

The enthusiasm for the project waned a bit, but it was always present. However, I stopped writing, and the material lay dormant for a few years. Even though I felt its importance, I shifted my focus to other matters, including moving my family.

There was a reason for the pattern, and I believe the reason was the joy of beginning. There is excitement, anticipation, some delight in the prospects of the future, and perhaps some nervous enjoyment of the unknown. One of the joys of system design is the joy of the beginning: each time you sit down to plan something new, the universe is yours to command, the potentials unlimited, the discoveries await, and the thrills yours to use as reward and motivation. I am excited at this beginning of sharing my thoughts on System Design For Almost Everyone. May you also experience the Joy of Beginning.

Copyright 2014 sdfae and Sheperd Systems