>
> sage: maxima_calculus("domain:real")
> real
> sage: integrate(e^-x*sinh(sqrt(x)),x,0,oo)
> 1/4*sqrt(pi)*(erf(1) - 1)*e^(1/4) - 1/4*(sqrt(pi)*(erf(1) - 1) - sqrt(pi)
> + 2*e^(-1) - 2)*e^(1/4) + 1/4*sqrt(pi)*e^(1/4) - 1/2*e^(1/4) + 1/2*e^(-3/4)
> sage: _.simplify_rational()
> 1/2*sqrt(pi)*e^(1/
>
> The former seems likely : Maxima's default for domain is "real" (and in
> turns out that my example runs under this assumption). In sage, immediatly
> after the horror reported above :
>
> sage: maxima("domain")
> complex
> sage: maxima("domain:real;")
> real
> sage: maxima("ratsimp(integrat
On Saturday, December 6, 2014 12:59:13 PM UTC-8, Emmanuel Charpentier wrote:
>
>
> It seems that trying to set Maxima's working value of domain via this
> interface is ... ineffective ...
>
> Is that a known problem ?
>
It's not an "interface". It's just a tab completion that gets picked up:
sag
The line
sage: from sympy.solvers.diophantine import *
has nothing to do with the problem.
The problematic line is
sage: gp.Qfb(1,0,-16)
which should initialize a quadratic form. But you get a relatively
explicit error from Pari/gp
? Qfb(1,0,-16)
*** at top-level: Qfb(1,0,-16)
***
In sage 6.5beta2, I find the following incoherence between Sage's Maxima
called from its own command line and from Sage's interface :
Maxima CL :
charpent@asus16-ec:~$ sage -maxima
;;; Loading #P"/usr/local/sage-6.5/local/lib/ecl/sb-bsd-sockets.fas"
;;; Loading #P"/usr/local/sage-6.5/local/lib/ec
Hi, please look at the following unexpected behavior:
sage: from sympy.solvers.diophantine import *
sage: w=gp.Qfb(1,0,-16).qfbsolve(17)
sage: print w
Traceback (most recent call last):
...
TypeError: Error executing code in GP:
CODE:
sage[26]=Qfb(sage[23],sage[24],sage[25]);
PARI/GP ERROR
On 2014-12-05 16:53, William Stein wrote:
I certainly think the design as it is now is extremely consistent with
the rest of Sage and with standard Python programming practices.
Yes, see also
https://docs.python.org/2/glossary.html#term-eafp
--
You received this message because you are subscrib
On 2014-12-06 05:39, kcrisman wrote:
I think in this case because
> Write the integer n as a sum of two integer squares if possible;
and it doesn't give a full list of *all* ways to do so, the ValueError
is appropriate. But if it returned a list of all such squares (warning:
don't try this at
