integrate(sec(t)*tan(t),t,0,pi/3), why does definite integral of trig functions give error?

[Ben Woodruff]

Hi all. This is my first post to the discussions groups I've been
following for the last 4 months. I used Sage in my first semester
calculus class this last semester, and plan to move every class I can
over to Sage during the next few years. Giving the students something
they can use anywhere they go without forking over thousands of
dollars has a huge advantage. As such, I'm going to start doing a
better job of posting errors when they arise and I can't figure out
how to resolve them.

Here is the issue. When I evaluate

sage: var('t')
sage: integrate(sec(t)*tan(t),t,0,pi/3)

I get the error message

>Traceback (click to the left for traceback)
>...
>Is cos(t) positive, negative, or zero?

I can get the correct solution of 1 by executing

sage: var('t')
sage: F(t)=integrate(sec(t)*tan(t),t)
sage: F(pi/3)-F(0)

Similar issues arise with other trig functions. The command

sage: integrate(csc(x)*cot(x),x,pi/3,pi/2)

gives the error message

>Traceback (click to the left for traceback)
>...
>Is sin(x) positive, negative, or zero?

Any ideas why Sage cannot complete this definite integral? I would
prefer to have Sage give the answers without using an assuming
commands, since by specifying the bounds are between 0 and pi/3 I am
already declaring cos(x)>0 and x to be real.

Could this be related to
http://trac.sagemath.org/sage_trac/ticket/6956

Thanks for the great product.

Ben Woodruff
BYU-Idaho

[Dr. David Kirkby]

Ben Woodruff wrote:
> Hi all. This is my first post to the discussions groups I've been
> following for the last 4 months. I used Sage in my first semester
> calculus class this last semester, and plan to move every class I can
> over to Sage during the next few years. Giving the students something
> they can use anywhere they go without forking over thousands of
> dollars has a huge advantage.

Sorry I can't answer your question. I'm not a Sage user, though I've spent a lot
of time porting Sage to Sun's Solaris operating system, so I will be able to use
it, on what I consider is an excellent operating system. But I could not resist
commenting on one of your points here.

Giving students something they can use outside university is a huge plus which
teaching Sage has compared to teaching Mathematica.

I learned Mathematica as a postgraduate researcher and used it at university
quite a bit. Then when I left university, suddenly I find few places use it.
Most places can't afford to, or insist staff use something cheaper. (At Marconi
Optical Components I had to use Mathcad if I wanted maths software.) A hunt for
jobs mentioning Mathematica on job sites brings up very few hits.

Learning Mathematica is a bit like learning your way around campus - useful
while you are at university, but your might as well forget it once you leave. In
my honest opinion, it is almost irresponsible for universities to teach
Mathematica.

I'm not a fan of Microsoft's products (I use Sun's Solaris rather than Microsoft
Windows most of the time). But nobody can accuse schools of being irresponsible
teaching children Word or Excel, as those skills are wanted by employers. The
same can not be said for Mathematica. I know little about Maple or Macsyma and
accept that MATLAB is wanted by a number of employers.

Of course there are other advantages/disadvantages to open-source software, but
here is not the place for a open-source vs closed-source debate.

Dave

[ma...@mendelu.cz]

On 24 pro, 07:10, Ben Woodruff <bmwoodr...@gmail.com> wrote:
> Hi all. This is my first post to the discussions groups I've been
> following for the last 4 months.  I used Sage in my first semester
> calculus class this last semester, and plan to move every class I can
> over to Sage during the next few years.  Giving the students something
> they can use anywhere they go without forking over thousands of
> dollars has a huge advantage.  As such, I'm going to start doing a
> better job of posting errors when they arise and I can't figure out
> how to resolve them.
>
> Here is the issue.  When I evaluate
>
> sage: var('t')
> sage: integrate(sec(t)*tan(t),t,0,pi/3)
>
> I get the error message
>
> >Traceback (click to the left for traceback)
> >...
> >Is  cos(t)  positive, negative, or zero?
>

