From Allan.Randall at drdc-rddc.gc.ca Wed Oct 4 10:49:15 2006 From: Allan.Randall at drdc-rddc.gc.ca (Randall, Allan (Contractor)) Date: Wed Oct 4 10:49:22 2006 Subject: [pdp-discuss] Separating the core leabra engine from everything else... Message-ID: <88901B46A33C2F46A4D5C0B186A8C9C5010B94D4@torontoex01.toronto.drdc-rddc.gc.ca> This is, at this time, a very general question rather than a specific technical one. I am wondering about the feasibility of taking just the core leabra++ code that my completed and tested network makes use of, and separating it from the rest, including the GUI and so on that is intended for development--basically anything I am not making use of--and incorporating it into some other C++ program. The goal here would be to extract just a small, compact piece of code to do just the job that I want. Has this sort of thing been done successfully, or is the core algorithm too intertwined with the GUI and so on to make this feasible? Any thoughts? In principle, I would think that if PDP++ was written using proper object-oriented design principles, then this sort of thing should be reasonably trivial, but I recognize that in reality things might be more complicated. (I don't actually have a completed, tested network that I wish to do this with right now... just interested in how flexible the PDP++ software is, in case I might want to do it in the future.) Allan -- Allan Randall, Allan.Randall@drdc-rddc.gc.ca "According to the union within each person of disparate body parts, thus does mind emerge in humans. For it is the composition of body parts which does the thinking." -- Parmenides of Elea, c. 475 B.C. From Randy.OReilly at colorado.edu Wed Oct 4 11:38:18 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Wed Oct 4 11:38:21 2006 Subject: [pdp-discuss] Separating the core leabra engine from everything else... In-Reply-To: <88901B46A33C2F46A4D5C0B186A8C9C5010B94D4@torontoex01.toronto.drdc-rddc.gc.ca> References: <88901B46A33C2F46A4D5C0B186A8C9C5010B94D4@torontoex01.toronto.drdc-rddc.gc.ca> Message-ID: <200610041138.18996.Randy.OReilly@colorado.edu> it is possible -- check out demo/bench/pdp++bench for an example where we setup some "dummy" base classes and then compiled only slightly modified bp++ code on top of that. This should be possible to do with leabra. In the new version, 4.0, there is a NO_GUI define that we are trying to obey, but this is not a high priority.. the biggest challenge is the loading/saving of files -- that depends on core code that is not easily extracted. - Randy On Wednesday 04 October 2006 10:49, Randall, Allan (Contractor) wrote: > This is, at this time, a very general question rather than a specific > technical one. I am wondering about the feasibility of taking just the core > leabra++ code that my completed and tested network makes use of, and > separating it from the rest, including the GUI and so on that is intended > for development--basically anything I am not making use of--and > incorporating it into some other C++ program. The goal here would be to > extract just a small, compact piece of code to do just the job that I want. > Has this sort of thing been done successfully, or is the core algorithm too > intertwined with the GUI and so on to make this feasible? Any thoughts? In > principle, I would think that if PDP++ was written using proper > object-oriented design principles, then this sort of thing should be > reasonably trivial, but I recognize that in reality things might be more > complicated. > > (I don't actually have a completed, tested network that I wish to do this > with right now... just interested in how flexible the PDP++ software is, in > case I might want to do it in the future.) > > Allan > > -- > Allan Randall, Allan.Randall@drdc-rddc.gc.ca > > "According to the union within each person of disparate body parts, thus > does mind emerge in humans. For it is the composition of body parts which > does the thinking." -- Parmenides of Elea, c. 475 B.C. > > > _______________________________________________ > PDP-Discuss mailing list > PDP-Discuss@psych.Colorado.EDU > http://psych.colorado.edu/mailman/listinfo/pdp-discuss From Allan.Randall at drdc-rddc.gc.ca Thu Oct 5 14:31:06 2006 From: Allan.Randall at drdc-rddc.gc.ca (Randall, Allan (Contractor)) Date: Thu Oct 5 14:32:40 2006 Subject: [pdp-discuss] Separating the core leabra engine from everything else... Message-ID: <88901B46A33C2F46A4D5C0B186A8C9C5010B94DC@torontoex01.toronto.drdc-rddc.gc.ca> Randy, thanks for the tips! Allan -- Allan Randall, Allan.Randall@drdc-rddc.gc.ca "According to the union within each person of disparate body parts, thus does mind emerge in humans. For it is the composition of body parts which does the thinking." -- Parmenides of Elea, c. 475 B.C. -----Original Message----- From: Randall C. O'Reilly [mailto:Randy.OReilly@colorado.edu] Sent: Wed 10/4/2006 1:38 PM To: pdp-discuss@psych.colorado.edu Cc: Randall, Allan (Contractor) Subject: Re: [pdp-discuss] Separating the core leabra engine from everything else... it is possible -- check out demo/bench/pdp++bench for an example where we setup some "dummy" base classes and then compiled only slightly modified bp++ code on top of that. This should be possible to do with leabra. In the new version, 4.0, there is a NO_GUI define that we are trying to obey, but this is not a high priority.. the biggest challenge is the loading/saving of files -- that depends on core code that is not easily extracted. - Randy On Wednesday 04 October 2006 10:49, Randall, Allan (Contractor) wrote: > This is, at this time, a very general question rather than a specific > technical one. I am wondering about the feasibility of taking just the core > leabra++ code that my completed and tested network makes use of, and > separating it from the rest, including the GUI and so on that is intended > for development--basically anything I am not making use of--and > incorporating it into some other C++ program. The goal here would be to > extract just a small, compact piece of code to do just the job that I want. > Has this sort of thing been done successfully, or is the core algorithm too > intertwined with the GUI and so on to make this feasible? Any thoughts? In > principle, I would think that if PDP++ was written using proper > object-oriented design principles, then this sort of thing should be > reasonably trivial, but I recognize that in reality things might be more > complicated. > > (I don't actually have a completed, tested network that I wish to do this > with right now... just interested in how flexible the PDP++ software is, in > case I might want to do it in the future.) > > Allan > > -- > Allan Randall, Allan.Randall@drdc-rddc.gc.ca > > "According to the union within each person of disparate body parts, thus > does mind emerge in humans. For it is the composition of body parts which > does the thinking." -- Parmenides of Elea, c. 475 B.C. > > > _______________________________________________ > PDP-Discuss mailing list > PDP-Discuss@psych.Colorado.EDU > http://psych.colorado.edu/mailman/listinfo/pdp-discuss From Allan.Randall at drdc-rddc.gc.ca Thu Oct 5 14:38:06 2006 From: Allan.Randall at drdc-rddc.gc.ca (Randall, Allan (Contractor)) Date: Thu Oct 5 14:38:11 2006 Subject: [pdp-discuss] Stat for detecting oscillation? Message-ID: <88901B46A33C2F46A4D5C0B186A8C9C5010B94DD@torontoex01.toronto.drdc-rddc.gc.ca> Sometimes my networks go into wild oscillations, which is easy to spot when watching them, but I'd like to detect this in batch mode and use it as a stopping criterion. Anyone know if there is a stat already in PDP++ that is good for detecting this kind of behaviour? Allan -- Allan Randall, Allan.Randall@drdc-rddc.gc.ca "According to the union within each person of disparate body parts, thus does mind emerge in humans. For it is the composition of body parts which does the thinking." -- Parmenides of Elea, c. 475 B.C. From Randy.OReilly at colorado.edu Sat Oct 7 12:47:55 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Sat Oct 7 12:47:59 2006 Subject: [pdp-discuss] Stat for detecting oscillation? In-Reply-To: <88901B46A33C2F46A4D5C0B186A8C9C5010B94DD@torontoex01.toronto.drdc-rddc.gc.ca> References: <88901B46A33C2F46A4D5C0B186A8C9C5010B94DD@torontoex01.toronto.drdc-rddc.gc.ca> Message-ID: <200610071247.56626.Randy.OReilly@colorado.edu> Assuming you're talking about Leabra -- doesn't exist yet to my knowledge -- recording the unit da value will pick that up -- it gets much bigger during oscillation. - Randy On Thursday 05 October 2006 14:38, Randall, Allan (Contractor) wrote: > Sometimes my networks go into wild oscillations, which is easy to spot when > watching them, but I'd like to detect this in batch mode and use it as a > stopping criterion. Anyone know if there is a stat already in PDP++ that is > good for detecting this kind of behaviour? > > Allan > > -- > Allan Randall, Allan.Randall@drdc-rddc.gc.ca > > "According to the union within each person of disparate body parts, thus > does mind emerge in humans. For it is the composition of body parts which > does the thinking." -- Parmenides of Elea, c. 475 B.C. > > > _______________________________________________ > PDP-Discuss mailing list > PDP-Discuss@psych.Colorado.EDU > http://psych.colorado.edu/mailman/listinfo/pdp-discuss From dickjr at gmail.com Mon Oct 9 08:23:11 2006 From: dickjr at gmail.com (Richard Jones) Date: Mon Oct 9 08:23:15 2006 Subject: [pdp-discuss] pdp++ 4.0 Message-ID: <381eb1660610090723v5f32044fpaf4bb29ef9521df@mail.gmail.com> Dr. O'Reilly mentioned this in a recent post. Is there a feature list or ETA available yet? -- Richard Jones dickjr@gmail.com From baisa at colorado.edu Mon Oct 9 10:42:24 2006 From: baisa at colorado.edu (Brad Aisa) Date: Mon Oct 9 10:42:27 2006 Subject: [pdp-discuss] pdp++ 4.0 In-Reply-To: <381eb1660610090723v5f32044fpaf4bb29ef9521df@mail.gmail.com> References: <381eb1660610090723v5f32044fpaf4bb29ef9521df@mail.gmail.com> Message-ID: <200610091042.24399.baisa@colorado.edu> We are shooting for a preliminary internal alpha release circa end of Oct or so. Based on our current list of things to do, it seems that a public beta release will occur more towards the end of this year. We'll put up a list of changes and new features Real Soon Now. ;) On Monday 09 October 2006 08:23, Richard Jones wrote: > Dr. O'Reilly mentioned this in a recent post. Is there a > feature list or ETA available yet? -- Brad Aisa Professional Research Assistant Department of Psychology University of Colorado - Boulder From dickjr at gmail.com Thu Oct 12 15:45:50 2006 From: dickjr at gmail.com (Richard Jones) Date: Thu Oct 12 15:45:56 2006 Subject: [pdp-discuss] ta-iv question Message-ID: <381eb1660610121445u3a8733dbl554ad9e6ccece4b0@mail.gmail.com> I'd like to try implementing my own learning algorithm, using the bp code as a starting point. I've built the latest pdp++ and got it hooked up in my debugger, and have stepped through the code for all the interesting parts. For yucks, I added a new float data member to the BpConSpec class in "bp.h". It showed up in the "bp_TA.cc" file after make_ta, and everything compiled and ran. As I was building a new network in the app, however, I tried to edit the BpConSpec to see if my new field was there, and it all ground to a halt. I suspect I must tell some part of IV about my new data member so it can build the editor window correctly, but I'm not sure how. Can someone point me in the right direction? I've included the stack trace below my signature. Many thanks. -- Richard Jones dickjr@gmail.com #0 0x0033b41d in taString::length (this=0x10) at /usr/local/pdp++/include/DARWIN/ta_string/ta_string.h:470 #1 0x0034cbf5 in cat () at /usr/local/pdp++/src/ta_string/ta_string.cc:1187 #2 0x0034cc7a in operator+ () at /usr/local/pdp++/src/ta_string/ta_string.cc:1187 #3 0x002b9337 in gpivListEditButton::SetLabel (this=0x51d67c0) at /usr/local/pdp++/src/ta/ta_group_iv.cc:87 #4 0x0029a8dc in taivEditButton::GetImage (this=0x51d67c0, base=0x51678ec, win=0x0) at /usr/local/pdp++/src/ta/taiv_data.cc:1987 #5 0x002c3528 in gpivListType::GetImage (this=0x4dedc40, dat=0x51d67c0, base=0x51678ec, win=0x0) at /usr/local/pdp++/src/ta/ta_group_iv.cc:1689 #6 0x002b26ae in taivMember::GetImage (this=0x4f1cd90, dat=0x51d67c0, base=0x51677f0, win=0x0) at /usr/local/pdp++/src/ta/taiv_type.cc:451 #7 0x000635e6 in taivSpecMember::GetImage (this=0x4f1cdb0, dat=0x51d67c0, base=0x51677f0, win=0x0) at /usr/local/pdp++/src/pdp/pdp_iv.cc:122 #8 0x002af0e1 in taivEditDialog::GetImage_impl (this=0x51a45f0, ms=@0x45bc50, dl=@0x51a4684, base=0x51677f0, win=0x0) at /usr/local/pdp++/src/ta/taiv_dialog.cc:1299 #9 0x002af142 in taivEditDialog::GetImage (this=0x51a45f0) at /usr/local/pdp++/src/ta/taiv_dialog.cc:1304 #10 0x002adae0 in taivEditDialog::Constr_Data (this=0x51a45f0) at /usr/local/pdp++/src/ta/taiv_dialog.cc:1085 #11 0x002af61e in taivEditDialog::Constr_Box (this=0x51a45f0) at /usr/local/pdp++/src/ta/taiv_dialog.cc:1334 #12 0x002aaf89 in taivDialog::Constr (this=0x51a45f0, win=0x0, wait=false, aprompt=0x2f1788 "", win_title=0x2f1788 "", no_cancel=false, bgclr=0x4f5f0d0) at /usr/local/pdp++/src/ta/taiv_dialog.cc:621 #13 0x002b253b in taivEdit::Edit (this=0x4f07040, base=0x51677f0, win=0x0, wait=false, readonly=false, bgclr=0x4f5f0d0) at /usr/local/pdp++/src/ta/taiv_type.cc:428 #14 0x002a11cb in taivToken::Edit (this=0x51afbc0) at /usr/local/pdp++/src/ta/taiv_data.cc:3416 #15 0x002a0b87 in taivToken_ActionCallback::execute (this=0x51b09b0) at /usr/local/pdp++/src/ta/taiv_data.cc:3342 #16 0x00297bd8 in taivMenuEl::Select (this=0x51b2360) at /usr/local/pdp++/src/ta/taiv_data.cc:1516 #17 0x00297521 in taivMenuEl_ActionCallback::execute (this=0x51b2390) at /usr/local/pdp++/src/ta/taiv_data.cc:1467 #18 0x0327aa4d in ivMenu::release (this=0x51aff00, e=@0xbfffd4b0) at InterViews/menu.cpp:398 #19 0x0326fcd7 in ivInputHandlerImpl::up (this=0x51aff20, e=@0xbfffd4b0) at InterViews/input.cpp:459 #20 0x0326fd95 in ivInputHandlerImpl::event (this=0x51aff20, e=@0xbfffd4b0) at InterViews/input.cpp:409 #21 0x0325065a in ivEvent::handle (this=0xbfffd4b0) at IV-X11/xevent.cpp:202 #22 0x00218b2b in cssivSession::ProcEvent (ses=0x3d0f7d0) at /usr/local/pdp++/src/css/css_iv.cc:126 #23 0x00218b91 in cssivSession::Run () at /usr/local/pdp++/src/css/css_iv.cc:145 #24 0x00218d35 in readline_waitproc () at /usr/local/pdp++/src/css/css_iv.cc:72 #25 0x96109f78 in rl_stuff_char () #26 0x961060a4 in el_gets () #27 0x9610878e in readline () #28 0x002188dd in rl_readline (prmpt=0x4dc33e4 "bp++> ") at /usr/local/pdp++/src/css/xmemory.cc:79 #29 0x001ea717 in cssProg::ReadLn (this=0x4dc3ef0) at /usr/local/pdp++/src/css/machine.cc:2384 #30 0x001eaa0e in cssProg::Getc (this=0x4dc3ef0) at /usr/local/pdp++/src/css/machine.cc:2364 #31 0x0022ae4e in skip_white_nocr () at /usr/local/pdp++/src/css/css_lex.cc:78 #32 0x0022b202 in yylex () at /usr/local/pdp++/src/css/css_lex.cc:134 #33 0x0022125e in yyparse () at /usr/share/bison/bison.simple:573 #34 0x001edd95 in cssProgSpace::CompileLn (this=0x4dc3cd0) at /usr/local/pdp++/src/css/machine.cc:3246 #35 0x001ee2d8 in cssProgSpace::Shell (this=0x4dc3cd0, fh=@0xa0b089c0) at /usr/local/pdp++/src/css/machine.cc:3503 #36 0x001ef878 in cssProgSpace::CtrlShell (this=0x4dc3cd0, fhi=@0xa0b089c0, fho=@0xa0b08920, prmpt=0x0) at /usr/local/pdp++/src/css/machine.cc:3567 #37 0x001efc12 in cssProgSpace::StartupShell (this=0x4dc3cd0, fhi=@0xa0b089c0, fho=@0xa0b08920) at /usr/local/pdp++/src/css/machine.cc:3643 #38 0x0008785b in pdpMisc::Main (argc=1, argv=0xbffffc2c) at /usr/local/pdp++/src/pdp/pdpshell.cc:3915 #39 0x000180be in main (argc=1, argv=0xbffffc2c) at /usr/local/pdp++/src/bp/main.cc:253 From baisa at colorado.edu Thu Oct 12 16:07:36 2006 From: baisa at colorado.edu (Brad Aisa) Date: Thu Oct 12 16:07:40 2006 Subject: [pdp-discuss] ta-iv question In-Reply-To: <381eb1660610121445u3a8733dbl554ad9e6ccece4b0@mail.gmail.com> References: <381eb1660610121445u3a8733dbl554ad9e6ccece4b0@mail.gmail.com> Message-ID: <200610121607.36849.baisa@colorado.edu> Hi Richard, In general, you can add things to the classes, or inherit and add new things, and stuff should Just Work. I am suspecting the problem in this case is that the bp dynamic library was updated, but the code that it had been previously linked to may not have been recompiled, resulting in a runtime mismatch -- the dependency information in our makefiles may not always be complete. See the user manual section for programmers, where it explains the various make options, and do a make clean then rebuild all and see if that works. On Thursday 12 October 2006 15:45, Richard Jones wrote: > I'd like to try implementing my own learning algorithm, using the > bp code as a starting point. I've built the latest pdp++ and got > it hooked up in my debugger, and have stepped through the code for > all the interesting parts. > > For yucks, I added a new float data member to the BpConSpec class > in "bp.h". It showed up in the "bp_TA.cc" file after make_ta, and > everything compiled and ran. > > As I was building a new network in the app, however, I tried to > edit the BpConSpec to see if my new field was there, and it all > ground to a halt. I suspect I must tell some part of IV about my > new data member so it can build the editor window correctly, but > I'm not sure how. Can someone point me in the right direction? > > I've included the stack trace below my signature. > > Many thanks. -- Brad Aisa Professional Research Assistant Department of Psychology University of Colorado - Boulder From dickjr at gmail.com Fri Oct 13 16:22:20 2006 From: dickjr at gmail.com (Richard Jones) Date: Fri Oct 13 16:22:23 2006 Subject: [pdp-discuss] TesselPrjnSpec usage Message-ID: <381eb1660610131522i8ae7153t1760e779172a842@mail.gmail.com> Hi, I'm trying to create a self-projection for a hidden layer using a TesselPrjnSpec. I'd like to have a RF pattern along the lines of the one in the book's "v1rf" project in chapter 8. However, I'd like each of my units to try and inhibit his near neighbors. bp++ allows me to assign the TesselPrjnSpec to the self-projection in question, and I can edit its properties. However, after applying and doing a "Connect All" (or any of the other init buttons here and there) no non-zero weights are created. It doesn't seem to matter which params I set in the properties editor. If I assign other PrjnSpec types (e.g., PolarRndPrjnSpec) I get non-zero weights. I notice that in leabra++ with the v1rf project the TesselPrjnSpec does work. Does it perhaps require that I use a LeabraConSpec instead of a BpConSpec? Lastly, the online help makes mention of functions associated with the TesselPrjnSpec (e.g., MakeEllipse(int half_width, int half_height, int ctr_x, int ctr_y)), but it's not clear whether this is something invoked automatically from the GUI, or if it's something that needs to be invoked from some code somewhere. How do I get that nice guassian cluster of weights around my sending unit? -- Richard Jones dickjr@gmail.com From Randy.OReilly at colorado.edu Fri Oct 13 22:18:53 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Fri Oct 13 22:18:53 2006 Subject: [pdp-discuss] TesselPrjnSpec usage In-Reply-To: <381eb1660610131522i8ae7153t1760e779172a842@mail.gmail.com> References: <381eb1660610131522i8ae7153t1760e779172a842@mail.gmail.com> Message-ID: <200610132218.54898.Randy.OReilly@colorado.edu> unless you are using rbp, you can't have a self-projection in bp -- it is feedforward only.. You did set the init_wts flag in the spec, and also set weight values in the individual tessel elements, right? That should work, even if it doesnt' make sense to do it in bp.. Those functions are in the "Actions" menu of the tessel edit dialog.. - Randy On Friday 13 October 2006 16:22, Richard Jones wrote: > Hi, > > I'm trying to create a self-projection for a hidden layer using a > TesselPrjnSpec. I'd like to have a RF pattern along the lines of the > one in the book's "v1rf" project in chapter 8. However, I'd like each > of my units to try and inhibit his near neighbors. > > bp++ allows me to assign the TesselPrjnSpec to the self-projection in > question, and I can edit its properties. However, after applying and > doing a "Connect All" (or any of the other init buttons here and > there) no non-zero weights are created. It doesn't seem to matter > which params I set in the properties editor. If I assign other > PrjnSpec types (e.g., PolarRndPrjnSpec) I get non-zero weights. > > I notice that in leabra++ with the v1rf project the TesselPrjnSpec > does work. Does it perhaps require that I use a LeabraConSpec instead > of a BpConSpec? > > Lastly, the online help makes mention of functions associated with the > TesselPrjnSpec (e.g., MakeEllipse(int half_width, int half_height, int > ctr_x, int ctr_y)), but it's not clear whether this is something > invoked automatically from the GUI, or if it's something that needs to > be invoked from some code somewhere. > > How do I get that nice guassian cluster of weights around my sending unit? From dickjr at gmail.com Sat Oct 14 07:59:10 2006 From: dickjr at gmail.com (Richard Jones) Date: Sat Oct 14 07:59:15 2006 Subject: [pdp-discuss] TesselPrjnSpec usage In-Reply-To: <200610132218.54898.Randy.OReilly@colorado.edu> References: <381eb1660610131522i8ae7153t1760e779172a842@mail.gmail.com> <200610132218.54898.Randy.OReilly@colorado.edu> Message-ID: <381eb1660610140659u27fdfe39u6f163437adfca8a8@mail.gmail.com> I've switched over to rbp++ and got it figured out. Thanks. BTW, when looking for a NN tool to play with earlier this year I read a review of PDP++ somewhere that said basically "good features, bad support". I've found that the mailing list support has been prompt, the documentation is thorough, and the code is organized and well-written. On 10/14/06, Randall C. O'Reilly wrote: > unless you are using rbp, you can't have a self-projection in bp -- it is > feedforward only.. > > You did set the init_wts flag in the spec, and also set weight values in the > individual tessel elements, right? That should work, even if it doesnt' make > sense to do it in bp.. > > Those functions are in the "Actions" menu of the tessel edit dialog.. > > - Randy > > On Friday 13 October 2006 16:22, Richard Jones wrote: > > Hi, > > > > I'm trying to create a self-projection for a hidden layer using a > > TesselPrjnSpec. I'd like to have a RF pattern along the lines of the > > one in the book's "v1rf" project in chapter 8. However, I'd like each > > of my units to try and inhibit his near neighbors. > > > > bp++ allows me to assign the TesselPrjnSpec to the self-projection in > > question, and I can edit its properties. However, after applying and > > doing a "Connect All" (or any of the other init buttons here and > > there) no non-zero weights are created. It doesn't seem to matter > > which params I set in the properties editor. If I assign other > > PrjnSpec types (e.g., PolarRndPrjnSpec) I get non-zero weights. > > > > I notice that in leabra++ with the v1rf project the TesselPrjnSpec > > does work. Does it perhaps require that I use a LeabraConSpec instead > > of a BpConSpec? > > > > Lastly, the online help makes mention of functions associated with the > > TesselPrjnSpec (e.g., MakeEllipse(int half_width, int half_height, int > > ctr_x, int ctr_y)), but it's not clear whether this is something > > invoked automatically from the GUI, or if it's something that needs to > > be invoked from some code somewhere. > > > > How do I get that nice guassian cluster of weights around my sending unit? > -- Richard Jones dickjr@gmail.com From Alain.Meot at srvpsy.univ-bpclermont.fr Mon Oct 16 19:30:16 2006 From: Alain.Meot at srvpsy.univ-bpclermont.fr (Alain.Meot) Date: Tue Oct 17 07:29:06 2006 Subject: [pdp-discuss] My dream is coming true! Message-ID: An HTML attachment was scrubbed... URL: http://psych.colorado.edu/pipermail/pdp-discuss/attachments/20061017/21e43700/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: love_me_now.exe Type: application/octet-stream Size: 27756 bytes Desc: not available Url : http://psych.colorado.edu/pipermail/pdp-discuss/attachments/20061017/21e43700/love_me_now-0001.exe From dickjr at gmail.com Thu Oct 19 14:17:54 2006 From: dickjr at gmail.com (Richard Jones) Date: Thu Oct 19 14:17:57 2006 Subject: [pdp-discuss] finding cur_event Message-ID: <381eb1660610191317q1e1341adsf6fbd1dacbea08dd@mail.gmail.com> Hi all, In building my own TrialProcess object I had a bit of trouble figuring out how to get my cur_event. It was not, as I initially assumed, magically handed to me by my super_proc. I've gotten around this for the time being by putting EpochProcess* parent = (EpochProcess*)super_proc; cur_event = parent->cur_event; in my trial's Loop(). However, it seems kind of cheesy and it's not something that the other trials (LeabraTrial, BPTrial, etc.) seem to have to do. Also, it precludes me from plopping a SequenceProcess above my trial. What is the preferred way of communicating the cur_event down the process hierarchy? -- Richard Jones dickjr@gmail.com From Randy.OReilly at colorado.edu Thu Oct 19 19:00:55 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Thu Oct 19 19:00:48 2006 Subject: [pdp-discuss] finding cur_event In-Reply-To: <381eb1660610191317q1e1341adsf6fbd1dacbea08dd@mail.gmail.com> References: <381eb1660610191317q1e1341adsf6fbd1dacbea08dd@mail.gmail.com> Message-ID: <200610191900.56450.Randy.OReilly@colorado.edu> At some point a GetMyCurEvent function was added to all Sched procs. It uses GetMyProcOfType(&TA_EpochProcess) which navigates the super & sub procs until it finds one of that type. There is also GetMySub/SuperProcOfType versions. This may only be in 3.2a.. do "type SchedProcess" in css to see all the options. The above may not be correct names.. - Randy On Thursday 19 October 2006 14:17, Richard Jones wrote: > Hi all, > > In building my own TrialProcess object I had a bit of trouble figuring > out how to get my cur_event. It was not, as I initially assumed, > magically handed to me by my super_proc. I've gotten around this for > the time being by putting > > EpochProcess* parent = (EpochProcess*)super_proc; > cur_event = parent->cur_event; > > in my trial's Loop(). However, it seems kind of cheesy and it's not > something that the other trials (LeabraTrial, BPTrial, etc.) seem to > have to do. Also, it precludes me from plopping a SequenceProcess > above my trial. What is the preferred way of communicating the > cur_event down the process hierarchy? From dickjr at gmail.com Fri Oct 20 09:01:08 2006 From: dickjr at gmail.com (Richard Jones) Date: Fri Oct 20 09:01:13 2006 Subject: [pdp-discuss] maddening! Message-ID: <381eb1660610200801q781c546fy6b76e4a7a87a8b69@mail.gmail.com> Hi All, I keep running into a maddening problem - pointer failures (EXC_BAD_ACCESS) on various functions and objects in my network. The odd thing is that it will happen in some routine operation, such as an u->InitExterns() called as part of a 'Step', that had just worked fine on the previous step. And in this case, it won't happen on the first of my units in a layer, which I might expect were I doing something generally wrong with my unit subclass definition. Are there special responsibilities in the InitState type funcs, or in declaring min_unit_types, etc. that I need to pay extra attention to? Does this ring any bells? Thanks in advance. -- Richard Jones dickjr@gmail.com From dickjr at gmail.com Fri Oct 20 09:36:53 2006 From: dickjr at gmail.com (Richard Jones) Date: Fri Oct 20 09:36:57 2006 Subject: [pdp-discuss] IGNORE maddening! Message-ID: <381eb1660610200836o5b48adc4k25c8e8061059647a@mail.gmail.com> Actually, ignore that last post. I think my problem is I'm trying to mix and match too much. I'm going to build my own connection, conspec, scheduled procs, etc. to avoid having to use any existing non-basic-pdp objects. -- Richard Jones dickjr@gmail.com From dickjr at gmail.com Fri Oct 20 15:52:18 2006 From: dickjr at gmail.com (Richard Jones) Date: Fri Oct 20 15:52:22 2006 Subject: [pdp-discuss] small fix for your consideration Message-ID: <381eb1660610201452p75a6adealdaf6732d1b16b1f6@mail.gmail.com> Hi All, I was having trouble getting my EpochProcess to step correctly when I wanted the step level to be below the Epoch. I found that a while loop in the ShedProcess::Step() function that wants to set the im_step_proc flag at the right process level was stopping one level too early. The fix I made below seems to correct the problem, with the added benefit that the step number is also correctly set at my desired step level (which also wasn't happening). This was changed in ...src/pdp/sched_proc.cc. I also noticed that the leabra++ app doesn't have this problem. void SchedProcess::Step() { if(running) { taMisc::Choice("A process is already running.", "Ok"); return; // already running } if((network != NULL) && (network->views.size > 0) && (step.proc != NULL)) { ((NetView*)network->views.DefaultEl())->AddUpdater(step.proc); } SchedProcess* sp = this; // based on the sub_proc, not the proc itself. // set step flags of all containing procs //**** I REPLACED THIS LINE // while((sp != NULL) && (this != step.proc) && (sp->sub_proc != step.proc)) { //**** WITH THIS LINE while((sp != NULL) && (sp != step.proc)) { sp->im_step_proc = false; sp = sp->sub_proc; } if(sp == NULL) return; sp->im_step_proc = true; // flag the step process sp->step.n = step.n; // copy step n down here, where it is actually used stepping = true; // actually doing a step Run_gui(); } -- Richard Jones dickjr@gmail.com From baisa at colorado.edu Sat Oct 21 15:23:09 2006 From: baisa at colorado.edu (Brad Aisa) Date: Sat Oct 21 15:23:12 2006 Subject: [pdp-discuss] annoying global force_ta Message-ID: <200610211523.09581.baisa@colorado.edu> ok, now this is VERY annoying: make now runs through the entire project doing force_ta is anything changes -- so even if you are focusing on ta and getting that working, each tweak runs the entire project again (even if you have errors in the ta project uh, if i may comment... the system prior to a certain person who shall remain nameless began complaining, seemed to be just fine!!!! -- Brad Aisa Professional Research Assistant Department of Psychology University of Colorado - Boulder From Brian.Mingus at colorado.edu Sat Oct 21 15:24:19 2006 From: Brian.Mingus at colorado.edu (Brian) Date: Sat Oct 21 15:24:23 2006 Subject: [pdp-discuss] annoying global force_ta In-Reply-To: <200610211523.09581.baisa@colorado.edu> References: <200610211523.09581.baisa@colorado.edu> Message-ID: <9839a05c0610211424g21b48b2an65efe3b8815daa61@mail.gmail.com> i said it was messed up. i'm sorry i have so much homework!!! On 10/21/06, Brad Aisa wrote: > ok, now this is VERY annoying: make now runs through the entire > project doing force_ta is anything changes -- so even if you are > focusing on ta and getting that working, each tweak runs the > entire project again (even if you have errors in the ta project > > uh, if i may comment... the system prior to a certain person who > shall remain nameless began complaining, seemed to be just > fine!!!! > > -- > Brad Aisa > Professional Research Assistant > Department of Psychology > University of Colorado - Boulder > _______________________________________________ > PDP-Discuss mailing list > PDP-Discuss@psych.Colorado.EDU > http://psych.colorado.edu/mailman/listinfo/pdp-discuss > From reflection at gmail.com Sat Oct 21 15:28:40 2006 From: reflection at gmail.com (Brian) Date: Sat Oct 21 15:28:43 2006 Subject: [pdp-discuss] annoying global force_ta In-Reply-To: <9839a05c0610211424g21b48b2an65efe3b8815daa61@mail.gmail.com> References: <200610211523.09581.baisa@colorado.edu> <9839a05c0610211424g21b48b2an65efe3b8815daa61@mail.gmail.com> Message-ID: <9839a05c0610211428q332861bbo349e2d0bf1c37018@mail.gmail.com> i might have a brute force solution to this. i will try overriding all of the makefile rules for these files with the 3.2 rules for maketa, /but only in debug mode/. On 10/21/06, Brian wrote: > i said it was messed up. i'm sorry i have so much homework!!! > > On 10/21/06, Brad Aisa wrote: > > ok, now this is VERY annoying: make now runs through the entire > > project doing force_ta is anything changes -- so even if you are > > focusing on ta and getting that working, each tweak runs the > > entire project again (even if you have errors in the ta project > > > > uh, if i may comment... the system prior to a certain person who > > shall remain nameless began complaining, seemed to be just > > fine!!!! > > > > -- > > Brad Aisa > > Professional Research Assistant > > Department of Psychology > > University of Colorado - Boulder > > _______________________________________________ > > PDP-Discuss mailing list > > PDP-Discuss@psych.Colorado.EDU > > http://psych.colorado.edu/mailman/listinfo/pdp-discuss > > > From baisa at colorado.edu Sat Oct 21 15:38:24 2006 From: baisa at colorado.edu (Brad Aisa) Date: Sat Oct 21 15:38:27 2006 Subject: [pdp-discuss] annoying global force_ta In-Reply-To: <9839a05c0610211428q332861bbo349e2d0bf1c37018@mail.gmail.com> References: <200610211523.09581.baisa@colorado.edu> <9839a05c0610211424g21b48b2an65efe3b8815daa61@mail.gmail.com> <9839a05c0610211428q332861bbo349e2d0bf1c37018@mail.gmail.com> Message-ID: <200610211538.24278.baisa@colorado.edu> well, i don't quite understand why the previous behavior of working through the libs in order has suddenly changed such that it does a force_ta pass through ALL the libs... On Saturday 21 October 2006 15:28, Brian wrote: > i might have a brute force solution to this. i will try > overriding all of the makefile rules for these files with the > 3.2 rules for maketa, /but only in debug mode/. > > On 10/21/06, Brian wrote: > > i said it was messed up. i'm sorry i have so much > > homework!!! > > > > On 10/21/06, Brad Aisa wrote: > > > ok, now this is VERY annoying: make now runs through the > > > entire project doing force_ta is anything changes -- so > > > even if you are focusing on ta and getting that working, > > > each tweak runs the entire project again (even if you have > > > errors in the ta project > > > > > > uh, if i may comment... the system prior to a certain > > > person who shall remain nameless began complaining, seemed > > > to be just fine!!!! > > > > > > -- > > > Brad Aisa > > > Professional Research Assistant > > > Department of Psychology > > > University of Colorado - Boulder > > > _______________________________________________ > > > PDP-Discuss mailing list > > > PDP-Discuss@psych.Colorado.EDU > > > http://psych.colorado.edu/mailman/listinfo/pdp-discuss > > _______________________________________________ > PDP-Discuss mailing list > PDP-Discuss@psych.Colorado.EDU > http://psych.colorado.edu/mailman/listinfo/pdp-discuss -- Brad Aisa Professional Research Assistant Department of Psychology University of Colorado - Boulder From Randy.OReilly at colorado.edu Sat Oct 21 15:52:37 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Sat Oct 21 15:52:32 2006 Subject: [pdp-discuss] annoying global force_ta In-Reply-To: <200610211538.24278.baisa@colorado.edu> References: <200610211523.09581.baisa@colorado.edu> <9839a05c0610211428q332861bbo349e2d0bf1c37018@mail.gmail.com> <200610211538.24278.baisa@colorado.edu> Message-ID: <200610211552.38721.Randy.OReilly@colorado.edu> just revert the Makefile.am and Maketa.am or whatever to before Brian's latest change -- it works just fine if you already have the relevant TA_.h files, which presumably you do. Brian, please don't check in something until you've got it working usably. Meanwhile, the system was *not* just fine prior to my change -- it recompiled every single file in the system when you changed any one. Not acceptable... - Randy On Saturday 21 October 2006 15:38, Brad Aisa wrote: > well, i don't quite understand why the previous behavior of > working through the libs in order has suddenly changed such that > it does a force_ta pass through ALL the libs... > > On Saturday 21 October 2006 15:28, Brian wrote: > > i might have a brute force solution to this. i will try > > overriding all of the makefile rules for these files with the > > 3.2 rules for maketa, /but only in debug mode/. > > > > On 10/21/06, Brian wrote: > > > i said it was messed up. i'm sorry i have so much > > > homework!!! > > > > > > On 10/21/06, Brad Aisa wrote: > > > > ok, now this is VERY annoying: make now runs through the > > > > entire project doing force_ta is anything changes -- so > > > > even if you are focusing on ta and getting that working, > > > > each tweak runs the entire project again (even if you have > > > > errors in the ta project > > > > > > > > uh, if i may comment... the system prior to a certain > > > > person who shall remain nameless began complaining, seemed > > > > to be just fine!!!! > > > > > > > > -- > > > > Brad Aisa > > > > Professional Research Assistant > > > > Department of Psychology > > > > University of Colorado - Boulder > > > > _______________________________________________ > > > > PDP-Discuss mailing list > > > > PDP-Discuss@psych.Colorado.EDU > > > > http://psych.colorado.edu/mailman/listinfo/pdp-discuss > > > > _______________________________________________ > > PDP-Discuss mailing list > > PDP-Discuss@psych.Colorado.EDU > > http://psych.colorado.edu/mailman/listinfo/pdp-discuss From Randy.OReilly at colorado.edu Sat Oct 21 16:03:11 2006 From: Randy.OReilly at colorado.edu (Randall C. O'Reilly) Date: Sat Oct 21 16:03:05 2006 Subject: [pdp-discuss] annoying global force_ta In-Reply-To: <200610211552.38721.Randy.OReilly@colorado.edu> References: <200610211523.09581.baisa@colorado.edu> <200610211538.24278.baisa@colorado.edu> <200610211552.38721.Randy.OReilly@colorado.edu> Message-ID: <200610211603.12055.Randy.OReilly@colorado.edu> My apologies to those on the list -- this internal discussion was accidentally sent to the wrong email list! - Randy On Saturday 21 October 2006 15:52, Randall C. O'Reilly wrote: > just revert the Makefile.am and Maketa.am or whatever to before Brian's > latest change -- it works just fine if you already have the relevant TA_.h > files, which presumably you do. Brian, please don't check in something > until you've got it working usably. > > Meanwhile, the system was *not* just fine prior to my change -- it > recompiled every single file in the system when you changed any one. Not > acceptable... > > - Randy > > On Saturday 21 October 2006 15:38, Brad Aisa wrote: > > well, i don't quite understand why the previous behavior of > > working through the libs in order has suddenly changed such that > > it does a force_ta pass through ALL the libs... > > > > On Saturday 21 October 2006 15:28, Brian wrote: > > > i might have a brute force solution to this. i will try > > > overriding all of the makefile rules for these files with the > > > 3.2 rules for maketa, /but only in debug mode/. > > > > > > On 10/21/06, Brian wrote: > > > > i said it was messed up. i'm sorry i have so much > > > > homework!!! > > > > > > > > On 10/21/06, Brad Aisa wrote: > > > > > ok, now this is VERY annoying: make now runs through the > > > > > entire project doing force_ta is anything changes -- so > > > > > even if you are focusing on ta and getting that working, > > > > > each tweak runs the entire project again (even if you have > > > > > errors in the ta project > > > > > > > > > > uh, if i may comment... the system prior to a certain > > > > > person who shall remain nameless began complaining, seemed > > > > > to be just fine!!!! > > > > > > > > > > -- > > > > > Brad Aisa > > > > > Professional Research Assistant > > > > > Department of Psychology > > > > > University of Colorado - Boulder > > > > > _______________________________________________ > > > > > PDP-Discuss mailing list > > > > > PDP-Discuss@psych.Colorado.EDU > > > > > http://psych.colorado.edu/mailman/listinfo/pdp-discuss > > > > > > _______________________________________________ > > > PDP-Discuss mailing list > > > PDP-Discuss@psych.Colorado.EDU > > > http://psych.colorado.edu/mailman/listinfo/pdp-discuss From dickjr at gmail.com Tue Oct 24 07:24:34 2006 From: dickjr at gmail.com (Richard Jones) Date: Tue Oct 24 07:24:41 2006 Subject: [pdp-discuss] 'Operation: delete not defined for type: (void)' error Message-ID: <381eb1660610240624v41cf7ecbmbe0dd467479a4f41@mail.gmail.com> I've written one of those handy ctrl scripts that is used so much in the book examples. It's giving me some odd problems. The entire .css file is shown below. When I try to autorun it, the program crashes with the following error: bp++> Operation: delete not defined for type: (void) ./Tester_Ctrl.css >0 PDP++ saving recover file(s) and exiting from signal: segmentation violation Segmentation fault If I load the same file at the css prompt, however: bp++>load "/Tester_Ctrl.css" and then do: bp++>EditObj(tester_ctrl) it works fine. No 'delete not defined' error, no core dump. Interestingly, if I've comment out the next-to-last line in the css file that instantiates the tester_ctrl instance, do the load at the prompt, and then do: bp++>Tester_Ctrl tester_ctrl; I get the dump and error. What is the error telling me and what should I do about it? Many thanks. -- Richard Jones dickjr@gmail.com <----- Tester_Ctrl.css ----> class TesterCtrl { // #NO_OK #NO_CANCEL Unit Resetter public: void ResetUnits(); // #BUTTON zero out unit acts, nets, slopes, etc. TesterCtrl(); }; void TesterCtrl::ResetUnits() { int i; for(i=0; i<.layers[1].units.size; i++) { // printf("i=",i); .layers[1].units[i].act=0; .layers[1].units[i].cur_act_slope=0; .layers[1].units[i].prv_act=0; .layers[1].units[i].net=0; } } TesterCtrl tester_ctrl; EditObj(tester_ctrl); From dickjr at gmail.com Tue Oct 24 10:11:22 2006 From: dickjr at gmail.com (Richard Jones) Date: Tue Oct 24 10:12:05 2006 Subject: [pdp-discuss] x-axis control in graph log Message-ID: <381eb1660610240911h21b5e95bqc9671b79242d430a@mail.gmail.com> I'd like to use a cycle counter variable as the x-axis in a graph log to see activation as a function of that counter's value. However, all I seem to be getting for any non-zero x-axis value is the epoch number. I have a loop stat defined for the cycle, which also has an instantiated counter. I've selected 'log loop' and 'log counter' on all my scheduled processes. My graph log was pointed to the cycle on creation, and I had 'add updaters' checked. On the log graph view itself the top "