Richard,
It seems 'ineq' is the only Maxima extra package for inequalities we
have at this moment, and my present target is to make the necessary
changes in order to have it running.
Thanks a lot for your interesting report and ideas.
Mario
> My first reaction to seeing this "ineq" code is that it is broken and
> misguided; my second reaction, after seeing that it was written
> by Leo Harten over 25 years ago was -- maybe it is useful somehow.
> My third reaction is that it is probably misguided.
>
> For example, a>b is nominally an expression that can be
> evaluated as true, false, unknown, or perhaps "not comparable"
> (complex, or floating NaNs, or ??) or "just leave me unevaluated".
> [We ignore semantics of
> languages like C where a>b is also an integer 0 or 1 (converted from
> Boolean).]
>
>
> In the expression below,
>
> (a>b)*c
>
> appears to be multiplying one of these concepts by "c".
>
> The simplifier for multiplication is being hacked to make sense of
> true*c or false*c ??
>
> What is intended by all this is a reduction of inequalities, but it is
> done by a hacking of multiplication (incidentally, slowing down the
> simplification of products of other things, and very probably not working in
> cases
> where there are products of more than two items.)
>
> I view the rule (a<b)*c --> a*c<b*c if c>0 as an attempt
> to implement a rule like this:
>
> (a > b/c) has the same truth value as (a*c>b) if c>0.
>
> or
> (a>b*c) --> (a/c > b) if c>0
>
> If you want to make maxima do something useful, it seems to me that
> what you need a version of "solve" for inequalities. That is, given
> some expression f(x)>g(x), and a distinguished variable, like x,
>
> do inequality_solve(f(x)>g(x),x)
> to get an answer like this.
> x> h(--not-involving-x).
>
> in fact, one could just use the existing solve command since it should
> be clear from the first argument that an inequality is the target.
> And furthermore, one could have multivariate linear or even non-linear
> inequality solving. (Some of the time, anyway).
>
> Some of this could be done using rules (I would suggest defrule), and
> I think that a critical part of each rule should be to distinguish parts
> that
> depend on the variable or variables you are solving for, from the rest.
>
> A working inequality program, even for a subset of cases might be
> good for a "summer of code". I am sure that the other M's have such
> features.
>
> And it would be much more useful task for than trying
> to figure out how to generalize and implement 2*2^k --> 2^(k+1). :)
> RJF
--
Mario Rodriguez Riotorto
www.biomates.net