On Tue, Jul 22, 2003 at 05:19:06AM +0200, Wolfgang Jenkner wrote:
> "Stavros Macrakis" <stavros.macrakis@verizon.net> writes:
>
> > There is an "ineq" share file, but that is just for convenience in
> > *manipulating* inequalities, allowing e.g. x*(a<b) => x*a<x*b (if x>0).
> > (And anyway it doesn't currently even load without error....)
>
> Actually, I (think to have) fixed this some time ago in
>
> http://members.inode.at/wjenkner/maxima/ineq.mac
>
> (at least, ineq.dem works with it).
>
> Wolfgang
>
Hi to everybody and thanks for suggestions.
I have downloaded the members.inode.at/wjenkner/maxima/ineq.mac
and put it instead of the ineq.mac supplied with the Maxima package.
Here is what did I get:
(C1) load(ineq);
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
(D1) /usr/local/maxima-5.9.0/share/maxima/5.9.0/share/simplification/ineq.mac
(C2) assume(a<c, b<d);
(D2) [c > a, d > b]
(C3) is(a+b<c+d);
MACSYMA was unable to evaluate the predicate:
b + a < d + c
-- an error. Quitting. To debug this try DEBUGMODE(TRUE);)
(C4) assume(a>0, b>0);
(D4) [a > 0, b > 0]
(C5) is(a*b<c*d);
MACSYMA was unable to evaluate the predicate:
a b < c d
-- an error. Quitting. To debug this try DEBUGMODE(TRUE);)
(C6) demo(ineq);
batching /usr/local/maxima-5.9.0/share/maxima/5.9.0/share/simplification/ineq.dem
At the _ prompt, type ';' followed by enter to get next demo
(C7) LOAD('ineq)
c a partitions PRODUCT
c a partitions PRODUCT
c a partitions PRODUCT
c a partitions PRODUCT
Is e + a positive, negative, or zero?
pos;
Circular rule attempted - TELLSIMPAFTER
-- an error. Quitting. To debug this try DEBUGMODE(TRUE);)
Maybe, I have to apply that ineq.mac some another way? Which one?
By the way, how to know which files *.mac are loaded when one starts
Maxima?
With the old ineq.mac result is similar:
(C1) load(ineq);
Is d positive, negative, or zero?
pos;
Is d positive, negative, or zero?
pos;
Is d positive, negative, or zero?
pos;
Is d positive, negative, or zero?
pos;
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
g + e partitions SUM
(D1) /usr/local/maxima-5.9.0/share/maxima/5.9.0/share/simplification/ineq.mac
(C2) assume(a<c, b<d);
(D2) [c > a, d > b]
(C3) is(a+b<c+d);
MACSYMA was unable to evaluate the predicate:
b + a < d + c
-- an error. Quitting. To debug this try DEBUGMODE(TRUE);)
(C4) assume(a>0, b>0);
(D4) [a > 0, b > 0]
(C5) is(a*b<c*d);
MACSYMA was unable to evaluate the predicate:
a b < c d
-- an error. Quitting. To debug this try DEBUGMODE(TRUE);)
(C6) demo(ineq);
batching /usr/local/maxima-5.9.0/share/maxima/5.9.0/share/simplification/ineq.dem
At the _ prompt, type ';' followed by enter to get next demo
(C7) LOAD('ineq)
c a partitions PRODUCT
c a partitions PRODUCT
c a partitions PRODUCT
c a partitions PRODUCT
Circular rule attempted - TELLSIMPAFTER
-- an error. Quitting. To debug this try DEBUGMODE(TRUE);)
(C8)
Note: In both trials file ineq.dem was the same (old, as I have not new).
By the way, I have tried Mathematica in PC of my friend.
My opinion is that Maxima is much better for many reasons, including
user interface and clarity. For my definite integrals Mathematica
gives wrong answer silently, while Maxima returns them without
simplification.
My question, is it possible to do something that Maxima could
derive more (all?) correct implications from assumptions and be able
to evaluate lines (C3),(C5), above?
The neccesity of this may be explained as follows.
Maxima is the system which, among other things, manipulates with integrals.
The concept of integral is substantially grounded on the structure
of the set of real numbers. The rules concerning linear inequalities
reflect that structure. The most important rules, such as antisymmetry
( a<b implies not b<a ) and transitivity ((a<b and b<c) implies a<c) (i)
and some others (e.g. a<b implies a+c<b+c ) (ii) are known by Maxima.
But the (C3) correct evaluation is the direct consequence of the
latter two rules:
a<c implies a+b<c+b due to (ii)
b<d implies c+b<d+c due to (ii)
(a+b<c+b and c+b<d+c) implies a+b<c+d due to (i)
It seems normal if in (C3),(C5) the system gives correct
answers automatically. Maybe, if assume() could accept
predicats with "OR" and/or "IMPLIES" one could easily
introduce those natural implcations to the system.
Appreciate any suggestions,
Sincerely,
--
Alexander Vidybida