This is the change log maintained for JM_SAP during the alpha development phase - i.e. *prior* to v1.0. Changes are listed in *reverse* chronological order. ============================================================= ALPHA (internal) Releases: 0.09: 16-MAR-1994 B.McMullin Replaced the built in pseudo random number generator, with a standardised one of known statistical properties (msr88). Main reason for this was to allow option of user control of seed, so that runs can be determinstically repeatable. Added options in initial for user to input the disintegration probability and the number of catalysts. The catalyst placement code was also slightly modified to *guarantee* that we will get the requested number of distinct catalysts. Completely re-engineered user interface to allow graphical display of bond positions. The graphical interface code is loosely derived from a program originally written by Francois Jullien (internet: frj@ccr.jussieu.fr). Note that the graphical output is now the slowest aspect of the program, so I have made it incremental - only updating things that have changed. This does not work completely prefectly - small fragments of diagonal bonds tend to get erased and/or left in mid air. But it does not detract too much (?). Altered procedures listholes, listlink, listkats to alternate the scanning order so as to offset (approximately at least) any systematic bias which one particular order might introduce. This is probably of negligable significance in the case of links and catalyst (because they only even have low density anyway) and of limited sighnificance for holes (their density did tend to grow to significant levels, where a movement bias became apparent, but that was because matter was not being conserved; but that is no longer the case either - see next point). Altered procedure disint so that it conserves matter; specifically it now tries for a vacent hole (for the extra substrate atom) in the full Moore (8-cell) neighbourhood first; and if that fails then it picks a hole at random from elsewhere in the space. It might be nicer to spiral the search outward, but its more trouble than I want to go to. Alternatively a totally crude method might be to always search from row 1, column 1, for a spare hole; that would be simpler, and execute faster, but would introduce a spurious bias in the hole distribution throughout the space. My method is an inbetween strategy which is fairly crude, fairly simple, but should still not have weird side effects. Re-instated the check for *equality* of hole count and link count in the space (now in DisplayGrid). 0.08: 09-MAR-1994 B.McMullin. Revamped version tracking infomation. Debugging code added to check for hole count always equal to link count. Misplace END in disint procedure corrected; but code still looks wrong - if no space in an immediate, orthogonal, position then the second substrate just disappears ... this looks like a "feature" not a bug, so we will not try to fix it now. Amended the code checking for equality of hole and link count again, so that we now panic only if the hole count becomes *less* than the link count. Switched on run-time range checking. Detected violation in checkbond. There seems to be a clutter of 'l' characters which should be '1'. Not detected previously because there happens to be an 'l' variable in scope in these cases. Wonder how many more of these there are? Hmmmm. More of the same in linkbonds, dsplink. Range check violation in listholes; but this is a more substantive problem. The static array size (200) only allows for a max of 100 holes. But, depending on production rate, this can get exceeded (especially since the hole count is drifting up away due to loss of substrate in disintegration). Resize the two arrays in question to be 1200 long, allowing for 600 entries apiece - this is *definitely* enough since this is the total size of the space! 'Course it slows things down a bit too, but we can't have everything. Some additional fixes from John Mingers added in. This seems to fix the range violations, but there are still some deficiencies in behaviour. On a long run, space accumulates on the left, matter on the right, indicating quite a strong bias in movement. 0.07: 09-MAR-1994 B.McMullin. Add this release history. Manual review code to fine tune layout and fix obvious incompatibilities with Turbo Pascal. Basic run testing. "Somewhat" functional: but matter not being properly conserved, so that holes become scarce (or non-existent) and dis-integration cannot proceed (execution also gets *very* slow presumably due to fruitless searching for non-existent holes...). 0.06: 09-MAR-1994 B.McMullin. Manually fix the indentation on the mail headers again. 0.05: 09-MAR-1994 B.McMullin. Then run through Pascal pretty printer obtained from Simtel-20 (turbopas/pp50.zip). 0.04: 09-MAR-1994 B.McMullin. Strip off all leading spaces and blank lines. 0.03: 09-MAR-1994 B.McMullin. Make minimal edits to allow successful compile under Turbo Pascal V5.5. Main typos were 'l' for '1', 'o' for '0', but a variety of others also present. Many individual fixes so they are undocumented in detail. 0.02: 09-MAR-1994 B.McMullin. Filter out Physical Tab characters, replacing with single spaces. 0.01: 09-MAR-1994 B.McMullin. Add Mail header(s) as documentary comments. 0.00: 09-MAR-1994 B.McMullin. uudecode from Mail message (header included below). NB: This version was re-keyed at Warwick. Indentation was messed up, and many minor typos can be expected. ========================================= Following are mail headers documenting original transmission of the electronic format program to BMcM: ============= To: mcmullin@eeng.dcu.ie (Barry McMullin) From: "John Mingers" Organization: Warwick Business School Date: Wed, 9 Mar 1994 09:00:38 GMT Subject: Re: Response to John Mingers... Barry, I attach with this message a copy of the program. It is not pretty - the indentation was messed up when it was re-input. Let me know what you think. John Mingers, Senior Lecturer in Operational Research and Systems, Warwick Business School, Internet: orsjm@wbs.warwick.ac.uk University of Warwick, Bitnet: orsjm%uk.ac.warwick.wbs@ukacrl.bitnet Coventry CV4 7AL, UK. phone: +203 523523 x2475 ============ To: mcmullin@eeng.dcu.ie (Barry McMullin) From: "John Mingers" Organization: Warwick Business School Date: Wed, 9 Mar 1994 09:00:37 GMT Subject: Re: Response to John Mingers... * This message contains the file 'autop.pas', which has been * uuencoded. If you are using Pegasus Mail, then you can use * the browser's eXtract function to lift the original contents * out to a file. If you are not using Pegasus Mail, you will * have to extract the message and uudecode it manually.