Re: [fonc] The Web Will Die When OOP Dies
On Jun 16, 2012, at 12:07 PM, Miles Fidelman wrote: Wesley Smith wrote: If things are expanding then they have to get more complex, they encompass more. Aside from intuition, what evidence do you have to back this statement up? I've seen no justification for this statement so far. As I recall, there was a recent Nobel prize that boiled down to: Increase the energy flowing into a system, and new, more complex, behaviors arise. Are you thinking of Prigogine's dissipative structures? Nobel laureate in 1977. http://en.wikipedia.org/wiki/Ilya_Prigogine ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
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
Re: [fonc] The Web Will Die When OOP Dies
Thanks for the link. This thread has had me thinking quite a bit about the Central Limit Theorem from probability. http://en.wikipedia.org/wiki/Central_limit_theorem It explains why so many of our measurements result in normal distributions. -David Leibs On Jun 17, 2012, at 9:36 AM, GrrrWaaa wrote: On Jun 16, 2012, at 12:07 PM, Miles Fidelman wrote: Wesley Smith wrote: If things are expanding then they have to get more complex, they encompass more. Aside from intuition, what evidence do you have to back this statement up? I've seen no justification for this statement so far. As I recall, there was a recent Nobel prize that boiled down to: Increase the energy flowing into a system, and new, more complex, behaviors arise. Are you thinking of Prigogine's dissipative structures? Nobel laureate in 1977. http://en.wikipedia.org/wiki/Ilya_Prigogine ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
GrrrWaaa wrote: On Jun 16, 2012, at 12:07 PM, Miles Fidelman wrote: Wesley Smith wrote: If things are expanding then they have to get more complex, they encompass more. Aside from intuition, what evidence do you have to back this statement up? I've seen no justification for this statement so far. As I recall, there was a recent Nobel prize that boiled down to: Increase the energy flowing into a system, and new, more complex, behaviors arise. Are you thinking of Prigogine's dissipative structures? Nobel laureate in 1977. http://en.wikipedia.org/wiki/Ilya_Prigogine That's the one. Thanks! Miles -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
On Sat, Jun 16, 2012 at 12:18 PM, David Barbour dmbarb...@gmail.com wrote: A valid question might be: how much of this information should be represented in code? How much should instead be heuristically captured by generic machine learning techniques, indeterminate STM solvers, or stability models? I can think of much functionality today for control systems, configurations, UIs, etc. that would be better (more adaptive, reactive, flexible) achieved through generic mechanisms. Sure, there is a minimum number of bits to represent information in the system, but code is a measure of human effort, not information in general. I think you'd be interested in this work, http://wekinator.cs.princeton.edu/ The idea is to build electronic musical instruments by training supervised machine learning algorithms on physical input signals (accelerometers, cameras, etc). The machine learning is pretty naive as I understand, but I think it works because the person training the machine is simultaneously exploring the instrument, training herself to play it. Person and instrument learning how to play each other. You can watch an overview video here, http://www.cs.princeton.edu/~fiebrink/drop/wekinator/WekinatorDemo2.m4v Toby ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