Hi Ben

this message is from Maxima. When evaluating integral from 0 to pi/3,
Maxima does not assume automatically 0<t<pi/3
(not sure if thas has been fixed in some recent versions).

Indefinite integral is evaluated via another apporach and this is the
explanation for the fact that the way based on values of primitive
functions works.

> I can get the correct solution of 1 by executing
>
> sage: var('t')
> sage: F(t)=integrate(sec(t)*tan(t),t)
> sage: F(pi/3)-F(0)
>

> Could this be related tohttp://trac.sagemath.org/sage_trac/ticket/6956

No, this is no related.

Happy christmas!
Robert

[Jason Grout]

As others have noted, the assumptions and questions are from maxima.
There has been lots of discussion about this, and one lead maxima
developer has done a lot of work towards removing these questions and
just returning cases, based on the questions. I think at least one
other Sage developer has worked on this sort of thing too.

Here are a few things you can do to get around it:

1. Give the assumption it wants. It mentions this in the error message
(right above the question).

sage: assume(cos(x)>0)
sage: integrate(sec(x)*tan(x),x,0,pi/3)
1

As you point out, in this case, this should be redundant and maxima
should be able to figure it out.

2. Use nintegrate, which uses numerical integration techniques.

sage: (sec(x)*tan(x)).nintegrate(x,0,pi/3)
(0.99999999999999956, 5.3650863533076041e-12, 21, 0)

***NOTE FOR DEVELOPERS*** Why is nintegrate/nintegral not in the
top-level commands???

3. Use an alternative system for evaluating the integral, like sympy or
mathematica_free

***NOTE*** These systems are not documented on the integrate command,
only the integral command.

***NOTE*** There are errors using both of these systems. The
mathematica_free one ignores the bounds of integration. The sympy one
doesn't recognize sec(x). Using sympy with tan(x)/cos(x) also gives an
error because sympy can't do the integral, and Sage doesn't know how to
deal with an unevaluated sympy integral.

sage: integrate(sec(x)*tan(x),x,0,pi/3,algorithm='mathematica_free')
sec(x)
sage: integrate(sec(x)*tan(x),x,0,pi/3,algorithm='sympy')
---------------------------------------------------------------------------
SympifyError Traceback (most recent call last)

/home/grout/.sage/temp/tiny/1970/_home_grout__sage_init_sage_0.py in
<module>()

/home/grout/sage/local/lib/python2.6/site-packages/sage/misc/functional.pyc
in integral(x, *args, **kwds)
566 """
567 if hasattr(x, 'integral'):
--> 568 return x.integral(*args, **kwds)
569 else:
570 from sage.symbolic.ring import SR

/home/grout/sage/local/lib/python2.6/site-packages/sage/symbolic/expression.so
in sage.symbolic.expression.Expression.integral
(sage/symbolic/expression.cpp:25344)()

/home/grout/sage/local/lib/python2.6/site-packages/sage/calculus/calculus.pyc
in integral(expression, v, a, b, algorithm)
671 elif algorithm == 'sympy':
672 import sympy
--> 673 ex = expression._sympy_()
674 v = v._sympy_()
675 if a is None:

/home/grout/sage/local/lib/python2.6/site-packages/sage/symbolic/expression.so
in sage.symbolic.expression.Expression._sympy_
(sage/symbolic/expression.cpp:5779)()

/home/grout/sage/local/lib/python2.6/site-packages/sage/symbolic/expression_conversions.pyc
in __call__(self, ex)
212 div = self.get_fake_div(ex)
213 return self.arithmetic(div, div.operator())
--> 214 return self.arithmetic(ex, operator)
215 elif operator in relation_operators:
216 return self.relation(ex, operator)

/home/grout/sage/local/lib/python2.6/site-packages/sage/symbolic/expression_conversions.pyc
in arithmetic(self, ex, operator)
577 return sympy.Add(*ops)
578 elif operator == "*":
--> 579 return sympy.Mul(*ops)
580 elif operator == "-":
581 return sympy.Sub(*ops)

/home/grout/sage/local/lib/python2.6/site-packages/sympy/core/cache.py
in wrapper(*args, **kw_args)
83 except KeyError:
84 pass
---> 85 func_cache_it_cache[k] = r = func(*args, **kw_args)
86 return r
87

/home/grout/sage/local/lib/python2.6/site-packages/sympy/core/operations.py
in __new__(cls, *args, **assumptions)
30 if len(args)==1:
31 return _sympify(args[0])
---> 32 c_part, nc_part, order_symbols =
cls.flatten(map(_sympify, args))
33 if len(c_part) + len(nc_part) <= 1:
34 if c_part: obj = c_part[0]

/home/grout/sage/local/lib/python2.6/site-packages/sympy/core/sympify.py
in _sympify(a)
191 return v
192
--> 193 raise SympifyError("%r is NOT a valid SymPy expression" % (a,))
194
195

SympifyError: SympifyError: NotImplementedError("SymPy function 'sec'
doesn't exist",) is NOT a valid SymPy expression
sage: integrate(tan(x)/cos(x),x,0,pi/3,algorithm='sympy')
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)

/home/grout/.sage/temp/tiny/2080/_home_grout__sage_init_sage_0.py in
<module>()

/home/grout/sage/local/lib/python2.6/site-packages/sage/misc/functional.pyc
in integral(x, *args, **kwds)
566 """
567 if hasattr(x, 'integral'):
--> 568 return x.integral(*args, **kwds)
569 else:
570 from sage.symbolic.ring import SR

