On Jun 15, 2012, at 12:17 PM, David Leibs wrote: > As children we spend a lot of time practicing adding up numbers. Humans are > very bad at this if you measure making a silly error as bad. Take for example: > > 365 > + 366 > ------ > > this requires you to add 5 & 6, write down 1 and carry 1 to the next column > then add 6, 6, and that carried 1 and write down 2 and carry a 1 to the next > column > finally add 3, 3 and the carried 1 and write down 7 > this gives you 721, oops, the wrong answer. In step 2 I made a totally > dyslexic mistake and should have written down a 3. > > Ken proposed learning to see things a bit differently and remember the > digits are a vector times another vector of powers. > Ken would have you see this as a two step problem with the digits spread out. > > 3 6 5 > + 3 6 6 > ------------ > > Then you just add the digits. Don't think about the carries. > > 3 6 5 > + 3 6 6 > ------------ > 6 12 11 > > > Now we normalize the by dealing with the carry part moving from right to left > in fine APL style. You can almost see the implied loop using residue and > n-residue. > 6 12 11 > 6 13 0 > 7 3 0 > > Ken believed that this two stage technique was much easier for people to get > right.
I'm not sure the argument holds: the answer should be 731. :-) But, to be fair, spreading out the calculation like this makes it easier to debug and find the place where it went awry. Ha - I never thought of that before - writing out proofs in math problems is as much debugging as it is verifying! Maybe programming interfaces could help us debug by more readily showing the 'reasoning' behind a particular value or state, the particular data/control-flows that led to it. Like picking up the program-mesh by holding the result value we are interested in, and seeing the connected inputs draping away to the floor. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
