On Friday 11 April 2008 01:50, Stavros Macrakis wrote:
> The binding strengths need to be adjusted.
Right, now they are correct only wrt internal operators of logic.mac.
> logicexprp(%pi) => true
Now it accepts any atom. Of course, it shouldn't be so; I think there should
be a feature which marks symbols as "logic":
(%o1) declare (logic, feature)$
(%o2) declare (x, logic)$
(%o3) declare ("AND", logic)$
etc.
> Various elementary simplifications are missing:
>
> x EQ NOT x doesn't simplify to 0
> x IMPL x doesn't simplify to 1
> NOT x IMPL x doesn't simplify to x
Yes, this stuff must be added.
> x NAND x etc. doesn't simplify to NOT x
> etc.
It's a bad idea since it may be undesirable to introduce the logical NOT
function. By default, package should apply only simplification rules which
are not affect basis.
> functionallycompletep seems to be inconsistent about whether constant
> symbols/nullary functions need to be included.
It really needs 1 and 0 to be listed explicitly. Implicit usage of constants
are allowed for a weak completeness, but functionallycompletep(...) tests
system on a strong completeness.
For example, {AND,XOR} is complete in a weak sense, but there is no way to get
constant 1 from AND and XOR, so it's not complete in a strong sense.
Maybe, distinct test on a weak completeness should be added.
> demorgan is indented incorrectly, implying that you intended something
> different.
> [...]
> In dualfunction, same indentation problem
Yes, it's a typo---parenthesis must be added.
> zhegalkin is extremely slow in some cases. On my machine, zhegalkin(a
> AND b AND (NOT c) AND (NOT d) OR a AND (NOT b) AND c AND (NOT d) OR a
> AND (NOT b) AND (NOT c) AND d OR (NOT a) AND b AND c AND (NOT d) OR
> (NOT a) AND b AND (NOT c) AND d OR (NOT a) AND (NOT b) AND c AND d)
> takes 4.5 secs. Is this normal?
It performs a kind of expand(...) for Zhegalkin polynomials and it relies on
pattern-matching (also, it seems that it does redundant things). I know, it's
a very bad idea.
By the way, it would be nice to have ability to tell simplifier that op1 is
distributive wrt op2 and expand expressions involving op1 and op2.
> Anyway, as I mentioned before, the ev function should almost *never*
> be used in programming.
I guess it's the only usage of ev in that code, and it will be dropped.
> Using 0 and 1 for false and true is incompatible with Maxima
> conventions so you have to do something like logical(oddp(x)) (where
> logical converts) instead of simply oddp(x). This seems pointless.
0 and 1 are used for shorter I/O.
--
Alexey Beshenov <al at beshenov.ru>
http://beshenov.ru/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.math.utexas.edu/pipermail/maxima/attachments/20080411/156575b5/attachment-0001.pgp