<div dir="ltr"><div>Hi,<br></div><div><br></div><div>In my printing of METAFONT: The Program (eighth printing, Nov 2017), section 214 ("Token lists") describes the five ways to encode tokens internally.  The first one says: "A symbolic token whose hash code is p is represented by the number p, in the info field of a single-word node in mem".  I believe this should say "whose hash ADDRESS is p", i.e. the location p such that text(p) is the string representation of the symbolic token.</div><div><br></div><div>Two tokens can of course have the same hash code (as defined in section 208, "Compute the hash code h").  For instance "ba" and "ac" both have hash code 2*"b"+"a" = 2*"a"+"c" = 293, but they would be represented by different locations in the hash & eqtb arrays: clearly, METAFONT does not get confused by the definition "def tricky = ba+ac enddef".  Later sections, such as section 229, indeed use the term "hash address" instead of "hash code" for this reason.</div><div><br></div><div><br></div><div>Separately, I had to carefully study the definitions of print_scaled in TeX (section 103) and METAFONT (section 103: what a coincidence!) to understand their differences.  The intended functional difference is that METAFONT tries to print integer scaled values such as 42 as "42", whereas TeX happily prints them as "42.0".  However, there is a second difference, where the statement that "rounds the last digit" is "s := s + '100000 - (delta div 2)" in METAFONT, but is "s := s + '100000 - 50000" in TeX.  Both are equivalent, of course, since this statement is only invoked when "delta > unity"; in successive iterations, delta is 10, 100, 1000, 10,000 and 100,000, and it is when delta is 100,000 that it finally exceeds unity = 2^16 = 65536.  But I found it confusing why the two programs express this operation differently.  If the constant '100000 were changed to "half_unity" in METAFONT, then the procedure text would be both more readable and completely general for any values of half_unity and unity that are successive powers of 2, as long as the type of "scaled" was sufficiently wide.  Conversely, if (delta div 2) were replaced by 50000 in METAFONT, the code might run a little faster (loop unrolling seems unlikely to detect that (delta div 2) is only ever calculated when it is equal to 50000).  But why the inconsistency between TeX and METAFONT?  I realize this is more of a stylistic issue than a "bug", but Knuth pays such meticulous attention to detail that this inconsistency seems accidental.</div><div><br></div><div><br></div><div></div><div>In both cases, I checked the latest errata at <a href="https://www-cs-faculty.stanford.edu/~knuth/abcde-errata.pdf">https://www-cs-faculty.stanford.edu/~knuth/abcde-errata.pdf</a> and did not find anything relating to the issues above (especially the first one).</div><div><br></div><div>Thank you in advance for giving these reports your careful consideration.</div><div><br></div><div>All the best,</div><div><br></div><div>Patrick Varilly<br></div></div>