/home/grout/sage/local/lib/python2.6/site-packages/sage/symbolic/expression.so
in sage.symbolic.expression.Expression.integral
(sage/symbolic/expression.cpp:25344)()

/home/grout/sage/local/lib/python2.6/site-packages/sage/calculus/calculus.pyc
in integral(expression, v, a, b, algorithm)
684 return expression.parent()(result)
685 else:
--> 686 return SR(result)
687
688 integrate = integral

/home/grout/sage/local/lib/python2.6/site-packages/sage/structure/parent.so
in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4241)()

/home/grout/sage/local/lib/python2.6/site-packages/sage/symbolic/ring.so
in sage.symbolic.ring.UnderscoreSageMorphism._call_
(sage/symbolic/ring.cpp:6687)()

AttributeError: 'Integral' object has no attribute '_sage_'

So there still is work to do, even on the alternatives.

Thanks,

Jason

[Ben Woodruff]

On Dec 24, 8:13 am, Jason Grout <jason-s...@creativetrax.com> wrote:
Thanks for the reply. Here are some concerns.

> 1. Give the assumption it wants.  It mentions this in the error message
> (right above the question).

Students in first semester calculus will not appreciate having to add
the "assume" command. It will turn them away, especially since the
assumption seem obvious (since they encounter this right after
learning how to optimize and draw functions).

> 2. Use nintegrate, which uses numerical integration techniques.
>
> sage: (sec(x)*tan(x)).nintegrate(x,0,pi/3)
> (0.99999999999999956, 5.3650863533076041e-12, 21, 0)
>
> ***NOTE FOR DEVELOPERS*** Why is nintegrate/nintegral not in the
> top-level commands???
>

I would love to see nintegrate be a top-level command. If it were at
the top level, then i would tell my students, "Any time you encounter
an error with the integrate command, just add an "n" to the front of
it and hit enter again."

Is it simple to make nintegrate a top-level command? I would still
like to see Sage be able to utilize Maxima to integrate trig functions
without adding redundant assumptions, but having nintegrate as a top
level command would greatly help students. Having to switch from
integrate(f,x,a,b) to f.nintegrate(x,a,b) is not a simple obvious
switch for beginning students.

Thanks for the feedback. Should this thread be moved to the developer
group to add nintegrate as a top-level command?
Merry Christmas all,

Ben

[William Stein]

No.

