LIMITATIONS

The current version of Istar has a number of limitations. Some of them include:

# Cannot import to KB from another KB.

# The FIRSTOK inference method (Present Each To User) not yet implemented.

# Cannot use the Import-Text yet on items.

# Cannot at present delete value names from an attribute type; can only add them.

# Certain obscure conversions between value types do not work fully; best to try them out before you use them. e.g. Float to Odds. Proportion, Prob and Bayes to Ordinal does not work.

# The new text/document facility is at present very limited.

# Warning: CONTROL unary operator will not always work on a Chooser attribute, unless it is the first antecedent.

BUGS

This is a list of some bugs you should be aware of that are either in the current version or were found in earlier versions and not yet diagnosed and corrected. Older bugs, now fixed, are listed below by version.

# (Nuisance for those using graphics cards. Reported November 1999) I've had one report from someone using Istar with a graphics card that it is very slow. I have asked for details, but few have been forthcoming yet, except that they say that it takes 15 seconds for the screen to come up! This is being investigated. But Istar does rely quite heavily on some features that are unique to the Amiga hardware, especially smooth scrolling of different screens. However, another person reported some time ago that Istar works OK with UAE on a PC. Being investigated.

# (Visual nuisance; can be misleading: Noted 12 November 1999) Sometimes you find that the value line in an attribute box does not seem to respond to changes in value. This can be because (somehow) there is an easelpiece for the value line but the attribute has its Show Value deactivated. Result: Because Show is inactive forward chaining will not take the time to look for and alter the value line easelpiece. So it remains as it was. SOLUTION: Tick Show gadget on 2nd line of Attribute Details Panel, then hit OK, then untick the Show box, and hit OK. Should then be correct.

# (Intermittent oddity that can be a nuisance, reported by John Evans.) Easel boxes can lose their labels. Occasionally, while you have been working on KBs for some time, you move a box and find that its label text stays behind on the screen and that the box now has no text in it. Thereafter, no boxes are drawn with text: all empty. If you do a redraw, you end up with empty boxes all over. The only way to cure it is to save your KB - don't worry, the texts are still there - and quit Istar, possibly reboot in case there is memory corruption, and restart Istar and reload your KB. It seems to occur after you have run out of chip memory for panels. Being investigated. Top-right button on control screen (unlabelled) can set tracing so I can see what is happening in the text drawing routine.

# (Tiny cosmetic nuisance introduced by fixing inability to set Show on attributes of item types) When you have an itemtype with an attribute that is ticked as Show, then when you first create the box for the item instance, the values are not shown. However, all you have to do is get the box redrawn, such as moving it a fraction, and the lines appear.

# (Nuisance) For an item type with its own box, if you make it of a different size than standard, then draw an item of this type, the box that follows the mouse is not the new size but the standard size. However it then pops to the correct size when you let go of the mouse. 2 June 1998

# (Rare but unavoidable if you need it) Multiplying two ratios in which one has a negative number does not work. 1/-6 times 12/1 gives 6/65533.

# (Harmless nuisance 'feature') If you create a new attribute type and set its pens, and then create a free attribute item type for it, then sometimes boxes of this will be the new colours and sometimes not. What happens is that if you set the pens and hit the 'Create Free Att Item Typ' button, it is created with the old pens - because it only copies the new pens etc. across when you hit the OK button. But if you do not hit that button but hit OK after setting the pens, and create the FAIT afterwards, then it will have the new pens. Note that from v1.083 onwards, if you hit the OK button without a FAIT it will ask whether you wish one created - and ones created there will have the new pens.

# (Harmless nuisance) If you start to create a new item type (and relationship type) then hit 'Cancel' the type is not actually deleted; you get a type with a null (dash) name and have to hit the 'Rid' button to remove it. This is because it first creates a null-named type and then allows you to change its details.

# (Nuisance) Recently I had things like DirOpus loaded, and went to load up three KBs with full size easels. Then tried to 'rid' a KB and nothing happened. Tried to quit and nothing happened. Because I had run out of Chip memory and the small "Is it OK to rid the KB?" panel would not come up! (Chip memory was down to 13k.) But beware: there is no warning, and none can be given because the warning panel will not come up.

# (Harmless limitation) Various buttons are not operative yet:

# (Harmless limitation) Conversion Float to Odds does not work.

