If you are going to do serious algorithms, it may pay to consider writing
them in Lisp.
(or possibly calling libraries that already exist.)
RJF
> -----Original Message-----
> From: maxima-bounces at math.utexas.edu
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of Alexey Beshenov
> Sent: Thursday, April 10, 2008 8:06 PM
> To: Stavros Macrakis
> Cc: maxima at math.utexas.edu
> Subject: Re: [Maxima] Logic algebra
>
> 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/
>