The problem -- which is a serious one -- is that Sage's symbolic
integration is by default done using Maxima (this is currently the
main way in which Maxima is used in Sage; the other big way is for
solving symbolic equations). Maxima has a somewhat weak assumptions
system and was designed in the 1960s when the assumption that a user
was at the terminal happily answering questions -- a sort of
conversation -- was considered reasonable.

Sympy is the only other program in Sage that does symbolic
integration, and you can access it by doing for example

sage: integrate(sin(t),t,0,pi/3, algorithm='sympy')

However, it only works on a small class of fairly simple integrals.

Until we Sage developers write our own symbolic integration
implementation, we'll continue to have similar issues to what you
complain about above. I'm for doing that.

In the meantime, I hope we can find ways around the issues that arise
by using assume.

-- William

[Jason Grout]

Ben Woodruff wrote:
>
> On Dec 24, 8:13 am, Jason Grout <jason-s...@creativetrax.com> wrote:
> Thanks for the reply. Here are some concerns.
>
>> 1. Give the assumption it wants. It mentions this in the error message
>> (right above the question).
>
> Students in first semester calculus will not appreciate having to add
> the "assume" command. It will turn them away, especially since the
> assumption seem obvious (since they encounter this right after
> learning how to optimize and draw functions).
>

I agree.

>> 2. Use nintegrate, which uses numerical integration techniques.
>>
>> sage: (sec(x)*tan(x)).nintegrate(x,0,pi/3)
>> (0.99999999999999956, 5.3650863533076041e-12, 21, 0)
>>
>> ***NOTE FOR DEVELOPERS*** Why is nintegrate/nintegral not in the
>> top-level commands???
>>
>
> I would love to see nintegrate be a top-level command. If it were at
> the top level, then i would tell my students, "Any time you encounter
> an error with the integrate command, just add an "n" to the front of
> it and hit enter again."
>
> Is it simple to make nintegrate a top-level command? I would still
> like to see Sage be able to utilize Maxima to integrate trig functions
> without adding redundant assumptions, but having nintegrate as a top
> level command would greatly help students. Having to switch from
> integrate(f,x,a,b) to f.nintegrate(x,a,b) is not a simple obvious
> switch for beginning students.
>

You can do it with:

sage: nintegrate=sage.calculus.calculus.nintegrate
sage: nintegrate(cos(x), x, 0, pi/2)
(0.99999999999999989, 1.110223024625157e-14, 21, 0)

I once wrote a patch to add nintegrate/nintegral to
sage/devel/sage/misc/functional.py, which just mimicked the
integral/integrate commands already in that file. I can't find it with
a cursory search on trac, but I think that would be what is really
needed here.

> Thanks for the feedback. Should this thread be moved to the developer
> group to add nintegrate as a top-level command?

I've added the issue here:

http://trac.sagemath.org/sage_trac/ticket/7763

Thanks,

Jason

[Martin Rubey]

Jason Grout <jason...@creativetrax.com> writes:

> 3. Use an alternative system for evaluating the integral, like sympy or
> mathematica_free

ceterum censeo:

sage: fricas.integrate('sec(t)*tan(t)','t=0..%pi/3','"noPole"')
1

the noPole argument instructs FriCAS to ignore possible poles that the
integral without limits could have:

sage: fricas.integrate('sec(t)*tan(t)','t')

cos(t) + 1
----------
cos(t)

I admit however, that calling FriCAS from sage is very awkward, since
the interface is absolutely dumb.

I think that's a shame, because FriCAS is quite good at differential
algebra.

Martin

[William Stein]

On Sat, Dec 26, 2009 at 7:18 AM, Martin Rubey
<martin...@math.uni-hannover.de> wrote:
> Jason Grout <jason...@creativetrax.com> writes:
>
>> 3. Use an alternative system for evaluating the integral, like sympy or
>> mathematica_free
>
> ceterum censeo:
>
> sage: fricas.integrate('sec(t)*tan(t)','t=0..%pi/3','"noPole"')
> 1
>
>
> the noPole argument instructs FriCAS to ignore possible poles that the
> integral without limits could have:
>
> sage: fricas.integrate('sec(t)*tan(t)','t')
>
>  cos(t) + 1
>  ----------
>    cos(t)
>
> I admit however, that calling FriCAS from sage is very awkward, since
> the interface is absolutely dumb.