# (Could lead to unexpected results in your KB) When a conversion does not work you do not get any warning of this fact. What happens depends on the type of conversion, but often the result holds the bit pattern of the uncoverted value, which might of course seem like rubbish, or might hold 0. 30 July 1996.

# (Nuisance, unlikely to be encountered) I have a couple of old KBs which have a 8-colour easel and in which pen 7 is white, like the background colour, so things drawn in this pen appear invisible. I alter the colour on the Easel Info menu, and save the KB, but for some reason it doesn't save properly. The reason is that in older KBs the palette was stored differently.

CRASHES ENCOUNTERED

(Please: it you have it crash on you, send me details. Istar@basden.u-net.com). The following crashes I have experienced and not yet found the cause of.

# (1.04: Probably OK from 1.05. Can cause crash, but avoidable) The resize KB facility can be a bit fragile and can cause a crash in version 1.04. This is because if the KB increases in size it moves in memory and therefore all the pointers into it must all be changed. I *think* I have found all these, but I did once get a guru 81---5 (attempt to free memory already freed) when I quit the program. I have a feeling it was something to do with resizing. For this reason, before you attempt to resize you should close down all panels except that for the KB itself.

BUGS FIXED

FIXED BY VERSION 1.14, April 2000

# (Rare possible crashing; never knowingly experienced) The main input routine could, in some very rare circumstances, be called recursively and in that case when it returned from an inner call it might crash because the variables it had when it recursed might no longer be valid. This has been fixed by using globals.

FIXED BY VERSION 1.13 (not published, Jan 2000)

# (Stupid nuisance!) Previously, something crazy happened on the item details panel: if you hit the 'rid' button on the list of antecedents or consequents, you were asked to confirm, but if you hit the Delete button, to get rid of the whole item, you were not! So I reversed that. Also on the relationship instance and attribute action panels.

FIXED BY VERSION 1.12, November 1999

# (Unavoidable but rare error, from version 1.1, noted 20 November 1999) Form input of ODDS or other multi-part values only fills in the first part.

# (Error in many versions since before 1998) For some time I have found that the inference methods >= and <= did not work correctly, always giving a result of true. John Evans also reported it a year or more ago, but I could never find the cause. It was an indirect error, rather hidden. Fixed 1.12. (Turns out that an included file had a define of qqCPF_GE/LE as qqCPF_GT/LT | qqCFP_EQ without brackets round it. So return( qqCPF_GE & result ) would not give what we expect, but would AND one part of _GE with result and then OR that with the other part - which of course would always yield a non-zero result!).

# (Error in server forms that affected the ICT KB, since version 1.0). When there were more than about 6 gadgets on a HTML form, some of the later ones could be cut off due to truncation of the input line. The reason was similar to above: the test if ( svCSF_EOF | svCSF_EOL & r ) .. (where the svCSF_ are defined constant flags) will always return true because the & is evaluated before the |.

FIXED BY VERSION 1.11, October 1999

Version 1.11 was placed on my website for a short time, but not on Aminet.

# (Nuisance only in version 1.1, that could in theory cause crashes though it was never known to.) When running as a Knowledge Server, the log did not show the IP Address of the incoming connection correctly. In fact it showed a static random number. The cause was that, in accepting a connection using accept() the size of buffer was not set. In fact the variable used, zna, was on the stack and always seemed to have the value 1, which meant that only one byte was plaved in buffer, and this did not include the IP address. (Because it always seemed to be 1, it was safe, and did not overwrite the end of the buffer, causing a crash. But I am putting out verson 1.11 in case it sometimes does so.) Remedy for user: nothing; get version 1.11. Corrected in version 1.11.

# (Nuisance only in version 1.1) The Weights Panel, when showing multi-part weights (such as bayesian weights) and the user clicked OK, only updated the first part and left all the other parts untouched. Remedy for user using version 1.1: you must bring up the individual Relationship Instance Panels for each weight and set it individually. Corrected in version 1.11.

# (Mystery. Could be a major nuisance, but only happened once.) Once I found that the knowledge server demo site had stopped. That is, on the log was a message saying 'Knowledge server stopped' and though Istar was still running OK, the server module was not. No reason could be found for stopping. Examination of the code could find no reason for stopping other than deliberate stopping by hitting a button. It might be that someone clicked the Stop button, but nobody was (supposed to be) around. No idea. But I've simplified version 1.11 and made it log a reason for stopping.

