[sage-devel] Re: denominator() hangs on a large fraction

On Thursday, January 5, 2017 at 8:01:42 AM UTC+1, Ralf Stephan wrote: > > There was a bug in the Pynac/Singular interface. To cancel fractions > a GCD is done via Singular. This was fixed 7 days ago in > > https://github.com/pynac/pynac/commit/fd180a9a82018e97c540950c1bbf083768f703ef > and the ne

[sage-devel] Re: denominator() hangs on a large fraction

There was a bug in the Pynac/Singular interface. To cancel fractions a GCD is done via Singular. This was fixed 7 days ago in https://github.com/pynac/pynac/commit/fd180a9a82018e97c540950c1bbf083768f703ef and the new Pynac version has the fix, see https://trac.sagemath.org/ticket/22136 Regards, -

[sage-devel] Re: coercions from (quadratic) NumberFields to AA

On Wednesday, January 4, 2017 at 7:54:57 AM UTC-6, Marc Mezzarobba wrote: > > Daniel Krenn wrote: > > In the doc of sage.rings.qqbar.AlgebraicRealField._coerce_map_from_ > > there is the following test: > > > > sage: K. = QuadraticField(7, embedding=AA(7).sqrt()) > > sage: AA.has_coe

[sage-devel] Re: denominator() hangs on a large fraction

On Wednesday, January 4, 2017 at 9:06:44 PM UTC, Eric Gourgoulhon wrote: > > Le mercredi 4 janvier 2017 21:47:00 UTC+1, Dima Pasechnik a écrit : >> >> >> >> It's because I need to consider sqrt(-z), so that I cannot stay with >>> rational functions. >>> >> >> I woud have picked one more variabl

[sage-devel] Re: denominator() hangs on a large fraction

Le mercredi 4 janvier 2017 21:47:00 UTC+1, Dima Pasechnik a écrit : > > > > It's because I need to consider sqrt(-z), so that I cannot stay with >> rational functions. >> > > I woud have picked one more variable, w, and set w^2=-z. > Now everything is polynomial again... > > But z is not a variab

Re: [sage-devel] group algebra modules

Hi Travis and David, Sorry for posting and then disappearing for a bit. Thanks for your answers. I will be very happy to have your help with the project to the extent that you have time, and even just any quick suggestions and advice. My thinking was to do something that would cover arbitrary

[sage-devel] Re: denominator() hangs on a large fraction

On Wednesday, January 4, 2017 at 8:24:22 PM UTC, Eric Gourgoulhon wrote: > > Hi Samuel, > > Le mercredi 4 janvier 2017 20:49:54 UTC+1, Samuel Lelievre a écrit : >> >> >> >> It's of course a good thing to track the issue, but on the other side, >> why work in the Symbolic Ring? >> >> > It's becaus

[sage-devel] Re: denominator() hangs on a large fraction

Hi Samuel, Le mercredi 4 janvier 2017 20:49:54 UTC+1, Samuel Lelievre a écrit : > > > > It's of course a good thing to track the issue, but on the other side, > why work in the Symbolic Ring? > > It's because I need to consider sqrt(-z), so that I cannot stay with rational functions. Actually sq

Re: [sage-devel] denominator() hangs on a large fraction

Most likely the pynac-0.7.2 update.. On Wednesday, January 4, 2017 at 5:19:36 PM UTC+1, Eric Gourgoulhon wrote: > > Works in Sage 7.5.beta5. > So the issue has been introduced somewhere between 7.5.beta6 and 7.5.rc1... > > > Le mercredi 4 janvier 2017 17:08:51 UTC+1, tdumont a écrit : > > >> sam

Re: [sage-devel] denominator() hangs on a large fraction

Works in Sage 7.5.beta5. So the issue has been introduced somewhere between 7.5.beta6 and 7.5.rc1... Le mercredi 4 janvier 2017 17:08:51 UTC+1, tdumont a écrit : > same for me in7.5.rc1; works in 7.4. > > > -- You received this message because you are subscribed to the Google Groups "sage-

Re: [sage-devel] denominator() hangs on a large fraction

Le 04/01/2017 à 16:47, Eric Gourgoulhon a écrit : > Hi, > > In Sage 7.5.rc1: > same for me in7.5.rc1; works in 7.4. t. > | > sage:var('x y') > (x,y) > sage:z =(x^18+60*x^17+331776*(x^2-1)*y^16+1599*x^16+25880*x^15+110 > :592*(x^4+15*x^3+99*x^2+485*x +1200)*y^14+266700*x^14+160*x^ >

Re: [sage-devel] denominator() hangs on a large fraction

Confirmed. Sage gets a SIGSEGV here and for some reason, the usual SIGSEGV handling code doesn't work. Only the dashes are printed. -- You received this message because you are subscribed to the Google Groups "sage-devel

[sage-devel] Re: denominator() hangs on a large fraction

Actually the numerator returned by Sage is not correct and trying to simplify it results in a crash + core dumped... -- 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 emai

[sage-devel] denominator() hangs on a large fraction

Hi, In Sage 7.5.rc1: sage: var('x y') (x, y) sage: z = (x^18 + 60*x^17 + 331776*(x^2 - 1)*y^16 + 1599*x^16 + 25880*x^15 + 110 : 592*(x^4 + 15*x^3 + 99*x^2 + 485*x + 1200)*y^14 + 266700*x^14 + 160*x^ : 13 - 9216*(17*x^6 + 60*x^5 - 417*x^4 - 3040*x^3 - 13425*x^2 - 31020*x - 16 :

Re: [sage-devel] Re: coercions from (quadratic) NumberFields to AA

On 2017-01-04 14:54, Marc Mezzarobba wrote: > Probably because NumberField_generic.__init__() does: > > self._populate_coercion_lists_(embedding=embedding) Ok, I see, thank you. Daniel -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

[sage-devel] Re: coercions from (quadratic) NumberFields to AA

Daniel Krenn wrote: > In the doc of sage.rings.qqbar.AlgebraicRealField._coerce_map_from_ > there is the following test: > > sage: K. = QuadraticField(7, embedding=AA(7).sqrt()) > sage: AA.has_coerce_map_from(K) > True > > Why does this return (correctly) True, although the code of th

[sage-devel] coercions from (quadratic) NumberFields to AA

In the doc of sage.rings.qqbar.AlgebraicRealField._coerce_map_from_ there is the following test: sage: K. = QuadraticField(7, embedding=AA(7).sqrt()) sage: AA.has_coerce_map_from(K) True Why does this return (correctly) True, although the code of this method is simply def _coerce

Re: [sage-devel] Python's _ssl module wont't compile correctly against OpenSSL 1.1

Le samedi 24 décembre 2016 17:00:37 UTC+1, Emmanuel Charpentier a écrit : [ Snip...] > I plan to recompile against openssl to try to port the Python patch. More > on this later... > Well, Trac#22089 was an abject failure ; I think that our best bet is