Function assume() has no effect on Maxima via desolve()
lutusp
In examining past thread on this issue, I am unable to tell if this
bug is seen as resolved, but ... it isn't.
Sage 4.5.3 compiled locally on a Linux platform.
sage: reset()
sage: var('g t')
sage: x = function('x',t)
sage: forget()
sage: assume(g > 0)
sage: de = x - g * diff(x,t,2)
sage: desolve(de,x,ivar=t)
Traceback (most recent call last): desolve(de,x,ivar=t)
File "", line 1, in <module>
File "/tmp/tmpK3xCAC/___code___.py", line 9, in <module>
exec compile(u'desolve(de,x,ivar=t)
File "", line 1, in <module>
File "/netbackup/downloads/aaa_Linux/sage_foss_mathematics/
sage-4.5.3/local/lib/python2.6/site-packages/sage/calculus/
desolvers.py", line 340, in desolve
soln = maxima(cmd)
File "/netbackup/downloads/aaa_Linux/sage_foss_mathematics/
sage-4.5.3/local/lib/python2.6/site-packages/sage/interfaces/
expect.py", line 1032, in __call__
return cls(self, x, name=name)
File "/netbackup/downloads/aaa_Linux/sage_foss_mathematics/
sage-4.5.3/local/lib/python2.6/site-packages/sage/interfaces/
expect.py", line 1451, in __init__
raise TypeError, x
TypeError: Computation failed since Maxima requested additional
constraints (try the command 'assume(g>0)' before integral or limit
evaluation, for example):
Is g positive or negative?
If I replace "assume(g > 0)" with
"sage.calculus.calculus.maxima.assume(g > 0)", no difference.
Burcin Erocal
lutusp <lut...@gmail.com> wrote:
> Dear group:
>
> In examining past thread on this issue, I am unable to tell if this
> bug is seen as resolved, but ... it isn't.
See #9835 and #9961 on the issue tracker. The patch by Robert
Marik attached to #9835 solves the problem you show below.
Cheers,
Burcin
rjf
If Macsyma were to be redesigned from the ground up, the issues
related to assume etc would probably be addressed at a foundational
level.
To the extent that other computer algebra systems claim to be a fresh
look at issues, it appears that they have all failed to address this
one.
Instead they ignore "assumptions" and later patch them on in peculiar
ways
and provide access to this information only from some specific
programs, e.g
Mathematica's Integrate, Reduce, Simplify. But probably not much
else.
So this known problem (at least since 1974) was off the radar of the
brainiacs
who designed all those subsequent systems, including I suppose, Sage.
I don't know if "desolve" uses any assumptions, but I would not be
surprised if it
didn't, at all. except perhaps (and this too is hardly guaranteed)
through
definite integration. But Macsyma's defint and limit programs were
written before the
assumption system, I think, and may not make full use of such things.
And then of course the assumption system is not as smart as it could
possibly be,
nor is it as expensive as a smarter system would be.
RJF
Burcin Erocal
rjf <fat...@gmail.com> wrote:
> Many features in Maxima do not use the "assume" features at all.
> If Macsyma were to be redesigned from the ground up, the issues
> related to assume etc would probably be addressed at a foundational
> level.
>
> To the extent that other computer algebra systems claim to be a fresh
> look at issues, it appears that they have all failed to address this
> one.
>
> Instead they ignore "assumptions" and later patch them on in peculiar
> ways
> and provide access to this information only from some specific
> programs, e.g
> Mathematica's Integrate, Reduce, Simplify. But probably not much
> else.
>
> So this known problem (at least since 1974) was off the radar of the
> brainiacs
> who designed all those subsequent systems, including I suppose, Sage.
I think it would be a huge overstatement to say that the symbolics
subsystem in Sage was "designed" in any way. IMHO, it was mostly
patched together to support educational use, then acquired more cruft
through several rewrite attempts and cramped schedules.
I am definitely not an expert in this field and have no idea how the
assumptions should work. If you can provide some references, perhaps
these could be used as starting points when/if somebody decides to
work on this.
Here is the only reference I found on this topic:
http://portal.acm.org/citation.cfm?id=680466
The article is available for download here (for those with access):
http://www.springerlink.com/content/p77364025wh6j7h5/
Burcin
kcrisman
> > So this known problem (at least since 1974) was off the radar of the
> > brainiacs
> > who designed all those subsequent systems, including I suppose, Sage.
>
> I think it would be a huge overstatement to say that the symbolics
> subsystem in Sage was "designed" in any way. IMHO, it was mostly
> patched together to support educational use, then acquired more cruft
> through several rewrite attempts and cramped schedules.
say that it was patched together using Maxima's assumption framework,
since that was the best thing going inside of Sage for this purpose.
- kcrisman
Tim Daly
1/x provided x != 0
I did thesis work in this area. One of the attacks is to use
cylindrical algebraic decomposition (CAD). A second approach
is to create a tree of expressions based on intervals such as
[1/x where x < 0] [1/x where x = 0] [1/x where x > 0]
The computation proceeds in 3 parts, each one under an interval
assumption. If a new proviso is added the program tree-forks again:
[1/x where x < 0 && 1/y where y < 0]
[1/x where x < 0 && 1/y where y = 0]
[1/x where x < 0 && 1/y where y > 0]
[1/x where x = 0 && 1/y where y < 0]
[1/x where x = 0 && 1/y where y = 0]
[1/x where x = 0 && 1/y where y > 0]
[1/x where x > 0 && 1/y where y < 0]
[1/x where x > 0 && 1/y where y = 0]
[1/x where x > 0 && 1/y where y > 0]
Note that these can all be run in parallel and the results
combined after the computation. This approach lends itself
to massively parallel computations.
I did a literature analysis of a couple hundred textbooks
and found that approximately 80 percent of all equation
provisos could be rewritten into interval constraints.
A simple "assume" facility does not begin to address the
problem for many reasons, such as the fact that provisos
can arise during intermediate computations.
Tim Daly
rjf
On Sep 23, 5:36 am, Burcin Erocal <bur...@erocal.org> wrote:
> I think it would be a huge overstatement to say that the symbolics
> subsystem in Sage was "designed" in any way. IMHO, it was mostly
> patched together to support educational use, then acquired more cruft
> through several rewrite attempts and cramped schedules.
In terms of my own interests, that is why the idea of rewriting Maxima
in
Python is pointless. Wouldn't you prefer to write a system that
addressed
the shortcomings of Macsyma (etc.) And by shortcomings I don't mean
"written in Lisp instead of Python".
There are perhaps papers hinting at the Macsyma "assume" system
capabilities by Michael Genesereth, but a quick search did not reveal
them.
The Maple system has a more ambitious capability, but it is still
patched on.
I do not know where the Mathematica version contains, at the moment.
It
seems to grow, every so often. But it is still patched on. The note
from
Tim suggests that (I think) linear inequalities and rectangular
regions can
encode most conditions of interest. Or maybe polynomial conditions?
Certainly not all. And cylindrical algebraic decomposition may be
useful, though
potentially quite expensive, there is all that other stuff that is not
algebraic.
Like log, exp, cos, ...
>
> I am definitely not an expert in this field and have no idea how the
> assumptions should work. If you can provide some references, perhaps
> these could be used as starting points when/if somebody decides to
> work on this.
the next time you design a system. Unfortunately, Sage is already
built, and it
is probably too late. But Stein is doing something else, so you don't
have
to worry about him getting in the way. Maybe UberSage; you can call
Sage
if you need to.
Tim Daly
it be deeply embedded in the algorithms. Whenever an algorithm
(say, division) did an operation that involved a proviso it would
need to (a) decorate the result with the proviso and (b) potentially
split the answer into separate sub-answers for further computation.
Note that I did not make any restrictions on the provisos so they
could be anything (not even necessarily computable), such as polynomials
or roots (e.g. [x suchthat x in roots of ....] and they don't need to
be intervals (e.g. f(x) is holonomic, the so-called "is" provisos).
There are deep research questions here involving reformulating normal
algorithmic computations to collect the provisos, splitting the
collection into (not necessarily decidable) disjoint sets, doing
parallel computation under a proviso set (generating further subsets
as the computation proceeds), combining partial results to poison
other branches of the parallel computation tree (which implies computing
partial CAD results and a "blackboard architecture") and the question
of combining results under proviso constraints (e.g. combining intervals
if the representations are intervals, in order to recover the real line
or the complex plane).
There is a whole research program here but the NSF doesn't seem to know
or care so its unlikely to be explored except by open source. Axiom has
a long term goal of refactoring the algebra to include this in the design
at the fundamental level (which was the point of the thesis work). It is
only in recent years that hundred-core machines are becoming available to
support the huge parallel trees this generates. A proviso-based system
will enable parallel computation in a "natural" manner as opposed to the
current ideas that depend on simple cases (like matrix multiply).
An "assume" facility that is bolted-on after the fact cannot possibly
handle issues that arise as part of the computation since intermediate
expressions can contain computations that are not apparent in the final
result. An assume facility could create some initial conditions but would
naturally be expressed using something like Axiom's "suchthat".
Tim Daly
lutusp
> Marik attached to #9835 solves the problem you show below.
posted example.
kcrisman
On Sep 23, 11:19 am, rjf <fate...@gmail.com> wrote:
> On Sep 23, 5:36 am, Burcin Erocal <bur...@erocal.org> wrote:
>
> > I think it would be a huge overstatement to say that the symbolics
> > subsystem in Sage was "designed" in any way. IMHO, it was mostly
> > patched together to support educational use, then acquired more cruft
> > through several rewrite attempts and cramped schedules.
>
> I think that is true of ALL the subsystems in Sage.
case for large portions of Sage. In particular the sage-combinat and
much of the algebraic geometry/number theory piece are definitely
designed, certainly by this point.
> In terms of my own interests, that is why the idea of rewriting Maxima
> in
> Python is pointless.
mathematician who would rather *use* math software than create the
perfect one. And neither is that of the practicing neuroscientist,
etc., who just wants easy access to something like our new Brian
experimental package along with some other mathematics. That's fine,
but not relevant in a normative sense.
> Wouldn't you prefer to write a system that
> addressed
> the shortcomings of Macsyma (etc.)
directly related to those shortcomings. For most of those on this
list, we would prefer to contribute to a system that has
1) Killer app in web-based interface
2) Has cutting-edge combinatorics and algebraic functionality
3) Has access to huge amounts of other libraries
That could have been Maxima, no doubt! But for whatever reason its
development went in other directions. That's fine. Maxima also wants
everything 'in-house'; that's fine too; Sage prefers to use Python to
glue other high-quality projects together with its (substantial) new
code.
I still don't know why you don't consider the truly new code in those
areas to be interesting, but I suppose we all have the occupational
hazard of overspecialization; I certainly do.
> And by shortcomings I don't mean
> "written in Lisp instead of Python".
>
that someone who is not a computer scientist by training might
actually be able to contribute, of course it isn't in the sense of how
to write a high-level symbolic program. But that doesn't happen to be
a goal of this project, though of course we are grateful to the GPL
for allowing us to use the constantly improving symbolics in Maxima.
And if anyone with Lisp knowledge ever reviews Nils Bruin's patch to
make library access to Maxima the default, it will even be fast :) so
we won't complain about that any more.
But please don't make these blanket statements about the whole content
of Sage until you are familiar with all those subsystems. As I've
said before, and will likely say again :) Still, it's worth saying.
All the best,
- kcrisman
rjf
On Sep 23, 7:43 pm, kcrisman <kcris...@gmail.com> wrote:
> On Sep 23, 11:19 am, rjf <fate...@gmail.com> wrote:
>
> > On Sep 23, 5:36 am, Burcin Erocal <bur...@erocal.org> wrote:
>
> > > I think it would be a huge overstatement to say that the symbolics
> > > subsystem in Sage was "designed" in any way. IMHO, it was mostly
> > > patched together to support educational use, then acquired more cruft
> > > through several rewrite attempts and cramped schedules.
>
> > I think that is true of ALL the subsystems in Sage.
>
> As we have tried to convince you before, this is very much NOT the
> case for large portions of Sage. In particular the sage-combinat and
> much of the algebraic geometry/number theory piece are definitely
> designed, certainly by this point.
written
specifically for Sage, they may play better. Or they may play better
simply
because the specifications are sufficiently clear that these parts do
not
require constant reconsideration. Just as Maxima would have very few
surprises if you used it for (say) polynomial arithmetic over the
integers.
(Of course for that domain you could use any number of pre-built
programs,
or you could write your own in Python if you have bignums.)
>
> > In terms of my own interests, that is why the idea of rewriting Maxima
> > in
> > Python is pointless.
>
> But your interests are not quite the same as that of a practicing
> mathematician who would rather *use* math software than create the
> perfect one.
Python
are not the same as those of a practicing mathematician, either.
And neither is that of the practicing neuroscientist,
> etc., who just wants easy access to something like our new Brian
> experimental package along with some other mathematics. That's fine,
> but not relevant in a normative sense.
> > Wouldn't you prefer to write a system that
> > addressed
> > the shortcomings of Macsyma (etc.)
>
> No. That would be a very good idea for someone whose research is
> directly related to those shortcomings.
Magma, Maple, Mathematica and Matlab.
> For most of those on this
> list, we would prefer to contribute to a system that has
>
> 1) Killer app in web-based interface
geometry? The closest anyone seems to have
come to a killer app is education. (Probably pre-calculus). Possibly,
"do my calculus homework", but
that's more limited.
> 2) Has cutting-edge combinatorics and algebraic functionality
to write their own programs, and
anyone else's program is either not computing the right thing, or is
too general and hence too slow.
This may easily be mistaken, since I'm judging from very few examples.
> 3) Has access to huge amounts of other libraries
libraries with what they need.
If they are forced to use a huge collection of probably irrelevant
cruft, they balk. That's certainly
my reaction to (say) "improved" Excel.
> That could have been Maxima, no doubt! But for whatever reason its
> development went in other directions. That's fine. Maxima also wants
> everything 'in-house'; that's fine too;
large
scientific libraries. BLAS, Lapack, Minpack, Slatec, quadpack.
Slatec has about 24,000 lines of code.
Sage prefers to use Python to
> glue other high-quality projects together with its (substantial) new
> code.
This
can be done by automatically converting fortran to lisp, or linking
code in
other languages e.g. as front-end or as plotting back-end. A better
way, but
not entirely portable is to use a foreign-function interface to load
libraries.
I use it frequently for accessing libraries written in C, C++,
assembler...
but only on the lisp I'm using, and not part of distributed Maxima.
>
> I still don't know why you don't consider the truly new code in those
> areas to be interesting, but I suppose we all have the occupational
> hazard of overspecialization; I certainly do.
quite
right that I don't find it interesting. And therefore putting it into
Sage, or
making it accessible only if you use Sage, or praising Sage because
it includes such code, is pretty much irrelevant.
>
> > And by shortcomings I don't mean
> > "written in Lisp instead of Python".
>
> Although this is a shortcoming in the sense that it is far more likely
> that someone who is not a computer scientist by training might
> actually be able to contribute, of course it isn't in the sense of how
> to write a high-level symbolic program.
Someone who finds Lisp too difficult to learn and instead decides
to (re)write symbolic math basics in Python in order to contribute to
the state of the art will likely (1) spend all the time writing basics
and never advance the state of the art; (2) have an inferior program.
> But that doesn't happen to be
> a goal of this project,
in python,
especially appropriate for summer-high-school students.
> though of course we are grateful to the GPL
> for allowing us to use the constantly improving symbolics in Maxima.
> And if anyone with Lisp knowledge ever reviews Nils Bruin's patch to
> make library access to Maxima the default, it will even be fast :) so
> we won't complain about that any more.
>
> But please don't make these blanket statements about the whole content
> of Sage until you are familiar with all those subsystems.
comments, e.g.
<sarcasm> I'm sure that Sage is the ultimate design for math </
sarcasm>
> As I've
> said before, and will likely say again :) Still, it's worth saying.
>
> All the best,
> - kcrisman
RJF
kcrisman
this, since we've had this discussion before, except to clarify two
things.
> > 1) Killer app in web-based interface
> > 3) Has access to huge amounts of other libraries
>
> I think that people do not generally want huge libraries. They want
more, as I understand it, but there are an awful lot of Python
libraries out there for just about anything scientific.
Also thanks for the clarification on Maxima also importing scientific
libraries of certain kinds. Doesn't make it an elephant!
- kcrisman