Hi!
Sorry to bother you again, but there still is a change that I don't
understand. It is about two doctests in sage.stats, where the expected
output has become a different but equivalent expression. It boils down
to a change in the minus sign distribution of symbolic expressions, as
below.
The d
Hi kcrisman,
On 15 Feb., 21:12, kcrisman wrote:
> Burcin or someone else who understands more about this (I see Mike
> responded as well) would have to say. I think the real issue is that
> we'd like to have consistency in representation, and in particular
> that certain doctests don't fail wher
> Question:
> Is it a problem if (-sqrt(2)-1/5*I)^2 returns 1/25*(-5*sqrt(2) - I)^2,
> i.e., if the minus sign is not pulled out?
> If it is, then please explain in what part of the code the minus sign
> is supposed to be pulled out.
>
Burcin or someone else who understands more about this (I see
On 15 Feb., 19:20, Simon King wrote:
> I think a segfault caused by a different choice of a gcd is nasty and
> probably a bug. But I guess Ginac is beyond my understanding.
I don't know if there is a bug in Ginac hidden (Ginac people may
contact me if they feel like hunting that issue down), but
Dear Mike and kcrisman,
Thank you for providing me with some pointers!
On 15 Feb., 17:29, kcrisman wrote:
> ...
> So it is using the Ginac gcd, and calling it 'g_gcd'. And all of that
> is in a call
>
> cdef extern from "ginac_wrap.h":
>
> which lives in devel/sage/c_lib/include. I understan
On Feb 15, 10:59 am, Simon King wrote:
> On 15 Feb., 16:37, Simon King wrote:
>
> > Yep:
> > sage: a = SR(-1)
> > sage: b = SR(-1/5)
> > sage: sage.rings.arith.gcd(a,b)
> > 1 # or 1/5 with my patch.
>
> No, I was mistaken. Everything can be traced back to g_gcd, which is
> called in sage.symbo
On Tue, Feb 15, 2011 at 4:59 PM, Simon King wrote:
> No, I was mistaken. Everything can be traced back to g_gcd, which is
> called in sage.symbolic.expression.Expression.gcd. At that point, I
> lost track: I can not find the code of g_gcd (even "grep g_gcd" does
> not give me a hint). In particula
On 15 Feb., 16:37, Simon King wrote:
> Yep:
> sage: a = SR(-1)
> sage: b = SR(-1/5)
> sage: sage.rings.arith.gcd(a,b)
> 1 # or 1/5 with my patch.
No, I was mistaken. Everything can be traced back to g_gcd, which is
called in sage.symbolic.expression.Expression.gcd. At that point, I
lost track: I
On 15 Feb., 16:34, Simon King wrote:
> Thank you! I guess this is it! Namely, I changed sage.rings.arith.gcd.
Yep:
sage: a = SR(-1)
sage: b = SR(-1/5)
sage: sage.rings.arith.gcd(a,b)
1 # or 1/5 with my patch.
However, if a different choice of a gcd can result in a segfault then
I think there is
Hi!
On 15 Feb., 16:23, kcrisman wrote:
> ...
> Hence in symbolic/pynac.pyx we have the following:
>
> #
> # GCD
> #
> import sage.rings.arith
> cdef public object py_gcd
On 15 Feb., 15:50, Simon King wrote:
> To symbolists:
> Please tell me whether (and how) gcd or lcm occur in
> new_Expression_from_GEx, or at least show me the code!
I also found that the gcd method of symbolic expressions was
(indirectly) changed by my patch, but again, I can't find the code:
s
On Feb 15, 9:50 am, Simon King wrote:
> Hi!
>
> Working on #10771 (making gcd and lcm work nicer), I got trouble with
> the multiplication of symbolic expressions. The problem seems to boil
> down to examples of the following type:
>
> Without the patch
> sage: x = -sqrt(2)-1/5*I
> sage: x*x
> 1
12 matches
Mail list logo
