home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / ai / neuraln / 3256 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  1.8 KB
  1. Path: sparky!uunet!stanford.edu!ames!lll-winken!tazdevil!henrik
  2. From: henrik@mpci.llnl.gov (Henrik Klagges)
  3. Newsgroups: comp.ai.neural-nets
  4. Subject: Re: Reducing Training time vs Generalisation
  5. Message-ID: <?.714340972@tazdevil>
  6. Date: 20 Aug 92 20:02:52 GMT
  7. References: <Bt9GIx.9In.1@cs.cmu.edu> <arms.714289771@spedden>
  8. Sender: usenet@lll-winken.LLNL.GOV
  9. Lines: 31
  10. Nntp-Posting-Host: tazdevil.llnl.gov
  11.  
  12. arms@cs.UAlberta.CA (Bill Armstrong) writes:
  13.  
  14. >>Sure, but they will have no incentive to do this unless the data, in some
  15. >>sense, forces them to.  You could always throw a narrow Gaussian unit into
  16. >>the net, slide it over between any two training points, and give it an
  17. >>output weight of 10^99.  But it would be wrong.
  18.  
  19. >A good reason not to use such units, eh!
  20. Hm, Bill - this reasonability applies to your example problem as well, which
  21. is pretty much constructed ad hoc. Just add a training point between your 
  22. center - or remove the symmetry otherwise, and your extremum is gone (!).
  23.  
  24. >I seem to recall going over this before, and I believe what is
  25. >required to upset the scheme is to have a lot of training points which
  26. >force training to fit a solution having a peak.  I.e. if six points
  27.  
  28. If there are many points suggesting a peak, than the peak is right. Ever 
  29. did a coupled pendulum experiment and plotted phase lag versus resonance ?
  30. Perfect peaks. Few points, though, to generate/plot them !
  31.  
  32. Concerning lazy evaluation: It is difficult to program on parallel machines.
  33. It is a kind of runtime loadunbalancing that constantly switches off tasks
  34. (=subtree evaluations) of varying size essentially at random. No way to do
  35. that in SIMD, and darn difficult to do it in MIMD at all, and especially not
  36. with a high efficiency.
  37.  
  38.  
  39. Cheers, Henrik
  40. IBM Research Division physics group Munich
  41. massively parallel group at Lawrence Livermore
  42.  
  43.