[Maxima-discuss] Comments and invitation

[Dimiter Prodanov]

Dear Richard,

I also think it is a good idea to start with a requirements list.
From my side I think that the default domain should always stay real.

Complex numbers are extremely useful but they are only one species of
Clifford algebra.
So instead of complex I would rather say "vector" - that is a number with a
real magnitude and defined direction.

In any case complex numbers in Maxima are of the form a+%i*b with a,b real
so having an explicit complex type begs for bugs.
I see no use of "imaginary" for that reason.


Having a "rational"/"irrational" type would make sense only for rational
simplification since rational numbers can be embedded in real intervals.

"analytic" is nicely undocumented so it's anyone's guess what it does.

My use case is to declare a symbol of certain "feature" and then to look
for it in expressions for simplification purposes.

A useful shortcut will be once a feature is declared to also produce the
predicate function

declare ("vector", feature)

will then also produce

vector(p)

and so on...

best regards,

Dimiter

----------

Message: 6
Date: Tue, 18 Jul 2017 14:25:42 -0700
assume()... was Re: simplifcation of (-a)^x for a > 0
Content-Type: text/plain; charset="utf-8"; Format="flowed"
It is perhaps worth presenting a list of what we would
like assume and "is" to do, in one place, and see how
much of it (a) works, (b) doesn't work,
(c) can be made to work,
(d) probably is too hard.
There seem to be several not necessarily conflicting,
lines of reasoning.
One is *types or categories*, using "declare" to establish
features such as integer, real, complex rational, even, odd.
(see ? features).
We can reason that an integer is necessarily real.
We have integerp(3) returns true.
declare(q,integer); integerp(q) returns false.
We can use lisp ?floatp(3.0) which returns true.
Another is "*mathematical facts*" and implications... such as
is (sin(x)^2>=0) which returns true
although sin(%i)^2 is -1.38, so the answer is incorrect.
Does assume() believe that x is real?
Setting domain:complex does not change this.
Arguably, we could have a simplification like
is (sin(x)^2>=0) simplifies to is( x an element of reals)?
Another is *deductions from **assumption data base of user f**acts*
assume(x>4);
is (x^2>16) returns true.
This kind of reasoning could be made algorithmic, for certain
kinds of assumptions. I have not looked at this recently, but
I think it is not hard to allow assumptions of linear combinations
of indeterminates like assume(3*x+4*y > 10). Such equations
determine planes or hyperplanes whose intersections can
be identified. allowing arbitrary polynomial equations is
computable at some expense via "cylindrical algebraic decomposition"
I think.
Arguably there is another source of information, the
*predicates associated with patterns*, e.g. matchdeclare(a,freeof(x)).
I invite interested parties to add to this email and send it out
again. Also, anyone interested in understanding, describing,
extending what Maxima does, should consider this as
an interesting opportunity. There is a literature on Mathematical
Knowledge Manipulation that should be, but mostly is not,
connected with computer algebra systems like Maxima.
RJF
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
**********************************************

[Richard Fateman]

Post by Dimiter Prodanov
Dear Richard,
I also think it is a good idea to start with a requirements list.
From my side I think that the default domain should always stay real.

Some of this domain specification is pushed from the computer
programming language
side. Outside the computer algebra system community (and now also
inside it) there
is a move toward "object oriented" computing (including Lisp).

This means that every data item is explicitly or implicitly
a member of some class of object with operations specific to that
class. Thus
simplify(foo), or in some languages foo.simplify or in lisp,
(simplify foo) is
treated as "look up the "simplify" procedure or message on the vector
of procedures
associated with the type of the object foo, and invoke that on foo".
Maxima is
implemented on top of Common Lisp which has an especially complete
Object System
(CLOS). Anyway, I explain this because I didn't really distinguish 2
views of this.
The Lisp object could be a number 3 with Lisp type integer or fixnum. The
Lisp object 3.0d0 is type double-float. From Maxima's perspective,
maybe they
are both "real". Or "complex" with realpart of 0. So there a type
associated with
the data format, and a different type associated with the mathematical
intention.

It is possible to construct a lisp complex constant in Maxima via
:lisp (setf $k $c(3 5))
and you can compute k^2 correctly. You get an error for sin(k), though
:lisp (sin $k) works
to get a float complex.
RJF

Post by Dimiter Prodanov
Complex numbers are extremely useful but they are only one species of
Clifford algebra.
So instead of complex I would rather say "vector" - that is a number
with a real magnitude and defined direction.
In any case complex numbers in Maxima are of the form a+%i*b with a,b
real so having an explicit complex type begs for bugs.
I see no use of "imaginary" for that reason.
Having a "rational"/"irrational" type would make sense only for
rational simplification since rational numbers can be embedded in
real intervals.
"analytic" is nicely undocumented so it's anyone's guess what it does.
My use case is to declare a symbol of certain "feature" and then to
look for it in expressions for simplification purposes.
A useful shortcut will be once a feature is declared to also produce
the predicate function
declare ("vector", feature)
will then also produce
vector(p)
and so on...
best regards,
Dimiter
----------
Message: 6
Date: Tue, 18 Jul 2017 14:25:42 -0700
assume()... was Re: simplifcation of (-a)^x for a > 0
Content-Type: text/plain; charset="utf-8"; Format="flowed"
It is perhaps worth presenting a list of what we would
like assume and "is" to do, in one place, and see how
much of it (a) works, (b) doesn't work,
(c) can be made to work,
(d) probably is too hard.
There seem to be several not necessarily conflicting,
lines of reasoning.
One is *types or categories*, using "declare" to establish
features such as integer, real, complex rational, even, odd.
(see ? features).
We can reason that an integer is necessarily real.
We have integerp(3) returns true.
declare(q,integer); integerp(q) returns false.
We can use lisp ?floatp(3.0) which returns true.
Another is "*mathematical facts*" and implications... such as
is (sin(x)^2>=0) which returns true
although sin(%i)^2 is -1.38, so the answer is incorrect.
Does assume() believe that x is real?
Setting domain:complex does not change this.
Arguably, we could have a simplification like
is (sin(x)^2>=0) simplifies to is( x an element of reals)?
Another is *deductions from **assumption data base of user f**acts*
assume(x>4);
is (x^2>16) returns true.
This kind of reasoning could be made algorithmic, for certain
kinds of assumptions. I have not looked at this recently, but
I think it is not hard to allow assumptions of linear combinations
of indeterminates like assume(3*x+4*y > 10). Such equations
determine planes or hyperplanes whose intersections can
be identified. allowing arbitrary polynomial equations is
computable at some expense via "cylindrical algebraic decomposition"
I think.
Arguably there is another source of information, the
*predicates associated with patterns*, e.g.
matchdeclare(a,freeof(x)).
I invite interested parties to add to this email and send it out
again. Also, anyone interested in understanding, describing,
extending what Maxima does, should consider this as
an interesting opportunity. There is a literature on Mathematical
Knowledge Manipulation that should be, but mostly is not,
connected with computer algebra systems like Maxima.
RJF