Could you please give constructive criticism instead? I for one
appreciate the work Bill Page did at Sage Days 2 to write an axiom
interface. I think enumerating some specific criticism of it would
be more useful. If you've already done so, maybe you could post a
link?

William

>
> I think that's a shame, because FriCAS is quite good at differential
> algebra.
>
> Martin
>

> --
> To post to this group, send email to sage-s...@googlegroups.com
> To unsubscribe from this group, send email to sage-support...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-support
> URL: http://www.sagemath.org
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[Robert Dodier]

On Dec 24, 11:18 am, William Stein <wst...@gmail.com> wrote:

> The problem -- which is a serious one -- is that Sage's symbolic
> integration is by default done using Maxima (this is currently the
> main way in which Maxima is used in Sage; the other big way is for
> solving symbolic equations). Maxima has a somewhat weak assumptions
> system and was designed in the 1960s when the assumption that a user
> was at the terminal happily answering questions -- a sort of
> conversation -- was considered reasonable.

For the record, I believe that strengthening the assume
system would be the shortest path towards solving the
problem which started this thread.
(As opposed to revising or reimplementing the code
for definite integration.)

FWIW

Robert Dodier

[William Stein]

Cool. I didn't know that. What do you have in mind?

William

[Martin Rubey]

William Stein <wst...@gmail.com> writes:

>> I admit however, that calling FriCAS from sage is very awkward, since
>> the interface is absolutely dumb.
>
> Could you please give constructive criticism instead? I for one
> appreciate the work Bill Page did at Sage Days 2 to write an axiom
> interface. I think enumerating some specific criticism of it would be
> more useful. If you've already done so, maybe you could post a link?

I also think that Bill Page did and does a good job.

The main thing that's missing is a proper way to translate between
fricas and sage types.

Eg: (without understanding the issues involved...)

>> sage: fricas.integrate('sec(t)*tan(t)','t=0..%pi/3','"noPole"')
>> 1

why is it, that I can't write

fricas.integrate(sec(t)*tan(t),(t,0,%pi/3),"noPole")

(and I think that "SegmentBinding", i.e., something of the form

t=a..

or

t=a..b

is something missing from sage. On the other hand, "=" seems to be
reserved for keyword arguments and assignment in python, except that
sage uses it at least in "limit" also in the sense of an equation. I
would have expected "==".)

FriCAS has a type called InputForm, which (in an ideal world) captures
the semantics of any given object. (I guess, it's somewhat similar to
the pickle mechanism?)

I think we would need a FriCAS-SAGE programmer, who implements a
dictionary style translation between the two type systems. But maybe
I'm too optimistic here...

Martin

[Jason Grout]

Martin Rubey wrote:

> why is it, that I can't write
>
> fricas.integrate(sec(t)*tan(t),(t,0,%pi/3),"noPole")
>

Even better (i.e., more consistent) would be:

integrate(sec(t)*tan(t), (t,0,pi/3),
algorithm="fricas",fricas_options="noPole")

Thanks,

Jason

[kcrisman]

>
> > For the record, I believe that strengthening the assume
> > system would be the shortest path towards solving the
> > problem which started this thread.
>

I agree this would probably be easier; unfortunately, it's not clear
that the set of people with time, interest, and expertise in doing
either that *or* writing native Sage solve or integration is
nonempty. Is there some set of threads which might give a sense of
what a framework for doing so would be? There is also the issue that
(at least currently) in Maxima the assumptions are explicitly not
always supposed to be used (such as in solve, correct?), while most
Sage users implicitly seem to desire that once they've assumed x>0, x
better be greater than zero (even if that is inconsistent with
something else the user types in later!). I don't know if that design
difference can be easily bridged or not, though we are trying to do so
in a number of cases.