# (Tiny rare nuisance. All previous versions.) Link a Form item to a bayesian attribute, and bring up its Relationship Instance panel. It gives you a weight and unary operator. If you alter the uop to be negate etc. then it changes the colour of link to the negative pen.

FIXED BY VERSION 1.1, September 1999

# (Intermittent crashes in rare circumstances up to and including version 1.092): If there is not enough memory to open a KB's easel (in normal usage), it would just load KB without it but expect it to be there, and gave no error; crashes. Fixed in version 1.1.

# (Nuisance up to and including version 1.092): A long-standing memory leak which could occur when hitting Quit and letting Istar remove all the KBs automatically (but which did not occur when you hit the Rid button for the KB). Fixed in version 1.1.

# (Nuisance up to and including version 1.092): Load two KBs, X,Y. Then do 'see easel' for X. Wave mouse around and the name window shows items in Y, not X. After a long time I found that aWorkWindow was not set to the proper easel before pgShowWork() was called. It did switch OK, but immediately on a mousemove it switched to the Y KB. Fixed in version 1.1.

# (Nuisance up to and including version 1.092): CONTROL inference relationship. Doesn't seem to work properly. Trees.2. Infer from frost. And its infce session waits at end for some time (loop?). Then frost is not ans. Probably this bug had been introduced by changes to some earlier version. Fixed in version 1.1.

# (Nuisance up to and including version 1.092): Allocation of string values is now OK. In previous versions, we had the following but: RI panel: For relshp to cons that is String: Change to UO CONTROL, OK, then bring rel up again, enter string value, OK, bring it up again and no sign of string. Various reasons. Some in RI. Some in qqbl. It was mainly to do with qqAllocVal(). See log:Log.990703. Fixed in version 1.1 by rationalizing allocation of variable length values in qq module.

# (Nuisance up to and including version 1.092): String to float conversion did not work. Fixed in version 1.1.

# (Cosmetic nuisance up and incl version 1.092; 25 February 1999) List of Relationship types sometimes shows the inverse names rather than real names. Fixed 25 February 1999 by making the name-finding more sophisticated so that for a reltype it gives a pair: 'main/inv'.

FIXED BY VERSION 1.092

# Fixed a bug introduced into version 1.09, in which item instances were not linked to their boxgroups.

# All known Enforcer Hits has been removed. Four were found: a read of location 0 when bringing up file requester for first time, a read of location 0 when the main easel of a KB was being displayed, and a couple which wrote to locations 0x20, 0x28 when creating a new KB. (All previous versions were subject to these hits.)

# (4 February 1999 Version 1.09 and 1.091 only. Nuisance.) When item blocks are created they are not linked with the box group that expresses them. This does not seem to be a problem in most cases since Istar has built-in redundancy, and several ways to find one from the other. FIXED 4 February 1999.

FIXED BY VERSION 1.09 AND 1.091

# (4 February 1999 all versions; usually no more than a nuisance) For Float variables, when you exit the Attribute Details Panel then it will always consider the value to have changed, even though you have not changed it. This will force a propagation, but normally this makes no difference except to waste a bit of time. The exception is if the consequent fan of the Float attribute has a Random inference method or unary operator in it; then a different random number will be propagated. FIXED 4 February 1999.

# (27 January 1999. Version 1.09 and 1.087. Version 1.086 is OK. Error that maybe cannot be overcome. Fixed 27 January 1999.) Chooser inference method does not seem to work properly with integer first antecedent. It works fine when the chosen antecedents are all Constant, but in other situations none of them are asked, and the inference session ends without having answered the goal. FIXED 27.1.99.

# (Nuisance that can be overcome: Version 1.09, and presumably earlier versions; 1 January 1999) Select a free attribute item type, 'See' it, select its single attribute, 'See' that, and hit the 'Show' checkbox so that it is ticked. What should happen is that boxes drawn for this attribute should then have their values shown. But it doesn't. Instead, a Beep/Flash happens and then we get an ES module error 'Some parameter is wrong'. I will look into it. FIXED 4 January 1999, but left another small bug.

