1. Unknown as a legal var state?
- Posted by Rom <kjehas at frisurf.no> Nov 23, 2002
- 506 views
From: "Juergen Luethje" <jluethje at gmx.de> > The above mentioned use of "nil" is primarily independent of the = problem > of uninstanciated variables, and those things shouldn't be mixed up, I > think. Using nil for such variables looks easy indeed, but I think = it's > also easy to genarate a runtime error (as Euphoria currently does), to > deal with them. The question is to me, what brings more benefit? I feel it would be a great help. I cannot prove that of course, but I = can give you arguments. Look at the example below and try to figure out = how to formulate (N and U and I) as a rule when you are not allowed to = deal with unknown states. It becomes very tricky. On the other hand, if a program has a state for unknown it almost = immediate appears be be smart to the user, giving respons like: "A cannot answer your question .... Because I don't know your user ID" "Response: You are a girl -> yes. Your are a student -> no. You have a = boyfried -> I don't know. You should go on vacation -> I don't know" The power of just 8-10 3-state-logic rules is good enough to represent = the basic legislation about unemployment rules (I did that with = certainty factors ... but that isn't really the right = tool.....3-state-logic is the rigth tool for dealing with exact rules). Rom Example case:=20 Simplified rules for unemployments benefits. How to program such rules? To qualify for unemployment benefits.... 1) you must be a national citizen 2) you must be unemployed 3) you must have earned more than $10000 previous year 4) all facts must be documented The following program produces too many rejections, leading to a row of complains...... boolean N, U, I /* N =3D person is a national citizen U =3D person is unemployed I =3D income previous year was > 10000 */ // Facts N =3D True U =3D True I =3D False // meaning income was < 10000 or documentation was not = submitted if N and U and I then printf( "Accept application") else printf( "Reject application") end if The following program produces too many inquiries about documentation. = Many og these enquiries for more documentation is unnecessary for making = a decision=20 (you may compare this solution to what will happen if you are forced to = instanciate all vars) boolean N, U, I boolean NDocOK, UDocOK, IDocOK // Facts N =3D True NDocOK =3D True U =3D True UDocOK =3D True // unemployment status is verified I =3D True IDocOK =3D False // documentation of income is missing if not( NDocOK and UDocOK oand IDocOK) then printf( "Ask for more documentation") EXIT end if if N and U and I then printf( "Accept application") else printf( "Reject application") end if This is another attempt to program the rules, not 100% right if N and U and I then if NDocOK and UDocOK and IDocOK then -- Accept application else -- Ask for documentation else if (N xor NDocOK) or (U xor UDocOK) or (I xor IDocOK) then -- Ask for clarification else -- Reject application end if;
2. Re: Unknown as a legal var state?
- Posted by Juergen Luethje <jluethje at gmx.de> Nov 24, 2002
- 511 views
Rom wrote: > From: "Juergen Luethje" <jluethje at gmx.de> > >> The above mentioned use of "nil" is primarily independent of the problem >> of uninstanciated variables, and those things shouldn't be mixed up, >> I think. Using nil for such variables looks easy indeed, but I think it's >> also easy to genarate a runtime error (as Euphoria currently does), to >> deal with them. The question is to me, what brings more benefit? [snipped much text about the usefulness of three-valued logic] Rom, it isn't necessary to convince me of the usefulness of three-valued logic in general. I wrote myself in my previous post in this thread: 'I would appreciate it very much, if there were a "3-value-logic" (false/unknown/true) in Euphoria.' But that does not necessarily mean, that I also think that using 'nil' is a good way to deal with uninstanciated variables. Again: Three-valued logic and uninstanciated variables are different topics, which shouldn't be mixed up. Regards, Juergen