diff options
author | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
commit | e0c6872cf40896c7be36b11dcc744620f10adf1d (patch) | |
tree | 60335e10d2f4354b0674ec22d7b53f0f8abee672 /info/challenges/aro-bend/answer.004 |
Initial commit
Diffstat (limited to 'info/challenges/aro-bend/answer.004')
-rw-r--r-- | info/challenges/aro-bend/answer.004 | 237 |
1 files changed, 237 insertions, 0 deletions
diff --git a/info/challenges/aro-bend/answer.004 b/info/challenges/aro-bend/answer.004 new file mode 100644 index 0000000000..2680fcab7c --- /dev/null +++ b/info/challenges/aro-bend/answer.004 @@ -0,0 +1,237 @@ +[Solutions for exercises 4,5 were originally posted together on 5 Dec 91] +Date: Thu 5 Dec 91 10:26:58-EST +From: Michael Downes <MJD@MATH.AMS.COM> +Subject: `Around the bend' #2 solutions (4,5) +To: info-tex@shsu.edu + +Answers to exercises 4 and 5 of `Around the bend' #2. Discussion of E6 +will follow in a separate post because it is rather lengthy. Discussion +of E7 will follow in another couple of weeks (I'm going to be on +vacation next week.) + +"*********************************************************************** +"*** Exercise 4 (essay): +" +"What should `best' mean when comparing solutions to an `Around the +"bend' exercise? What qualities of a good solution are most important? +"Why? How can they be objectively measured? (Or can they?) On the +"negative side, what qualities indicate an inferior solution? + +Peter Schmitt writes: + +> What is to be rated as `best' clearly depends on the function used to +> measure quality. And therefore the question makes sense only with +> respect to some particular rating function. Seemingly nothing is gained +> by this statement: Instead of discussing what qualities are required +> for a good solution one has to discuss how the rating system should be +> defined. But nevertheless this shifted point of view has an important +> an important advantage. It makes clear that there is no unique answer: +> Quality is not an absolute notion but a notion relative to some +> (agreed) measure. This measure is not independent of the context --- +> under different conditions different rating functions may be used. + +> One further important point must not be forgotten: If matters of +> personal taste are to be excluded than the measuring function has to be +> precisely defined --- demanding simplicity, without giving this notion +> a precise (formal) meaning, is not sufficient. +> +> Therefore I would like to split the original question into two seperate +> questions: +> +> (a) What (formal and informal) rating functions are likely to be +> useful, and under what circumstances? +> +> (b) With respect to some formal rating function, is there always a best +> solution? +> +> Some answers to the first questions are the following (no completeness +> claimed or even intended): +> +> (1) the first solution: +> +> If some special effect is needed for a single application then the +> best solution is the first solution (the solution that can be +> realized with the least effort). This is, however, a purely +> individual criterion that cannot be formalized. +> +> (2) the most economic (in some sense) solution: +> +> Economic considerations are important if a code is used frequently, +> Depending on the nature of the applications running time, memory +> usage, and others, may be relevant. But the time spent for finding +> a good solution still cannot be neglected in a real world +> situation. Of course, for theoretical investigations the time spent +> for research does not matter. +> +> (3) the more robust solution: +> +> If some set of macros is used by a large number of people who not +> always know how to use them correctly (or even do not care to know) +> then it is certainly an advantage if they are robust, i.e. work in +> as many cases (even strange ones) as possible. But again, one has +> to decide what price (in terms of resources) is acceptable for this +> robustness. (In many cases the item (4) below will be more +> important.) +> +> (4) ease-of-use: +> +> If a set of macros is used frequently (by one or more persons) then +> ease-of-use is certainly a mark of quality: easy to remember +> syntax, short commands, natural and good readable embedding into +> the surrounding text, and similar criteria, decide about this. +> +> (5) simplicity: +> +> Simple solutions certainly have a strong appeal --- but what is a +> simple solution? Again this is hard to formalize, since simplicity +> basically is an aesthetic value, closely related to the concepts of +> elegance and beauty. (This is similar to the situation in +> mathematics.) But be careful: Simple is not equivalent to short! +> +> (6) the shortest solution: +> +> This may seem to be an easy rating function, but is it? Should +> length be measured by the number of characters (probably not!), or +> by the number of tokens, or by the number of control sequences? Or +> by something else? +> +> Most of the measures mentioned are difficult to formalize, or cannot be +> formalized at all. Only the resources used (in (2)) and the length of a +> code (in (6)) can be precisely defined. Therefore, with respect to one +> of these cases two solutions of the same problem can be compared. +> Furthermore, in many cases it will be possible to proof that an optimal +> solution exists. (For instance, since the length of a code (in any +> interpretation) is a positive integer, there must exist one or more +> solutions with minimal length, provided there is at least one +> solution.) But unfortunately this does not imply that one is able to +> construct an optimal solution, or to decide whether a given piece of +> code is an optimal solution (or at least near to one). And in some +> cases it may happen that no optimal solution exists, e.g. if to every +> solution there is better --- but longer! --- one. +> +> What is the conclusion of all this? That there may be a best solution +> relative to some side conditions. But that there is no globally best +> solution. This statement is, of course, not very satisfying. One +> would rather prefer to have at least some notion (even a tentative one) +> of a best solution than none at all. I propose therefore the following +> informal definition (often subject to personal taste): If some code is +> optimal or near-optimal in more than one category then it is probably +> as near to a globally optimal solution as this is possible. + +My comments: + +I propose the following list, based on (1) [my interpretation of] +Knuth's ideas about good macro writing as demonstrated in the TeXbook +and plain.tex, (2) various articles in TUGboat, (3) Schmitt's comments, +(4) discussions I've had in the past with other macro writers, and so +forth. + +The characteristics of a good solution to an `Around the bend' exercise +are (in order of decreasing importance): + +1. Robustness +2. Brevity (= minimal usage of TeX's main memory) +3. Simplicity +4. Ease of use +5. Suitable commentary +6. Speed +7. Minimal hash table load +8. Minimal save stack load +9. Minimal load in other categories of TeX's memory +10. Comprehensive test suite (when applicable) + +Schmitt's point about 'first solution' is well taken but does not apply +to `Around the bend' exercises, because of the stated goal of finding a +'best' solution, with the presumption that normally more than one +solution will be found. + +Measurement of these qualities is not too difficult, I think, +except for 3 and 5. Here's how I see the measurements: + +1. Robustness: A solution is robust if no one who reads it offers a +counterexample that causes it to fail. If two solutions both fail, the +one with more counterexamples is less robust; if two solutions have +different counterexamples, the solution whose counterexample is more +likely to occur in normal use is the less robust solution. + +2. Brevity: Of two different solutions, the one that is +briefer/shorter/more compact is the one that uses less of TeX's main +memory as measured by \tracingstats. + +3. Simplicity: Of two different solutions, the shorter one (in the +sense of the previous item) is usually the simpler one, but not always. +A solution that condenses all the necessary operations into a dense, +incomprehensible Gordian knot is less simple than a longer solution +that lays out the operations in a series of easily comprehended steps. +A solution that relies on arcane dirty tricks is less simple than a +solution that uses better-known techniques in a straightforward +approach. + +4. Ease of use: I believe this will not be extremely hard to measure in +the context of the particular application; it can't sensibly be +discussed out of context. + +5. Suitable commentary: The commentary surrounding a solution should +explicitly mention any necessary assumptions. If the code is complex, +the commentary should give an outline or overview of the intended +algorithm. It should explain the operation of any macro if its +operation is not evident from the code. If an unusual construction is +used where a different construction would normally be expected, the +commentary should give the reason. + +6. Speed: Of two solutions, the speedier one is the one that runs +faster on common computer systems. If one solution runs faster and +slower than another, depending on the system ... well, let's not cross +that bridge unless it turns out to be real. + +7,8,9. Minimal hash table load, save stack load, etc. These can be +measured by \tracingstats. + +10. Comprehensive test suite: If two solutions are equal in other +respects, the one whose accompanying test suite covers more distinct +cases than the other's is better by that much. + +It may be argued that I have not sufficiently answered the question of +subjectivity. For example, who's to decide what's an 'arcane dirty +trick' and what's not? What does 'suitable' mean in number 5? The +answer is that I will say that something is an 'arcane dirty trick' if +I think so, and anyone else can do the same. In most cases I believe +that there will be general agreement on such a question; if not, and an +ensuing discussion fails to reach a clear settlement, then each of the +solutions in question will be decreed 'subjectively just as good as the +others'. + +Other qualities of a good solution can be expressed in terms of the +ones listed above. For example, self-sufficiency may be considered an +aspect of robustness---if a solution is not entirely self-sufficient, +it can easily be shown to be not robust by giving a counterexample that +exploits the assumption that makes the solution non-self-sufficient. +Elegance? If a solution is simple and easy to use, then I say it is +elegant. A solution doesn't necessarily have to be robust in order to +be elegant, nor even short (although of two solutions that are +otherwise equal, the shorter one is undoubtedly more elegant). + +[Solution for exercise 5 moved to answer.005] + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +Table of special characters (ASCII): + +33: ! exclamation point; 59: ; semicolon; +34: " double quote; 60: < left elbow; +35: # number/pound sign; 61: = equals sign; +36: $ dollar sign; 62: > right elbow; +37: % percent sign; 63: ? question mark; +38: & ampersand; 64: @ at sign; +39: ' right quote/apostrophe; 91: [ left square bracket; +40: ( left parenthesis; 92: \ backslash; +41: ) right parenthesis; 93: ] right square bracket; +42: * star/asterisk; 94: ^ circumflex/hat/caret; +43: + plus sign; 95: _ underscore; +44: , comma; 96: ` left quote; +45: - hyphen; 123: { left curly brace; +46: . period/dot/point; 124: | vert bar; +47: / slash; 125: } right curly brace; +58: : colon; 126: ~ tilde + +Michael Downes mjd@math.ams.com (Internet) |