# (Cosmetic) The font used for the number that varies with slider gadgets is usually the Question text, rather than the standard text. It can look odd - or even look good. FIXED 2 January 1999.

FIXED BY VERSION 1.087 Oct-Nov 1998

# (Nuisance during run) When in an inference session with a goal list, the ResetQ button showed only those questions asked for the current goal, rather than since the start of the session. This has been fixed Sep 98.

# (Avoidable crash: most versions before 1.087) If you have an attribute, bring up its attribute action panel and start the inference process and have a question being asked, and then hit the 'Data' button on the action panel to bring up the attribute details panel, and then hit its OK, when you hit the OK of the question being asked, then you get software error 00000003. I don't think it happens if the question sequence is started from the InferGoals button. It seems that the problem occurs because the action panel has been closed before the inference process ends, so that it returns to a wrong panel. 3 November 1998. Fixed 3 Nov 1998.

# (Cosmetic nuisance) Altering font Preferences for question text seemed to have no effect; now does. Font for document was altered when you zoom it; now OK.

FIXED BY VERSION 1.086 March 1998

# (Rare nuisance, avoidable) When you have a UO_CONTROL unary operator to a consequent whose inference method is FirstKnown or Chooser (or perhaps others of that ilk), then when the controlling antecedent is false, the consequent receives a value of zero rather than that in the relationship. To avoid this, change the inference method to e.g. addition, max, bayesian, etc.

# (Rare nuisance) If you had an ORDINAL or ENUM antecedent e.g. Weekdays and tried to set the unary operator to EqualTo, then it would not do so. Now it does. (The bug only affected ORDINALs and ENUMs.) A reason for doing this is to convert an enum to a boolean saying e.g. 'It is Wednesday'.

# (Common problem if you used strings) String concatenation did not work well. String chooser did not work at all. String 'IsIn' and 'HasIn' inference did not work. At least not since 1.06. Fixed 1.086.

# (Rare nuisance) Up to 1.086 with some attribute types you were offered a 'Remove From' inference method (opposite of Concat). It has never been implemented yet. I just suppressed the possibility of using this.

FIXED BY VERSION 1.085 February 1998

# (Can be misleading to user) The explanation of a relationship type is only accurate for simple types; the facility is yet to be finalized. Version 1.04 and earlier.

# (Crash, avoidable, unlikely to be encountered) If you try to save the easel as an IFF file without having iff.library in libs: version 1.084 and earlier would crash. Fixed 1.085.

FIXED BY VERSION 1.084 February 1998

# (Avoidable error in Version 1.08-1.083) If you draw a link in inverse direction (from cons box LHS to ante) then though it looks, and acts visually like an inverse link, it actually is a forward link in the data structures. Avoid by not drawing inverse links. Fixed with version 1.084, and not a problem pre 1.08.

FIXED BY VERSION 1.083 (Feb 98)

# (Nuisance Crash, frequent.) V1.08 (both Dec97 and Jan98 versions) crashed when you hit 'Delete' on Attribute Action Panel. Now it doesn't.

# (Avoidable nuisance Crash.) In V1.08 (both Dec97 and Jan98 versions) if you bring up, say, the Attribute Details Panel and hit the Type button, up comes a simple list of types from which you can choose. In V1.08 (but not before) you could then send the main panel away and the list remains - and if you then hit its 'OK' button Istar would crash. Corrected.

# (Slightly dangerous nuisance) In V1.08 and earlier if something was deleted, but there were panels around that referred to it, then not all were removed - which could lead to a crash. Now, if you delete something, and a panel is up that is for that thing then the whole panel is removed. And in most cases, if a list gadget refers to it, its entry in the list is removed.

FIXED BY (Jan 98) VERSION 1.08

# (Rare nuisance to version 1.08; fixed in version 1.083) If you make up an item type with attributes, and then rearrange the attributes then the resulting box group has the attributes in the wrong order.

# (Only in the early version of v1.08 uploaded around Christmas 1997: Occasional Crash; the real version, uploaded 3-Jan-98 should be OK) If you tried to change the attribute value type on the attribute details panel it could crash. Caused by calling a routine with parameters the wrong way round. Action: Download the new version, or avoid changing value type.

# (Only in the early version of v1.08 uploaded around Christmas 1997: Minor Nuisance; the real version, uploaded 3-Jan-98 should be OK) In new KBs the attribute given to Text Fragment and Insert item types are wrong.

