On Wednesday, June 20, 2018 at 5:43:06 PM UTC-7, Michael Orlitzky wrote:
>
> Better yet, set it back to whatever it was originally.
>
Actually, at the moment "whatever it originally was" should be "domain:
complex". There's no management of that status flag. If there should be
then some
OK, I get a stack overflow with this example:
domain:complex;
assume(m1>0,m2>0);
A : (--r23^2)+r13^2+r12^2)*(
On 06/20/2018 04:21 PM, Nils Bruin wrote:
>
> Hm, if you intend to use that in sage library code, do remember to
> change back the state to domain:complex when you're done
Better yet, set it back to whatever it was originally.
--
You received this message because you are subscribed to the
On Wednesday, June 20, 2018 at 1:45:16 PM UTC-7, Richard_L wrote:
>
> Is this potentially the same bug as Maxima's #3324?
> (to which both Robert and Nils contributed last year)
>
> Advice please: Should I start a new ticket at Maxima, or add to the old
> one?
>
The causes could well be related,
Is this potentially the same bug as Maxima's #3324?
(to which both Robert and Nils contributed last year)
Advice please: Should I start a new ticket at Maxima, or add to the old one?
Thanks
On Wednesday, June 20, 2018 at 11:57:58 AM UTC-7, Richard_L wrote:
>
> Thank you.
> Now to report the
On Wednesday, June 20, 2018 at 12:01:50 PM UTC-7, Eric Gourgoulhon wrote:
>
> Le mercredi 20 juin 2018 00:22:07 UTC+2, Nils Bruin a écrit :
>>
>> On Tuesday, June 19, 2018 at 2:30:46 PM UTC-7, Richard_L wrote:
>>>
>>> It would be useful if one could override Sage's default
>>> "domain:complex",
Le mercredi 20 juin 2018 00:22:07 UTC+2, Nils Bruin a écrit :
>
> On Tuesday, June 19, 2018 at 2:30:46 PM UTC-7, Richard_L wrote:
>>
>> It would be useful if one could override Sage's default "domain:complex",
>> at least until the Maxima fix comes through.
>>
>> One can:
Thank you.
Now to report the bug.
On Wednesday, June 20, 2018 at 11:15:36 AM UTC-7, Nils Bruin wrote:
>
> On Wednesday, June 20, 2018 at 10:12:24 AM UTC-7, Richard_L wrote:
>>
>> ..."domain:complex" is not the default for which code: Maxima or Sage?
>>
>
> it's a maxima command, so: default for
On Wednesday, June 20, 2018 at 10:12:24 AM UTC-7, Richard_L wrote:
>
> ..."domain:complex" is not the default for which code: Maxima or Sage?
>
it's a maxima command, so: default for maxima. Sage uses maxima with
non-default settings.
>
> Sage's documentation [
>
..."domain:complex" is not the default for which code: Maxima or Sage?
Sage's documentation
[https://doc.sagemath.org/html/en/reference/calculus/sage/calculus/var.html]
states
By default, var returns a complex variable. To define real or positive
> variables we can specify the domain as:
On Wednesday, June 20, 2018 at 7:15:11 AM UTC-7, Richard_L wrote:
>
> Thank you! maxima_calculus.eval("domain:real;") solves my immediate
> problem.
> Of course, the underlying bug remains.
> BTW, I had heard years ago to avoid declaring sage variables with
> domain='positive', as this often
On Tuesday, June 19, 2018 at 10:35:46 PM UTC-7, Ralf Stephan wrote:
>
> On Wednesday, June 20, 2018 at 12:22:07 AM UTC+2, Nils Bruin wrote:
>>
>> Of course, another solution for your computation to succeed is to not put
>> the assumptions in. Inequalities will not affect matrix algebra
>>
Thank you! maxima_calculus.eval("domain:real;") solves my immediate problem.
Of course, the underlying bug remains.
BTW, I had heard years ago to avoid declaring sage variables with
domain='positive', as this often triggered maxima failures. I wonder if I
have stumbled on the same bug.
On
On Wednesday, June 20, 2018 at 12:22:07 AM UTC+2, Nils Bruin wrote:
>
> Of course, another solution for your computation to succeed is to not put
> the assumptions in. Inequalities will not affect matrix algebra
> computations. (only decisions are made based on whether something is
> *equal* to
On Tuesday, June 19, 2018 at 2:30:46 PM UTC-7, Richard_L wrote:
>
> It would be useful if one could override Sage's default "domain:complex",
> at least until the Maxima fix comes through.
>
> One can: maxima_calculus.eval("domain: real;")
Of course, another solution for your computation to
There are several ways to avoid the seg-fault. Consider this script:
> display2d:false$
> domain:complex; /*setting domain to real causes success in
> all cases below*/
> declare([m1,m2,m3],real);
> declare([r12,r13,r23],real);
> assume(r12>0,r13>0,r23>0);
> assume(r12
On Saturday, June 16, 2018 at 12:05:48 PM UTC-7, Robert Dodier wrote:
> Hi,
>
> for the record I've tried this problem with a translation of the
> script to pure Maxima and I can't reproduce the error. I'm working
> with a recent Maxima build (post-5.41) and ECL 16.1.3 on Linux x86. I
> tried
I will post the failing Sage call on the original thread, along with the
full PDB script.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
That appears to be what I'm running via the Sage interface:
[sage-beta is my soft-link to sage-8.3-beta5]
rllozes@linux-yzi3:~/temp> sage-beta --maxima
;;; Loading
#P"/home/rllozes/Development/sage/local/lib/ecl/sb-bsd-sockets.fas"
;;; Loading
19 matches
Mail list logo
