I really like you observation about debugging. The error you see was bad copying from another workspace. Totally botched. My email proof reading skill are totally lacking as well. In general I will get everything I try to do initially wrong and if I don't get something "very wrong" every 30 minutes then I am not doing anything.
-David Leibs On Jun 17, 2012, at 9:49 AM, GrrrWaaa wrote: > > 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 > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