FIXED BY (Early) VERSION 1.08 (Dec 1997)

# (Cosmetic, harmless; PARTLY FIXED) Version 1.02: A Form item does not space out the value gadgets properly always. Some of them are too tall and overlap others. 2 August 1996. This is being investigated. It has been partly cured (still untidy) in Version 1.03.

BY VERSION 1.06 (Feb 1997)

# (Nuisance to end user in versions 1.05 and earlier) The Chooser inference method would only reset its attribute to unanswered every other time, not every time. A bug in dealing with first (index) antecedent. Fixed after 1.05.

# (Nuisance in version 1.04, corrected 1.041) A bug entered V1.04 that I found two days after placing it on Aminet! It would not allow you to change value types in the Attribute Details panel. Immediately corrected it and placed new version 1.041 on Aminet.

# Bug when adding new attribute to items with shown attributes. The new one would be placed on top of old one. Now it's OK; they are placed in a vertical column.

BY VERSION 1.05 (Jan 1997)

# (A freeze if not a crash!) There's an odd sort of bug when Istar runs up on some machines. It's perfectly OK on the three 1200s that I have tried it on (020 and 030). But when I run it up on my 4000 it comes up with the main easel and the SIT (Select Item Type) panel and all, but won't draw, and won't respond to clicks on the main control panel. Until, that is, I click around on the SIT panel. Sometimes dragging the listview scroll bar around helps, and then clicking to select an item type, sometimes clicking on the 'New' button. Then there is a delay of a few seconds, and everything starts as normal. Strange. But, as I say, on my three 1200s it seems perfectly OK. 9.9.96: I have found a possible cause of this and corrected it, but have yet to try it out. No, it does not work yet, Nov 1996. I got an email to say that it froze their 3000 too. While preparing 1.05 I found a slight error in the code, changed it, and then it seemed to work on my 4000 and 3000. So hopefully it's now OK.

BUGS FIXED BY VERSION 1.04 (Nov 1996)

# (Harmless Cosmetic) When you change the name of an item, it doesn't redraw with the new name until F1 or next load. Attribute names refresh OK. Version 1.03 and before.

# (Harmless Nuisance) When trying to resize an item using right-shift, you have to place the mouse *exactly* on the edge of the box: hit-vicinity is zero. Otherwise you will start to draw a link or move the box; if that happens then just hit escape. Version 1.03 and before. (Actually, it was not the need for exact positioning: it required a second attempt. A bug in window switching.)

# (Harmless cosmetic) When you start drawing on the main easel and abort by hitting escape you get a beep-flash. Don't worry: nothing is wrong. Version 1.03 and before.

# (Harmless nuisance) New facility in Version 1.03, Resizing of KBA, doesn't work; it leaves the KBA as it is.

# (Harmless nuisance) The Backup button on the KB Area panel (Version 1.03) has no effect.

# (Harmless cosmetic nuisance) Renaming the KB Area sometimes leaves rubbish characters at the end. Version 1.03.

# (Harmless, cosmetic) When you reset an attribute that is in the middle of a network it propagates the unanswered status OK, but does not show this change in status on the easel. So if the Att is e.g. Bayesian and Shown it retains the solid black line.

# (Frustrating but probably harmless) Version 1.03: When you have two KBs active, and go to the Item Type Panel, and hit the Left or Right RelTypes buttons nothing happens. But when you get rid of all but one then the list of RelTypes appears OK. 5 August 1996. This is being investigated.

BUGS FIXED BY VERSION 1.03 (Sep 1996)

# FIXED. Version 1.02: Never press the three right hand gadgets of the name/meaning bar unless a knowledge base is present. It will probably crash the machine or send it into an infinite loop since they assume one is present. 2 August 1996. This has been corrected in version 1.03.

# Version 1.02: When redirecting a link the DAG cycle detection algorithm sometimes says there is a loop when there is not. 2 August 1996. This is being investigated. 12 September 1996: I have found the bug: it occasionally searched from the wrong node. Now it should be OK in Version 1.03.

# Version 1.02. It occasionally crashed while linking two items. I have found a bug that could do this, and corrected it. Version 1.03 should be OK.


Copyright (c) Andrew Basden 1997.