Ralf Hemmecke wrote:
>
> > PredImplies(a,b) ==
> > --true if a => b in the sense of logical implication
> > --a = "true" => true
> > a=true => true
> > a=b => true
> > false -- added by RDJ: 12/21/82
> > --error() -- for the time being
>
> Truth table rather suggests that this implements "a or not b", i.e. "b
> implies a".
>
Yes, order of arguments is reversed. PredImplies is used only in
places and in all arguments are reversed so the code worked OK.
What I find interesting is that implementation and comments
did not agree and apparently nobody noticed during 29 years.
> What is interesting, though, is the usage of PredImplies. Or rather the
> use of (boot meaning) of =>.
>
AFAICS boot meaning of 'a => b' is the same as Spad meaning of 'a => b',
that is if a is true it exits current block giving b as result.
Of course, Spad requires a to be a Boolean, while Boot allows
any Lisp value.
Shoe implements '=>' using 'COND' while Spad and old Boot use
quite different implementation, but effects are supposed to
be the same.
>
> CondAncestorP(xname,leaves,condition) ==
> -- checks for being a principal ancestor of one of the leaves
> for u in leaves repeat
> u':=first u
> ucond:=
> null rest u => true
> first rest u
> xname = u' or member(xname,first (CatEval u').4) =>
> PredImplies(ucond,condition) => return u'
>
> the => certainly appears in a pile, but what is actually returned if
>
> xname = u' or member(xname,first (CatEval u').4)
>
> is never true?
The rule is that if no value is returned, then value is NIL (=false).
>
> In fact, it's a pitty that they did not have version control 30 years
> back. The code looks rather strange. For example,
>
> if ancindex and (PredImplies(anccond,condition); true)
> -- I have no idea who effectively commented out the predImplies
> -- JHD 25/8/86
>
> might have to do with the fact that PredImplies did not behave as
> specified. Or someone was translating that into
>
> if ancindex and (anccond => condition; true)
>
> where => is used in its BOOT meaning rather than its logical meaning.
>
> Very strange!!!
Actually, which branch is taken does not matter much: each will
add new condition. Old version used this comparison to decide
position in category vector to store name of category appearing
in the condition. The stored names were unused, so both versions
were equally correct. However, the one with 'true' used less
space...
To say the truth the code of 'JoinInner' looks like exercise in
writing obfuscated code.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
