summaryrefslogtreecommitdiff
path: root/info/challenges/aro-bend/answer.004
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /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.004237
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)