- kcrisman

[Robert Bradshaw]

On Dec 26, 2009, at 12:42 PM, Martin Rubey wrote:

> William Stein <wst...@gmail.com> writes:
>
>>> I admit however, that calling FriCAS from sage is very awkward,
>>> since
>>> the interface is absolutely dumb.
>>
>> Could you please give constructive criticism instead? I for one
>> appreciate the work Bill Page did at Sage Days 2 to write an axiom
>> interface. I think enumerating some specific criticism of it would
>> be
>> more useful. If you've already done so, maybe you could post a link?
>
> I also think that Bill Page did and does a good job.
>
> The main thing that's missing is a proper way to translate between
> fricas and sage types.

Yes.

> Eg: (without understanding the issues involved...)
>
>>> sage: fricas.integrate('sec(t)*tan(t)','t=0..%pi/3','"noPole"')
>>> 1
>
> why is it, that I can't write
>
> fricas.integrate(sec(t)*tan(t),(t,0,%pi/3),"noPole")

You can do fricas.eval("...any valid fricas command..."), though
fricas.integrate(...) and integrate(..., algorithm='fricas') should
work much better.

> (and I think that "SegmentBinding", i.e., something of the form
>
> t=a..
>
> or
>
> t=a..b
>
> is something missing from sage. On the other hand, "=" seems to be
> reserved for keyword arguments and assignment in python, except that
> sage uses it at least in "limit" also in the sense of an equation.

Yes, that is correct. The decision to stay close to Python is a
constraint in some ways, but in many others is a huge benefit.

> I would have expected "==".)
> FriCAS has a type called InputForm, which (in an ideal world) captures
> the semantics of any given object. (I guess, it's somewhat similar to
> the pickle mechanism?)

Sage has an input form as well:

sage: R.<t> = QQ[]
sage: sage_input(t^3-t)
R.<t> = QQ[]
t^3 - t

sage: R.<t> = GF(101)[]
sage: sage_input(random_matrix(ZZ, 2, 2) + t)
R.<t> = GF(101)[]
matrix(R, [[t, 1], [96, t + 98]])

Pickling is a binary representation, more optimized for compactness
and speed (and also may store pre-computed cached data).

> I think we would need a FriCAS-SAGE programmer, who implements a
> dictionary style translation between the two type systems. But maybe
> I'm too optimistic here...

