Minor fixes in 2011/hou/README.md

In particular the 'to use' section had something that should be in the
try section instead.

Line length 'fixes' were made as well.

2011/hou/README.md

@@ -12,25 +12,23 @@ make
 ## To run:
 
 ```sh
-./hou 'a calculator expression -- see the C Code for details'
+./hou 'expression'
-```
-
-More generally:
-
-```sh
-./hou expression
 ```
 
 ## Try:
 
 ```sh
-./hou 11/26+222/31
+./hou '11/26+222/31'
 
 ./hou 'log((21701-19937)-(23209-21701))/log(2)'
 
 ./hou 'sin(1.5708)+0.04321+log(sqrt(exp(1*1*1)))+(1+2*3)-0.4-0.6+(4+6)*(2-1+2*3)-tan(0.785398)+2*10/3*6*sqrt(16/2/2)*10+10000-1000'
+
+./hou 'a calculator expression -- see the C Code for details'
 ```
 
+What does the last one mean?
+
 ## Judges' remarks:
 
 This self-documenting scientific calculator compiles clean with no
@@ -64,20 +62,24 @@ Comments would almost be redundant.  :-}
 
 ### The only multi-byte strings are format strings
 
-The code does not contain some simple string-encoded lookup table for calculator operations.
+The code does not contain some simple string-encoded lookup table for calculator
+operations.
 
 ### Example input and output in the source
 
-The example input and output in the C code is significant.  Can you find out why?
+The example input and output in the C code is significant.  Can you find out
+why?
 
 ### The button layout
 
-The button layout in the C code is significant ... not just a nice looking layout.
+The button layout in the C code is significant ... not just a nice looking
+layout.
 
 ### input parsing
 
-The parser is functionally equivalent to a normal arithmetic parser for all valid inputs.
+The parser is functionally equivalent to a normal arithmetic parser for all
-For another fun challenge: try to determine how it parses the command line argument.
+valid inputs.  For another fun challenge: try to determine how it parses the
+command line argument.
 
 ## Author's remarks:
 
@@ -87,19 +89,21 @@ This program is designed to be self-documenting. It doesn't just provide an
 example command line. It also provides the expected output and illustrates all
 supported functionality using embedded ASCII art.
 
-- A few line numbers are significant and careless beautification will break the program.
+- A few line numbers are significant and careless beautification will break the
+program.
 - The entire ASCII art is valid code. The preprocessor won't remove any part of it.
 - The only strings longer than 1 byte are printf/sscanf format strings, even
-  after preprocessing. No string-encoded lookup table is used.
+after preprocessing. No string-encoded lookup table is used.
-- The example input and its expected output are both algorithmically significant.
+- The example input and its expected output are both algorithmically
+significant.
 - The button layout is also significant.
-- The actual syntax being parsed is not that obvious, despite being
+- The actual syntax being parsed is not that obvious, despite being functionally
-  functionally equivalent for all correct inputs.
+equivalent for all correct inputs.
 
 ### Portability
 
 - This program requires `argv` to point to writable memory. It doesn't require
-  the actual argv strings to be writable, though.
+the actual argv strings to be writable, though.
 - This program requires ASCII.
 - This program doesn't work with `%e` style numbers like `1e-4`.
 - Some seemingly redundant code works to eliminate warnings and evade a gcc bug.