Followup
Message 
Date: 20130111 10:42 Sender: Christoph Lauter
The bug is gone. Closing the tracker.  Date: 20120215 16:52 Sender: Sylvain Chevillard
Should be patched in revision 1640. @Christoph: please doublecheck and close.  Date: 20120215 16:12 Sender: Christoph Lauter
Additionnally, both functions should emit the warning
SOLLYA_MSG_DOMAIN_IS_NO_CLOSED_INTERVAL_ON_THE_REALS
for all domains that are not a closed subset of the reals.
 Date: 20120109 11:10 Sender: Christoph Lauter
Okay, patch it.
 Date: 20120109 11:01 Sender: Sylvain Chevillard
I forgot a word in my previous post, which made it obscure.
Here is an uptodate output of Sollya on this example: > integral(exp(x),[infty,0]); [@Inf@;@Inf@] > dirtyintegral(exp(x),[infty,0]); 0
The behavior of dirtyintegral does not match the specif ("The interval must be bound. If the interval contains one of Inf or +Inf, the result of dirtyintegral is NaN, even if the integral has a meaning.")
The behavior of integral does not match the specif either. I guess that the previous answer ([NaN, +Inf]) became [+Inf, +Inf] when we wrote sollya_mpfi. Anyway, if intervals are not allowed to contain NaN anymore, the only correct answer would be [Inf, +Inf].
 Date: 20120109 10:44 Sender: Christoph Lauter
"The behavior of the command 'integral' respects the specifications.
vs.
The behavior does not respect the specif. "
To be correct or not to be correct, that's the question.
Sylvain: could you please comment again?
 Date: 20100415 20:44 Sender: Christoph Lauter
@Sylvain: it is long ago that I did some integrals by hand so I am a little rusty. But I still feel that
> dirtyintegral(exp(x),[infty;0]); 0
is a wrong answer:
int(exp(x),infty,0) = [exp(x)]^0_{\infty} = exp(0)  lim(exp(x),x>infty) = exp(0)  0 = 1 != 0
 Date: 20100415 14:53 Sender: Sylvain Chevillard
The behavior of the command 'integral' respects the specifications. I agree that we could add some warning, but it is not necessary, strictly speaking.
The behavior does not respect the specif. I will change its behavior. Here again, we could add some warning, but it is not required.
@Christoph: please comment on this message. 