Well, I'm pretty sure there's not a FriCAS equivalent of every Sage
type, and vice-versa, but even doing a little better would be very
useful (right now, it doesn't do anything that's not just passing
strings back and forth.

- Robert

[Martin Rubey]

ceterum censeo 2:

> The problem -- which is a serious one -- is that Sage's symbolic
> integration is by default done using Maxima (this is currently the
> main way in which Maxima is used in Sage; the other big way is for
> solving symbolic equations).

For my ears (well, eyes :-) this sounds like an insult. (and I'm
certainly not a maxima developer.)

Why don't you just say something like:

| The problem is that Maxima assumes that a user is at the terminal
| answering questions.

(By the way, Christian Krattenthaler's hyp and hyp.q for mathematica are
two brilliant packages that assume the very same thing. This doesn't
make the package less brilliant)

I can imagine (but I don't know) that the maxima developers are
unwilling (or even unable) to change that behaviour. In this case one
could state precisely this:

| And the maxima developers are unwilling/unable to change this
| behaviour.

Statements like the one above are one of the reasons I am unwilling to
really join sage.

Martin

[Martin Rubey]

Robert Bradshaw <robe...@math.washington.edu> writes:

> Sage has an input form as well:
>
> sage: R.<t> = QQ[]
> sage: sage_input(t^3-t)
> R.<t> = QQ[]
> t^3 - t
>
> sage: R.<t> = GF(101)[]
> sage: sage_input(random_matrix(ZZ, 2, 2) + t)
> R.<t> = GF(101)[]
> matrix(R, [[t, 1], [96, t + 98]])

Oh, this is wonderful!

(ideally, i.e., for many types it is not implemented, but it's mostly a
triviality) we'd have something like

($elt (MyType myop) arg1 arg2 ...)

for

myop(arg1, arg2, ...)$MyType

Of course, since there may be several operations myop in MyType, the
types of arg1, arg2, etc. should be specified too.

>> I think we would need a FriCAS-SAGE programmer, who implements a
>> dictionary style translation between the two type systems. But maybe
>> I'm too optimistic here...
>
> Well, I'm pretty sure there's not a FriCAS equivalent of every Sage
> type, and vice-versa, but even doing a little better would be very
> useful (right now, it doesn't do anything that's not just passing
> strings back and forth.

Exactly.

Martin

[Chris Chiasson]

Hi Dave. Nice to see a fellow Mathematica "alum". I have found the
same thing with the lack of Mathematica outside of schools.

On Dec 24, 3:51 am, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:

[William Stein]

On Sun, Dec 27, 2009 at 12:42 AM, Martin Rubey
<martin...@math.uni-hannover.de> wrote:
> ceterum censeo 2:
>
>> The problem -- which is a serious one -- is that Sage's symbolic
>> integration is by default done using Maxima (this is currently the
>> main way in which Maxima is used in Sage; the other big way is for
>> solving symbolic equations).
>
> For my ears (well, eyes :-) this sounds like an insult.  (and I'm
> certainly not a maxima developer.)

We are shipping a central critical component of Sage -- the symbolic
integration function -- which none of us fully understand or know how
to fix bugs in. This *is* a problem. See [1] and [2] for some
discussions about how not understanding the components of your
software can be a serious problem.

-- William

[1] http://www.joelonsoftware.com/articles/fog0000000007.html
[2] http://www.wired.com/magazine/2009/12/fail_duke_nukem/

[Martin Rubey]

William Stein <wst...@gmail.com> writes:

> On Sun, Dec 27, 2009 at 12:42 AM, Martin Rubey
> <martin...@math.uni-hannover.de> wrote:
>> ceterum censeo 2:
>>
>>> The problem -- which is a serious one -- is that Sage's symbolic
>>> integration is by default done using Maxima (this is currently the
>>> main way in which Maxima is used in Sage; the other big way is for
>>> solving symbolic equations).
>>
>> For my ears (well, eyes :-) this sounds like an insult. (and I'm
>> certainly not a maxima developer.)
>
> We are shipping a central critical component of Sage -- the symbolic
> integration function -- which none of us fully understand or know how
> to fix bugs in. This *is* a problem.

If that's the reason (and I agree it's a very good reason), why don't
you state just this?

(it's not a technical issue I criticise, but I hope that's obvious.)

Martin

[William Stein]

On Sun, Dec 27, 2009 at 9:22 AM, Martin Rubey

<martin...@math.uni-hannover.de> wrote:
> William Stein <wst...@gmail.com> writes:
>
>> On Sun, Dec 27, 2009 at 12:42 AM, Martin Rubey
>> <martin...@math.uni-hannover.de> wrote:
>>> ceterum censeo 2:
>>>
>>>> The problem -- which is a serious one -- is that Sage's symbolic
>>>> integration is by default done using Maxima (this is currently the
>>>> main way in which Maxima is used in Sage; the other big way is for
>>>> solving symbolic equations).
>>>
>>> For my ears (well, eyes :-) this sounds like an insult. (and I'm
>>> certainly not a maxima developer.)
>>
>> We are shipping a central critical component of Sage -- the symbolic
>> integration function -- which none of us fully understand  or know how
>> to fix bugs in.  This *is* a problem.
>
> If that's the reason (and I agree it's a very good reason), why don't
> you state just this?

You're absolutely right, I should just state this: We are shipping a

central critical component of Sage -- the symbolic integration
function -- which none of us fully understand or know how to fix bugs
in. This *is* a problem.

William